[xsd-users] Re: xsd-users Digest, Vol 43, Issue 5

dan mcgee dan.mcgee at ntsoc.com
Sat Jan 10 21:59:56 EST 2009


Thanks

xsd-users-request at codesynthesis.com wrote:

>Send xsd-users mailing list submissions to
>	xsd-users at codesynthesis.com
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://codesynthesis.com/mailman/listinfo/xsd-users
>or, via email, send a message with subject or body 'help' to
>	xsd-users-request at codesynthesis.com
>
>You can reach the person managing the list at
>	xsd-users-owner at codesynthesis.com
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of xsd-users digest..."
>
>
>Today's Topics:
>
>   1. Re: Re: Spec file for XSD.. (Boris Kolpackov)
>   2. Re: Compile problem with CygWin (Steve)
>   3. Re: Re: Spec file for XSD.. (Jeroen N. Witmond [Bahco])
>   4. Re: Re: Spec file for XSD.. (Boris Kolpackov)
>   5. Re: Polymorphism enhancements. (Boris Kolpackov)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 9 Jan 2009 15:49:32 +0200
>From: Boris Kolpackov <boris at codesynthesis.com>
>Subject: Re: [xsd-users] Re: Spec file for XSD..
>To: "Fitzpatrick, Bill" <BFITZPATRICK at NADA.org>
>Cc: xsd-users at codesynthesis.com
>Message-ID: <20090109134932.GB29883 at karelia>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Bill,
>
>Boris Kolpackov <boris at codesynthesis.com> writes:
>
>> If you would like to automate the build process, including 
>> configuration and building of prerequisites then you can take
>> a look at how Raphael Bossek did this for the Debian package.
>> He basically created and saved a configuration where all the
>> prerequisites are installed. His rules script (Debian's 
>> counterpart of the spec file) would then unpack each 
>> prerequisite, copy the configuration, build, and install.
>
>Wanted to let you know that we created a package for XSD 3.2.0 with
>all its dependencies (except Xerces-C++ and Boost). The dependencies
>are pre-configured and there is a top-level build.sh script that builds
>everything in non-interactive mode. You can customize the build using
>the standard variables e.g., CXX, CPPFLAGS, CXXFLAGS, LDFLAGS, etc.
>
>There is a README file inside the package with more information and
>the package itself is available here:
>
>http://www.codesynthesis.com/download/xsd/3.2/xsd-3.2.0+dep.tar.bz2
>
>We are planning to maintain this new package for the future releases.
>
>I thought you may want to base your RPM spec file for XSD on it. Let
>me know if you have any questions or need help.
>
>Boris
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 9 Jan 2009 06:08:02 -0800 (PST)
>From: Steve <ongs_1999 at yahoo.com>
>Subject: Re: [xsd-users] Compile problem with CygWin
>To: Boris Kolpackov <boris at codesynthesis.com>
>Cc: xsd-users at codesynthesis.com
>Message-ID: <999450.66065.qm at web32203.mail.mud.yahoo.com>
>Content-Type: text/plain; charset=us-ascii
>
>Hi all (especially Boris)
>
>I am not ignoring your question. It just I am so hang up with work at the present. I will get back to this matter when time permissible.
>
>Regards,
>Steve
>
>--- On Thu, 1/8/09, Boris Kolpackov <boris at codesynthesis.com> wrote:
>
>From: Boris Kolpackov <boris at codesynthesis.com>
>Subject: Re: [xsd-users] Compile problem with CygWin
>To: "Steve" <ongs_1999 at yahoo.com>
>Cc: xsd-users at codesynthesis.com
>Date: Thursday, January 8, 2009, 8:48 AM
>
>
>-----Inline Attachment Follows-----
>
>Hi Steve,
>
>In the future please send technical questions like these to the
>xsd-users mailing list (which I've CC'ed) instead of to me directly.
>This way other developers who may have experienced a similar problem
>can provide you with a solution. Plus questions and answers will be
>archived and available to others with similar problems.
>
>
>Steve <ongs_1999 at yahoo.com> writes:
>
>> First of all, it's compiled now. Thanks.
>> 
>> I do, however, have couple more questions (I hope they are not too 
>> "overwhelming"):
>> 
>> 1. Is there a way to run 'make' for some of these packages 
>> none-interactively? I am trying to write a bash script to 
>> automate the build.
>
>Yes, it is possible to pre-configure everything in a fairly
>generic way. Seeing that there has been quite a few requests
>like this, I created a package which contains XSD 3.2.0 with
>all its prerequisites (except Xerces-C++ and Boost) as well 
>as a non-interactive build script:
>
>http://www.codesynthesis.com/~boris/tmp/xsd-3.2.0+dep.tar.bz2
>
>See the README file inside for details and let me know if you
>run into any problems.
>
>
>> 2. I tried to build the xsd on Nexenta (Debian on top of OpeSolaris)
>> but unsuccessfully (I thought because there are some missing libraries,
>> but I am not sure, since this is my first encountered with 'build').
>> Could you try and see what the problem -- If you have the resources, 
>> that is :)
>
>Since it is Debian-based then that means it has the GNU toolchain.
>I would expect everything to compile without any problems. What
>errors are you getting?
>
>Boris
>
>
>
>      
>
>------------------------------
>
>Message: 3
>Date: Fri, 9 Jan 2009 15:16:59 +0100 (CET)
>From: "Jeroen N. Witmond [Bahco]" <jnw at xs4all.nl>
>Subject: Re: [xsd-users] Re: Spec file for XSD..
>To: xsd-users at codesynthesis.com
>Message-ID:
>	<11658.80.101.201.227.1231510619.squirrel at webmail.xs4all.nl>
>Content-Type: text/plain;charset=iso-8859-1
>
>Boris Kolpackov <boris at codesynthesis.com> writes:
>> Wanted to let you know that we created a package for XSD 3.2.0 with
>> all its dependencies (except Xerces-C++ and Boost). The dependencies
>> are pre-configured and there is a top-level build.sh script that builds
>> everything in non-interactive mode. You can customize the build using
>> the standard variables e.g., CXX, CPPFLAGS, CXXFLAGS, LDFLAGS, etc.
>>
>> There is a README file inside the package with more information and
>> the package itself is available here:
>>
>> http://www.codesynthesis.com/download/xsd/3.2/xsd-3.2.0+dep.tar.bz2
>>
>> We are planning to maintain this new package for the future releases.
>>
>> I thought you may want to base your RPM spec file for XSD on it. Let
>> me know if you have any questions or need help.
>
>Nice!
>
>Minor nit: xsd-3.2.0+dep.tar.bz2: gzip compressed data, from Unix, last
>modified: Fri Jan  9 14:24:50 2009
>
>(The file name extension does not match the content. `tar -zxf` works on
>the file.)
>
>Jeroen.
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Fri, 9 Jan 2009 16:10:26 +0200
>From: Boris Kolpackov <boris at codesynthesis.com>
>Subject: Re: [xsd-users] Re: Spec file for XSD..
>To: "Jeroen N. Witmond [Bahco]" <jnw at xs4all.nl>
>Cc: xsd-users at codesynthesis.com
>Message-ID: <20090109141026.GD29883 at karelia>
>Content-Type: text/plain; charset=us-ascii
>
>Jeroen N. Witmond [Bahco] <jnw at xs4all.nl> writes:
>
>> Minor nit: xsd-3.2.0+dep.tar.bz2: gzip compressed data
>
>Fixed. Thanks, Jeroen!
>
>Boris
>
>
>
>------------------------------
>
>Message: 5
>Date: Fri, 9 Jan 2009 16:46:23 +0200
>From: Boris Kolpackov <boris at codesynthesis.com>
>Subject: [xsd-users] Re: Polymorphism enhancements.
>To: Bill Pringlemeir <bpringle at sympatico.ca>
>Cc: xsd-users at codesynthesis.com
>Message-ID: <20090109144623.GE29883 at karelia>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Bill,
>
>Thanks for the feedback. My comments are below.
>
>Bill Pringlemeir <bpringle at sympatico.ca> writes:
>
>> > We can always add an option (e.g., --generate-explicit) for this but
>> > I am wondering how useful it will be.
>> 
>> That is a killer if you have 'operator' functionality in a wrapper
>> with parameter overloading.  You end up getting ambiguous definitions.
>> For example,
>> 
>> <xs:complexType name="quaterino">
>>   <xs:sequence>
>>     <xs:element name="oridinal" type="int_t"/>
>>   </xs:sequence>
>>   <xs:attribute name="i" type="int_t" default="0"/>
>>   <xs:attribute name="j" type="int_t" default="0"/>
>>   <xs:attribute name="k" type="int_t" default="0"/>
>> </xs:complexType>
>> 
>> class  quaterino: public quaterino_base
>> {
>> public:
>>    operator int();
>> }
>> quaterino operator+(const quaterino &, const quaterino&);
>> quaterino operator+(const quaterino &, const quaterino&);
>> quaterino operator+(const quaterino &, const quaterino&);
>
>I am not sure I follow. Which definitions are ambiguous? Why do
>you have three identical declarations of operator+ for quaterino?
>
>
>> >> 3. It is possible that a schema will have many similar data types with
>> >> the same defaults.  Would it be possible to use the same default
>> >> static instance in generated code.  Ie, if we have 20 "xs:int
>> >> default='0'" attributes, then twenty static elements are created.
>> 
>> > Do you mean the same private value (in order to save space) or the 
>> > same public accessors for these values?
>> 
>> I meant the same private value to reduce code size.
>
>That would be pretty hard to do and I don't think the gain will be
>significant. 
>
>We are also planning to change the way we handle default values. Right
>now we parse the string representation of the default value as it appears 
>in XML Schema at runtime. So for:
>
><attribute name="foo" type="int" default="123"/>
>
>We generate something like:
>
>int foo_default_value_ = traits<int>::parse ("123");
>
>We are planning to change this to perform parsing at compile-time
>so that we will generate:
>
>int foo_default_value_ = 123;
>
>For XML Schema types that are mapped to fundamental C++ types, such as
>int, double, etc., we will probably eliminate the variable altogether
>and return the literal directly. I think that will help your case.
>
>
>> >> Alternatively, more control over the 'auto_ptr' mechanism that allows
>> >> selective generation of constructors would help.
>> 
>> > Not sure how this can be done. Specifying a set of c-tors to generate
>> > for each type sounds too burdensome.
>> 
>> I am not sure which variant is used underneath by XSD generated code.
>> However, with the 'base-ctor' option you can get four variants of
>> constructors.  In some cases the only difference is an
>> "xml_schema::string &" versus "std::auto_ptr<xml_schema::string>"
>> parameter.  With this condition the 'base-ctor' will generate four
>> versions.  The deep copy versions are useful to a user unless it is a
>> complexType.
>> 
>> It becomes more painful when customizing these classes [there are four
>> constructors to overload].  I was just wishing to turn off the
>> 'auto_ptr' for a particular type (the class, not constructor
>> parameters).  Did I miss something?  I don't think you can do this.
>
>The auto_ptr versions for types like xml_schema::string are only
>generated when polymorphism is enabled. This is done to allow 
>polymorphic behavior for types derived from string even though,
>in 99% of schemas, it is not needed.
>
>While it is definitely possible to add an option that would disable
>generation of the c-tor with auto_ptr arguments for a particular
>type, I am trying to see if there is a better solution.
>
>One idea that we have is to allow you to specify which hierarchies
>in your object model actually need polymorphism. Normally a schema
>would contain only a handful of types (usually derived from one or
>two bases) that should be polymorphism-aware (that is, they can be
>used in substitution groups and/or xsi:type). We can detect these 
>types when substitution groups are involved but with xsi:type any
>type can theoretically be used.
>
>So we can provide an option, something like --polymorphic-base,
>where you can specify root types for polymorphic hierarchies in
>your schemas. Then the XSD compiler will generate polymorphism
>support code (and c-tors with auto_ptr arguments) only for these
>types and types that are derived from them. I believe this will
>result in significant object code size reduction for most schemas.
>
>What do you think?
>
>Boris
>
>
>
>------------------------------
>
>_______________________________________________
>xsd-users mailing list
>xsd-users at codesynthesis.com
>http://codesynthesis.com/mailman/listinfo/xsd-users
>
>
>End of xsd-users Digest, Vol 43, Issue 5
>****************************************

-- 
Sent from my Android phone with K-9. Please excuse my brevity.


More information about the xsd-users mailing list