From jnw at xs4all.nl Thu Jan 1 07:21:06 2009 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] cxx-parser: In typemap file, C++ types are sometimes incorrectly namespaced Message-ID: <11472.80.101.201.227.1230812466.squirrel@webmail.xs4all.nl> Happy New Year, everybody! In XSD version 3.2.0, I came across a small problem in the handling of namespaces for the C++ types in the typemap file. All source files needed to reproduce this problem, including a Makefile, can be found in tarball http://www.xs4all.nl/~jnw/codesynthesis/parser-typemap-namespace.tgz This tarball expands in the current directory. File mixed.map contains namespace "http://metadox.xs4all.nl/mixed" mixed { include ; binop ::mpz_class; operator_t action; } This results in compilation error: expected unqualified-id before '::' token, for instance on line "virtual mixed::::mpz_class post_binop () = 0;" in the generated pskel.hxx file. The problem can be bypassed by splitting the content of the typemap file, as shown in file split.map, which contains namespace "http://metadox.xs4all.nl/mixed" mixed { operator_t action; } namespace "http://metadox.xs4all.nl/mixed" { include ; binop ::mpz_class; } The code generated by XSD when using split.map compiles and executes as well as should be expected without customizing the generated implementation. Regards, Jeroen. From a.omrani at gmail.com Mon Jan 5 09:55:20 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] CDATA Message-ID: <183a50e60901050655n5c8f667ew54f0365a501df172@mail.gmail.com> Hi, Thank you Boris for your previous helpful replies. I have a new question. How xsd manages CDATA sections? does it return the data in it as a single string? (so I have to parse it myself to retrieve data from it)? The Data in CDATA has a look like this: a=6795 b=IP shu c=... Thank you From boris at codesynthesis.com Mon Jan 5 09:59:38 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] cxx-parser: In typemap file, C++ types are sometimes incorrectly namespaced In-Reply-To: <11472.80.101.201.227.1230812466.squirrel@webmail.xs4all.nl> References: <11472.80.101.201.227.1230812466.squirrel@webmail.xs4all.nl> Message-ID: <20090105145938.GB26061@karelia> Hi Jeroen, Jeroen N. Witmond [Bahco] writes: > File mixed.map contains > namespace "http://metadox.xs4all.nl/mixed" mixed > { > include ; > binop ::mpz_class; > operator_t action; > } > This results in compilation error: expected unqualified-id before '::' > token, for instance on line "virtual mixed::::mpz_class post_binop () = > 0;" in the generated pskel.hxx file. The original idea of the C++ namespace for the XML Schema namespace was to add it to every type in the namespace to save typing. There are a few situations where this is not desirable. One is a fully-qualified name as in your case. Another case is the use of fundamental types such as int, long, etc. I was thinking of fixing this but then realized that it gets a lot more complex when we consider things like const: binop "const ::mpz_class*"; operator_t "const action*"; foo "const unsigned long*"; In other words we would need to parse the type in order to figure out whether and where to add the namespace. I will need to think some more about other possible complications before attempting to fix this. Thanks for reporting this! Boris From boris at codesynthesis.com Mon Jan 5 10:03:19 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] CDATA In-Reply-To: <183a50e60901050655n5c8f667ew54f0365a501df172@mail.gmail.com> References: <183a50e60901050655n5c8f667ew54f0365a501df172@mail.gmail.com> Message-ID: <20090105150319.GC26061@karelia> Hi Azadeh, Azadeh Omrani writes: > How xsd manages CDATA sections? > does it return the data in it as a single string? (so I have to parse it > myself to retrieve data from it)? CDATA is parsed by the underlying XML parser and you get the actual data. You don't need to do anything special to access it. Boris From bpringle at sympatico.ca Wed Jan 7 00:53:35 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: Polymorphism enhancements. References: <87prkb4b1j.fsf@sympatico.ca> <20081202123138.GC1977@karelia> <874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia> <87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca> <20081203081809.GG12327@karelia> <87zljcx335.fsf@sympatico.ca> <20081204142819.GA13539@karelia> <87iqpzeq4v.fsf_-_@sympatico.ca> <20081205084325.GC20354@karelia> Message-ID: <87mye3d5ls.fsf@sympatico.ca> On 5 Dec 2008, boris@codesynthesis.com wrote: > 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, 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 ended up using '--custom-type quaterino='. I agree that your time might be better spent elsewhere. >> 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. >> 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" 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. Thanks again, Bill Pringlemeir -- ``C Code. C code run. Run, code, run... PLEASE!!!'' - Barbara Tongue From ongs_1999 at yahoo.com Thu Jan 8 00:13:45 2009 From: ongs_1999 at yahoo.com (Steve) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compile problem with CygWin Message-ID: <835795.17153.qm@web32201.mail.mud.yahoo.com> Hi, This is my first attempt to compile XSD in CygWin. Everything went pretty smooth until I compile the XSD itself; I ran into the following error: c++ /cygdrive/c/Projects/XSD/xsd-3.2.0/xsd/cxx/parser/parser-header.cxx /cygdrive/c/Projects/XSD/libcult-1.4.2/cult/containers/iterator.hxx: In function `Cult::Types::Fundamental::Boolean Cult::Containers::operator!=(const Cult::Containers::IteratorAdapter&, const Cult::Containers::IteratorAdapter&) [with I = stlp_std::reverse_iterator > >, J = stlp_std::reverse_iterator > >]': /cygdrive/c/Projects/XSD/xsd-3.2.0/xsd/cxx/parser/parser-header.cxx:1324:?? instantiated from here /cygdrive/c/Projects/XSD/libcult-1.4.2/cult/containers/iterator.hxx:177: error: no match for 'operator!=' in '(+i)->Cult::Containers::IteratorAdapter::base [with I = stlp_std::reverse_iterator > >]() != (+j)->Cult::Containers::IteratorAdapter::base [with I = stlp_std::reverse_iterator > >]()' /cygdrive/c/Projects/XSD/STLport-5.0.1/stlport/stl/_bvector.h:146: note: candidates are: bool stlp_std::operator!=(const stlp_std::_Bit_iterator_base&, const stlp_std::_Bit_iterator_base&) make: *** [/cygdrive/c/Projects/XSD/xsd-3.2.0/xsd/cxx/parser/parser-header.o] Error 1 ... Please help! Thanks, Steve From boris at codesynthesis.com Thu Jan 8 00:49:44 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compile problem with CygWin In-Reply-To: <835795.17153.qm@web32201.mail.mud.yahoo.com> References: <835795.17153.qm@web32201.mail.mud.yahoo.com> Message-ID: <20090108054944.GA7211@karelia> Hi Steve, Steve writes: > Everything went pretty smooth until I compile the XSD itself; I ran > into the following error: > > /cygdrive/c/Projects/XSD/xsd-3.2.0/xsd/cxx/parser/parser-header.cxx:1324: instantiated from here We fixed this in the 3.2.0-1 release of the source code. Try to download xsd-3.2.0-1.tar.bz2 instead of xsd-3.2.0.tar.bz2 and everything should compile. Boris From a.omrani at gmail.com Thu Jan 8 05:51:03 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access Message-ID: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> Hello Boris and everybody, Can you please help me on this: I want to retrieve parsed data that I need. But I was confused. ///////////////////////////////////////////////////////////////////////////The schema is like this: [...] [....] /////////////////////////////////////////// the xml instance is like this: en ** ** http://example.com/defaultSDP ////////////////////////////////////This is how I tried to retrieve SDPStream:: esg::ESGType::ComponentDescription_sequence& cds (eagdata.esgData->ComponentDescription()); for(esg::ESGType::ComponentDescription_iterator i (cds.begin ());i != cds.end (); ++j) { esg::ComponentDescriptionType::SessionDescription_type sdt (i->SessionDescription()); //////// Then what? ( Regarding that I don't know which of the instantiations of SessionDescriptionBaseType will arrive by this time.) ////////or maybe the above line of code is not useful...SOS... } Thank you so much Azadeh From a.omrani at gmail.com Thu Jan 8 05:52:55 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access Message-ID: <183a50e60901080252r1933dd25w86b9b19a1133b14b@mail.gmail.com> Hello Boris and everybody, Can you please help me on this: I want to retrieve parsed data that I need. But I was confused. ///////////////////////////////////////////////////////////////////////////The schema is like this: [...] [....] /////////////////////////////////////////// the xml instance is like this: en ** ** http://example.com/defaultSDP ////////////////////////////////////This is how I tried to retrieve SDPStream:: esg::ESGType::ComponentDescription_sequence& cds (eagdata.esgData->ComponentDescription()); for(esg::ESGType::ComponentDescription_iterator i (cds.begin ());i != cds.end (); ++j) { esg::ComponentDescriptionType::SessionDescription_type sdt (i->SessionDescription()); //////// Then what? ( Regarding that I don't know which of the instantiations of SessionDescriptionBaseType will arrive by this time.) ////////or maybe the above line of code is not useful...SOS... } Thank you so much Azadeh From boris at codesynthesis.com Thu Jan 8 06:36:55 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> Message-ID: <20090108113655.GA10046@karelia> Hi Azadeh, I noticed that you sent two identical copies of this email. Please refrain from doing this in the future to avoid unnecessary traffic on the mailing list. Azadeh Omrani writes: > esg::ESGType::ComponentDescription_sequence& cds > (eagdata.esgData->ComponentDescription()); > for(esg::ESGType::ComponentDescription_iterator i (cds.begin ());i != > cds.end (); ++j) > { > esg::ComponentDescriptionType::SessionDescription_type sdt > (i->SessionDescription()); You can test which type it is using dynamic_cast: esg::ComponentDescriptionType::SessionDescription_type& sdt ( i->SessionDescription()); if (SDPRefType* ref = dynamic_cast (&sdt)) { // We've got SDPRefType. } else if (InlinedSDPType* inl = dynamic_cast (&sdt)) { // We've got InlinedSDPType. } Notice that I changed your 'sdt' declaration to use a reference. This is important for the polymorphism to work. For more information on working with polymorphic object models see Section 2.11, "Mapping for xsi:type and Substitution Groups" in the C++/Tree Mapping User Manual: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11 Boris From boris at codesynthesis.com Thu Jan 8 09:48:46 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compile problem with CygWin In-Reply-To: <999335.92572.qm@web32202.mail.mud.yahoo.com> References: <999335.92572.qm@web32202.mail.mud.yahoo.com> Message-ID: <20090108144846.GB10046@karelia> 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 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 From boris at codesynthesis.com Fri Jan 9 08:49:32 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: Spec file for XSD.. In-Reply-To: <20081001210854.GB21793@karelia> References: <7989E8376B575A48988B91440219DA6001C6A345@EXCHANGE2003.NADA.org> <20081001200929.GA21793@karelia> <7989E8376B575A48988B91440219DA6001C6A349@EXCHANGE2003.NADA.org> <20081001210854.GB21793@karelia> Message-ID: <20090109134932.GB29883@karelia> Hi Bill, Boris Kolpackov 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 From ongs_1999 at yahoo.com Fri Jan 9 09:08:02 2009 From: ongs_1999 at yahoo.com (Steve) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compile problem with CygWin Message-ID: <999450.66065.qm@web32203.mail.mud.yahoo.com> 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 wrote: From: Boris Kolpackov Subject: Re: [xsd-users] Compile problem with CygWin To: "Steve" Cc: xsd-users@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 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 From jnw at xs4all.nl Fri Jan 9 09:16:59 2009 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: Spec file for XSD.. Message-ID: <11658.80.101.201.227.1231510619.squirrel@webmail.xs4all.nl> Boris Kolpackov 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. From boris at codesynthesis.com Fri Jan 9 09:10:26 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: Spec file for XSD.. In-Reply-To: <11658.80.101.201.227.1231510619.squirrel@webmail.xs4all.nl> References: <11658.80.101.201.227.1231510619.squirrel@webmail.xs4all.nl> Message-ID: <20090109141026.GD29883@karelia> Jeroen N. Witmond [Bahco] writes: > Minor nit: xsd-3.2.0+dep.tar.bz2: gzip compressed data Fixed. Thanks, Jeroen! Boris From boris at codesynthesis.com Fri Jan 9 09:46:23 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: Polymorphism enhancements. In-Reply-To: <87mye3d5ls.fsf@sympatico.ca> References: <874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia> <87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca> <20081203081809.GG12327@karelia> <87zljcx335.fsf@sympatico.ca> <20081204142819.GA13539@karelia> <87iqpzeq4v.fsf_-_@sympatico.ca> <20081205084325.GC20354@karelia> <87mye3d5ls.fsf@sympatico.ca> Message-ID: <20090109144623.GE29883@karelia> Hi Bill, Thanks for the feedback. My comments are below. Bill Pringlemeir 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, > > > > > > > > > > > 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: We generate something like: int foo_default_value_ = traits::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" > 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 From dan.mcgee at ntsoc.com Sat Jan 10 21:59:56 2009 From: dan.mcgee at ntsoc.com (dan mcgee) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: xsd-users Digest, Vol 43, Issue 5 Message-ID: Thanks xsd-users-request@codesynthesis.com wrote: >Send xsd-users mailing list submissions to > xsd-users@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@codesynthesis.com > >You can reach the person managing the list at > xsd-users-owner@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 >Subject: Re: [xsd-users] Re: Spec file for XSD.. >To: "Fitzpatrick, Bill" >Cc: xsd-users@codesynthesis.com >Message-ID: <20090109134932.GB29883@karelia> >Content-Type: text/plain; charset=us-ascii > >Hi Bill, > >Boris Kolpackov 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 >Subject: Re: [xsd-users] Compile problem with CygWin >To: Boris Kolpackov >Cc: xsd-users@codesynthesis.com >Message-ID: <999450.66065.qm@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 wrote: > >From: Boris Kolpackov >Subject: Re: [xsd-users] Compile problem with CygWin >To: "Steve" >Cc: xsd-users@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 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]" >Subject: Re: [xsd-users] Re: Spec file for XSD.. >To: xsd-users@codesynthesis.com >Message-ID: > <11658.80.101.201.227.1231510619.squirrel@webmail.xs4all.nl> >Content-Type: text/plain;charset=iso-8859-1 > >Boris Kolpackov 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 >Subject: Re: [xsd-users] Re: Spec file for XSD.. >To: "Jeroen N. Witmond [Bahco]" >Cc: xsd-users@codesynthesis.com >Message-ID: <20090109141026.GD29883@karelia> >Content-Type: text/plain; charset=us-ascii > >Jeroen N. Witmond [Bahco] 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 >Subject: [xsd-users] Re: Polymorphism enhancements. >To: Bill Pringlemeir >Cc: xsd-users@codesynthesis.com >Message-ID: <20090109144623.GE29883@karelia> >Content-Type: text/plain; charset=us-ascii > >Hi Bill, > >Thanks for the feedback. My comments are below. > >Bill Pringlemeir 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, >> >> >> >> >> >> >> >> >> >> >> 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: > > > >We generate something like: > >int foo_default_value_ = traits::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" >> 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@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. From jnw at xs4all.nl Thu Jan 22 16:09:50 2009 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: In-memory validation Message-ID: <4570.80.101.201.227.1232658590.squirrel@webmail.xs4all.nl> Hi Boris, I found this post from a year and a day ago. :) My comments are inline below: On Mon, January 21, 2008, Boris Kolpackov wrote: > After some more thinking and experimentation on the subject of in- > memory validation I would like to get your thoughts on our current > view of how it can be implemented and whether it will still be > useful for you project. [...] > The "desirable and impossible/inefficient" category contains the > bulk of the XML Schema validation constructs. These include most > of the facets and key/keyref/unique constructs. Let's consider > the minInclusive and maxInclusive facets from your example below. > The range checking code will have to be called after every > modification to the underlying int value. Just for my own amusement, I've been playing around with the idea of doing just that: Creating a data model that guarantees that its contents conforms to the schema. The current solution of serialisation and re-parsing, when done for every change, certainly is more inefficient than in-memory validation. And when it is delayed until a number of changes have accumulated, the data model may be left in an inconsistent state for some time. This can be a problem when the data model is shared, for instance between threads. > In the current > architecture you can do, for example, the following: > > int& i = rt->bounded_int(); // Get a reference to the "base" type (int) > i = 100; // Impossible to detect. > > This is an example of a check that is impossible to implement in the > current C++/Tree architecture. I beg to differ. What I was in the process of doing, before I got sidetracked into finding a more general solution, was writing custom types for the Schema types positiveInteger et al.. These custom types are based on the Constrained Value library in the Boost sandbox.[1] This library introduces the concept of variables for which constraints are defined. The modifying operators of these variables throw if an attempt is made to break the constraint. I'm having my doubts about this library in its current form, but the concept intrigues me. The disadvantage of writing custom types that enforce the Schema constraints is that the code for these types may get out of date when the Schema constraints are updated. And besides: It is tedious work that should be automated. :) (I am playing around with xsd+dep to see if I can hack this, but it going to take me some time to get up to speed.) > Then there is a number of undesirable checks that, if enforced > immediately, would make the object model very awkward to use. > These are minOccurs, the length and minLength list facets, ordering > of elements, as well as compound keys in key/unique. The problem > with all these constraints is that you may need to perform several > operations (e.g., several push_back's for minOccurs and element > ordering or modification of several elements/attributes for > compound key/unique) before the resulting object model becomes > valid. Food for thought. :) [...] > There is, however, a number of questions about practical usefulness > and implementation of this model: > > 1. How to point to the error location? Possible options: (1) a > reference to the invalid node passed as xml_schema::type& > (drawback: hard to know the actual type and thus to do > anything about the error), (2) XPath identifying the error > location (drawback: impossible to use to correct the error). More food for thought. :) And to state this point more generally: The exception must describe the location, but also describe the constraint that prevented the modification, and anything else that may help to correct the problem. > 2. Some errors may be impossible for the application to correct. > For example, if an error indicates that a string does not match > a pattern, what is the application going to do? If you go by the thought that the constraints are implemented as objects, then these objects can also implement something like: const Type& getDefault() const; which returns a value that is guaranteed to pass the constraint. > 3. If error correction by the application is hard/impossible then > what is the use of in-memory validation other then to know > whether the object model is valid/invalid? There are two sides to this: - If the data model is invalid because an invalid xml file was parsed, then the blame belongs to the creator of that xml file. On second thought: There should be a way to handle input files (or even data models) that become invalid because the Schema changes ... - Otherwise the data model can only become invalid by a modification of that model by the application. It is up to the application code to report the broken constraint (read: attempt to break the constraint) to the origin of the modification. Just my $0.02. Regards, Jeroen. PS: You wouldn't happen to have a prerelease of XSD/e with support for validation during serialization[2] for me to play with? :) [1] http://lists.boost.org/Archives/boost/2008/12/145581.php [2] http://www.codesynthesis.com/pipermail/xsd-users/2008-June/001793.html From Raymond.Rizzuto at sig.com Thu Jan 22 15:26:39 2009 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) Message-ID: Boris, Does XSD support/plan to support Efficient XML Interchange or other mechanisms to reduce the size of XML messages? After a successful 1st phase of the project I am on (in large part due to XSD), we are seeing two issues with our use of XML. One is the network bandwidth associated with a projected 200 million messages of 2-4k per message during a 7 hour period. The other is with the CPU load on the applications receiving and parsing the XML messages (these are C# clients using Microsoft's parser). It seems like EXI might at least address issue 1. Ray ________________________________________ Ray Rizzuto raymond.rizzuto@sig.com Susquehanna International Group (610)747-2336 (W) (215)776-3780 (C) IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From boris at codesynthesis.com Fri Jan 23 08:56:21 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) In-Reply-To: References: Message-ID: <20090123135621.GA16307@karelia> Hi Raymond, Rizzuto, Raymond writes: > Does XSD support/plan to support Efficient XML Interchange or > other mechanisms to reduce the size of XML messages? We do not currently support EXI nor have any definite plans to support it. We do support compact and fast (up to 10x speed up) binary serialization into a number of data representations (CDR, XDR, custom formats). It should be a lot faster and more compact than any binary XML representation could ever get because it does not serialize the markup, only the data. See Section 5.2, "Binary Serialization" in the C++/Tree Mapping User Manual for details: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#5.2 Most people go with binary formats for one (or both) of two reasons: (1) more compact representation, (2) faster parsing and serialization. The problem with XSI, and binary XML formats in general is that they are a half-step in that direction: while they are more efficient than textual XML, they still don't achieve the maximum efficiency offered by the markup-less binary formats. It seems that the majority of people in this situation prefer to go all the way. This explains why we don't get many inquiries about supporting binary XML (you are the second person asking about EXI) and have quite a few people using the binary serialization support. > After a successful 1st phase of the project I am on (in large part > due to XSD), we are seeing two issues with our use of XML. One is > the network bandwidth associated with a projected 200 million > messages of 2-4k per message during a 7 hour period. The other > is with the CPU load on the applications receiving and parsing > the XML messages (these are C# clients using Microsoft's parser). > > It seems like EXI might at least address issue 1. Since you are using C# on the other end, it may be harder for you to use binary serialization since there is no way to generate the insertion/extraction code for C# classes. I agree EXI might address your first problem which can probably be also addressed by simply compressing XML being sent. If you really need support for EXI, we can discuss implementing it as a custom feature on the commercial basis. Boris From boris at codesynthesis.com Fri Jan 23 09:09:31 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: In-memory validation In-Reply-To: <4570.80.101.201.227.1232658590.squirrel@webmail.xs4all.nl> References: <4570.80.101.201.227.1232658590.squirrel@webmail.xs4all.nl> Message-ID: Hi Jeroen, Jeroen N. Witmond [Bahco] writes: > Just for my own amusement, I've been playing around with the idea of doing > just that: Creating a data model that guarantees that its contents > conforms to the schema. The current solution of serialisation and > re-parsing, when done for every change, certainly is more inefficient than > in-memory validation. And when it is delayed until a number of changes > have accumulated, the data model may be left in an inconsistent state for > some time. This can be a problem when the data model is shared, for > instance between threads. I think the most practical approach for such a situation is to have on-demand, in-memory validation support. In case of threads, you would need to lock the data before a thread can modify it. Then you can re-validate it just before unlocking after all the modifications by this thread have been made. > PS: You wouldn't happen to have a prerelease of XSD/e with support for > validation during serialization[2] for me to play with? :) Actually, I do: http://www.codesynthesis.com/~boris/tmp/xsde-3.0.0.a1-i686-linux-gnu.tar.bz2 Take a look inside the examples/cxx/hybrid/ directory. There is not manual yet for the new mapping but I will have the first draft ready in the next couple of days. Boris From PaquetP at navcanada.ca Fri Jan 23 09:58:45 2009 From: PaquetP at navcanada.ca (Paquette, Patrick) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) Message-ID: <474534909BE4064E853161350C47578E0A8B6CCD@ncrmail1.corp.navcan.ca> > Hi Raymond, > > Rizzuto, Raymond writes: > > > Does XSD support/plan to support Efficient XML Interchange or > > other mechanisms to reduce the size of XML messages? > > We do not currently support EXI nor have any definite plans to > support it. We do support compact and fast (up to 10x speed up) > binary serialization into a number of data representations (CDR, > XDR, custom formats). It should be a lot faster and more compact > than any binary XML representation could ever get because it does > not serialize the markup, only the data. See Section 5.2, "Binary > Serialization" in the C++/Tree Mapping User Manual for details: > > http://codesynthesis.com/projects/xsd/documentation/cxx/tree/m > anual/#5.2 > > Most people go with binary formats for one (or both) of two > reasons: (1) more compact representation, (2) faster parsing > and serialization. The problem with XSI, and binary XML formats > in general is that they are a half-step in that direction: while > they are more efficient than textual XML, they still don't achieve > the maximum efficiency offered by the markup-less binary formats. > It seems that the majority of people in this situation prefer to > go all the way. This explains why we don't get many inquiries about > supporting binary XML (you are the second person asking about EXI) > and have quite a few people using the binary serialization support. > > > > After a successful 1st phase of the project I am on (in large part > > due to XSD), we are seeing two issues with our use of XML. One is > > the network bandwidth associated with a projected 200 million > > messages of 2-4k per message during a 7 hour period. The other > > is with the CPU load on the applications receiving and parsing > > the XML messages (these are C# clients using Microsoft's parser). > > > > It seems like EXI might at least address issue 1. > > Since you are using C# on the other end, it may be harder for you > to use binary serialization since there is no way to generate the > insertion/extraction code for C# classes. > > I agree EXI might address your first problem which can probably > be also addressed by simply compressing XML being sent. > > If you really need support for EXI, we can discuss implementing > it as a custom feature on the commercial basis. > > Boris > > > In researching bandwidth reduction solutions, I've seen other tools use something called Fast Info Set... http://en.wikipedia.org/wiki/Fast_Infoset Which are implemented by other vendors... Which standard currently prevails? Patrick From Raymond.Rizzuto at sig.com Fri Jan 23 10:22:23 2009 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) In-Reply-To: <474534909BE4064E853161350C47578E0A8B6CCD@ncrmail1.corp.navcan.ca> References: <474534909BE4064E853161350C47578E0A8B6CCD@ncrmail1.corp.navcan.ca> Message-ID: Thanks! Fast Infoset seems more mature, although that doesn't mean that EXI couldn't end up winning. Or both might co-exist. Ray -----Original Message----- From: Paquette, Patrick [mailto:PaquetP@navcanada.ca] Sent: Friday, January 23, 2009 9:59 AM To: Boris Kolpackov; Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: RE: [xsd-users] Efficient XML Interchange Format (Exi) > Hi Raymond, > > Rizzuto, Raymond writes: > > > Does XSD support/plan to support Efficient XML Interchange or > > other mechanisms to reduce the size of XML messages? > > We do not currently support EXI nor have any definite plans to > support it. We do support compact and fast (up to 10x speed up) > binary serialization into a number of data representations (CDR, > XDR, custom formats). It should be a lot faster and more compact > than any binary XML representation could ever get because it does > not serialize the markup, only the data. See Section 5.2, "Binary > Serialization" in the C++/Tree Mapping User Manual for details: > > http://codesynthesis.com/projects/xsd/documentation/cxx/tree/m > anual/#5.2 > > Most people go with binary formats for one (or both) of two > reasons: (1) more compact representation, (2) faster parsing > and serialization. The problem with XSI, and binary XML formats > in general is that they are a half-step in that direction: while > they are more efficient than textual XML, they still don't achieve > the maximum efficiency offered by the markup-less binary formats. > It seems that the majority of people in this situation prefer to > go all the way. This explains why we don't get many inquiries about > supporting binary XML (you are the second person asking about EXI) > and have quite a few people using the binary serialization support. > > > > After a successful 1st phase of the project I am on (in large part > > due to XSD), we are seeing two issues with our use of XML. One is > > the network bandwidth associated with a projected 200 million > > messages of 2-4k per message during a 7 hour period. The other > > is with the CPU load on the applications receiving and parsing > > the XML messages (these are C# clients using Microsoft's parser). > > > > It seems like EXI might at least address issue 1. > > Since you are using C# on the other end, it may be harder for you > to use binary serialization since there is no way to generate the > insertion/extraction code for C# classes. > > I agree EXI might address your first problem which can probably > be also addressed by simply compressing XML being sent. > > If you really need support for EXI, we can discuss implementing > it as a custom feature on the commercial basis. > > Boris > > > In researching bandwidth reduction solutions, I've seen other tools use something called Fast Info Set... http://en.wikipedia.org/wiki/Fast_Infoset Which are implemented by other vendors... Which standard currently prevails? Patrick IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From boris at codesynthesis.com Fri Jan 23 14:08:17 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) In-Reply-To: References: <20090123135621.GA16307@karelia> Message-ID: Hi Raymond, [I've CC'ed xsd-users to my reply in case someone else is/will be interested.] Rizzuto, Raymond writes: > I was leaning towards EXI since it is from W3C, and should at > some point be a recommendation. I was able to find a tool for > .Net that says it supports it, which would simplify interoperability. > > Do you have any documentation on the mapping from XML to CDR and XDR? > I.e. so we could implement the matching deserialization on the other > end? The binary serialization is actually quite simple. The basic types (e.g., ints, strings, etc.) are serialized according to the data representation rules. For CDR, see ace-cdr-stream-*-.hxx files in libxsd/xsd/cxx/tree/. For XDR, see xdr-stream-*-.hxx files. I think there is a better chance you will find XDR implementation for C# than CDR. User-defined types a serialized like this: 1. If there is a base, it is serialized first. 2. Then elements are serialized in the schema order: a. For required elements, the element value is serialized directly. b. For optional elements a boolean value is serialized first indicating whether the element is present, then element value, if present. c. For sequences of elements, the number of elements is written first, then each element value in order. 3. Then attributes are serialized in the schema order (same rules as 2.a and 2.b). If polymorphism is involved, things are a bit more complicated. For every non-fundamental C++ type, first a boolean value is written indicating whether this element's dynamic type differs from its static type. If it does, then the dynamic type's namespace and name are written. Then the value is serialized. Actually, I think it should be pretty straightforward to extend XSD to automatically generate this code for C# classes. Maybe using partial classes or some such. Boris From Raymond.Rizzuto at sig.com Fri Jan 23 14:29:49 2009 From: Raymond.Rizzuto at sig.com (Rizzuto, Raymond) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) In-Reply-To: References: <20090123135621.GA16307@karelia> Message-ID: Boris, Our schema is pretty complicated, with a lot of polymorphism. I would hate to have to hand-write the C# code to deserialize the XDR. One option might be to create a C++ library from the XSD generated code, and then link that into the C# application. I believe that is possible, though I haven't done it myself. Ray -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, January 23, 2009 2:08 PM To: Rizzuto, Raymond Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Efficient XML Interchange Format (Exi) Hi Raymond, [I've CC'ed xsd-users to my reply in case someone else is/will be interested.] Rizzuto, Raymond writes: > I was leaning towards EXI since it is from W3C, and should at > some point be a recommendation. I was able to find a tool for > .Net that says it supports it, which would simplify interoperability. > > Do you have any documentation on the mapping from XML to CDR and XDR? > I.e. so we could implement the matching deserialization on the other > end? The binary serialization is actually quite simple. The basic types (e.g., ints, strings, etc.) are serialized according to the data representation rules. For CDR, see ace-cdr-stream-*-.hxx files in libxsd/xsd/cxx/tree/. For XDR, see xdr-stream-*-.hxx files. I think there is a better chance you will find XDR implementation for C# than CDR. User-defined types a serialized like this: 1. If there is a base, it is serialized first. 2. Then elements are serialized in the schema order: a. For required elements, the element value is serialized directly. b. For optional elements a boolean value is serialized first indicating whether the element is present, then element value, if present. c. For sequences of elements, the number of elements is written first, then each element value in order. 3. Then attributes are serialized in the schema order (same rules as 2.a and 2.b). If polymorphism is involved, things are a bit more complicated. For every non-fundamental C++ type, first a boolean value is written indicating whether this element's dynamic type differs from its static type. If it does, then the dynamic type's namespace and name are written. Then the value is serialized. Actually, I think it should be pretty straightforward to extend XSD to automatically generate this code for C# classes. Maybe using partial classes or some such. Boris IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From PaquetP at navcanada.ca Fri Jan 23 15:35:00 2009 From: PaquetP at navcanada.ca (Paquette, Patrick) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) Message-ID: <474534909BE4064E853161350C47578E09C56B6D@ncrmail1.corp.navcan.ca> Boris, [I've replied to xsd-users because I'd like to hear input on this design decision] > Hi Raymond, > > [I've CC'ed xsd-users to my reply in case someone else is/will be > interested.] > > Rizzuto, Raymond writes: > > > I was leaning towards EXI since it is from W3C, and should at > > some point be a recommendation. I was able to find a tool for > > .Net that says it supports it, which would simplify > interoperability. > > > > Do you have any documentation on the mapping from XML to > CDR and XDR? > > I.e. so we could implement the matching deserialization on > the other > > end? > > The binary serialization is actually quite simple. The basic types > (e.g., ints, strings, etc.) are serialized according to the data > representation rules. For CDR, see ace-cdr-stream-*-.hxx files > in libxsd/xsd/cxx/tree/. For XDR, see xdr-stream-*-.hxx files. I > think there is a better chance you will find XDR implementation > for C# than CDR. > > User-defined types a serialized like this: > > 1. If there is a base, it is serialized first. > > 2. Then elements are serialized in the schema order: > > a. For required elements, the element value is serialized directly. > > b. For optional elements a boolean value is serialized first > indicating whether the element is present, then element > value, if present. > > c. For sequences of elements, the number of elements is written > first, then each element value in order. > > 3. Then attributes are serialized in the schema order (same rules > as 2.a and 2.b). > > If polymorphism is involved, things are a bit more complicated. For > every non-fundamental C++ type, first a boolean value is written > indicating whether this element's dynamic type differs from its > static type. If it does, then the dynamic type's namespace and name > are written. Then the value is serialized. > > Actually, I think it should be pretty straightforward to extend XSD > to automatically generate this code for C# classes. Maybe using > partial classes or some such. > > Boris > Perhaps an implementation that involves performing the binary serialization algorithm defined above as a subclass of XmlWriter/XmlReader provided by the .NET framework, that way you don't need to define a new language for the xsd compiler? Don't know which would be easier for you. Patrick From a.omrani at gmail.com Mon Jan 26 07:43:43 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: <20090108113655.GA10046@karelia> References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> Message-ID: <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> Hi, Thanks for your response on polymorphism Boris. Can you please help me on the following problem? The schema (in aq.xds) is this: [...] [...] [...] [...] I set the --generate -polymorphysm option, then I have the following error on line 36 of aq.cxx (below): "Unhandled exception at 0x7c812aeb in ESG.exe: Microsoft C++ exception: xsd::cxx::tree::not_derived at memory location 0x0012d5bc.." 1 void ComponentDescriptionType:: 2 parse (::xsd::cxx::xml::dom::parser< char >& p, 3 ::xml_schema::flags f) 4 { 5 for (; p.more_elements (); p.next_element ()) 6 { 7 const ::xercesc::DOMElement& i (p.cur_element ()); 8 const ::xsd::cxx::xml::qualified_name< char > n ( 9 ::xsd::cxx::xml::dom::name< char > (i)); 10 11 // SessionDescription 12 // 13 { 14 ::xsd::cxx::tree::type_factory_map< char >& tfm ( 15 ::xsd::cxx::tree::type_factory_map_instance< 0, char > ()); 16 17 ::std::auto_ptr< ::xsd::cxx::tree::type > tmp ( 18 tfm.create ( 19 "SessionDescription", 20 "urn:dvb:ipdc:esg:2005", 21 &::xsd::cxx::tree::factory_impl< SessionDescription_type >, 22 false, true, i, n, f, this)); 23 24 if (tmp.get () != 0) 25 { 26 if (!SessionDescription_.present ()) 27 { 28 ::std::auto_ptr< SessionDescription_type > r ( 29 dynamic_cast< SessionDescription_type* > (tmp.get ())); 30 31 if (r.get ()) 32 tmp.release (); 33 else 34 throw ::xsd::cxx::tree::not_derived< char > (); 35 36 this->SessionDescription_.set (r); 37 continue; 38 } 39 } 40 } What does this line do and where do you think this problem comes from? P.S. If I remove the option then there is no error like that but non of the following "if clauses" come true. I think it is natural in this case. acquisition::ComponentDescriptionType::SessionDescription_type& sd (cdi->SessionDescription()); if (acquisition::SDPRefType* reff = dynamic_cast (&sd)) { //======== We've got SDPRefType. acquisition::SDPRefType::SDPStream_type sdpstr (reff->SDPStream()); sdp=(char *)sdpstr.c_str(); } else if (acquisition::InlinedSDPType* inll = dynamic_cast (&sd)) { //======== We've got InlinedSDPType. acquisition::InlinedSDPType::SDP_type sdp ( inll->SDP()); sdp= (char *) sdp.c_str(); } On Thu, Jan 8, 2009 at 3:06 PM, Boris Kolpackov wrote: > Hi Azadeh, > > I noticed that you sent two identical copies of this email. Please > refrain from doing this in the future to avoid unnecessary traffic > on the mailing list. > > Azadeh Omrani writes: > > > esg::ESGType::ComponentDescription_sequence& cds > > (eagdata.esgData->ComponentDescription()); > > for(esg::ESGType::ComponentDescription_iterator i (cds.begin ());i != > > cds.end (); ++j) > > { > > esg::ComponentDescriptionType::SessionDescription_type sdt > > (i->SessionDescription()); > > You can test which type it is using dynamic_cast: > > esg::ComponentDescriptionType::SessionDescription_type& sdt ( > i->SessionDescription()); > > if (SDPRefType* ref = dynamic_cast (&sdt)) > { > // We've got SDPRefType. > } > else if (InlinedSDPType* inl = dynamic_cast (&sdt)) > { > // We've got InlinedSDPType. > } > > Notice that I changed your 'sdt' declaration to use a reference. This > is important for the polymorphism to work. > > For more information on working with polymorphic object models see > Section 2.11, "Mapping for xsi:type and Substitution Groups" in the > C++/Tree Mapping User Manual: > > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11 > > > Boris > From boris at codesynthesis.com Mon Jan 26 10:15:17 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> Message-ID: <20090126151517.GA30691@karelia> Hi Azadeh, Azadeh Omrani writes: > xsd::cxx::tree::not_derived at memory location 0x0012d5bc.." This exception means that the actual (dynamic) object type is not derived from the (static) element type (SessionDescriptionBaseType, in your case). Can you make sure that whatever type mentioned in xsi:type is actually derived from SessionDescriptionBaseType? If that does not help, then I will need a small test case (i.e., schema, test driver, and XML file) that reproduces the problem. Boris From boris at codesynthesis.com Mon Jan 26 10:27:12 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) In-Reply-To: References: <20090123135621.GA16307@karelia> Message-ID: Hi Raymond, Rizzuto, Raymond writes: > Our schema is pretty complicated, with a lot of polymorphism. I would > hate to have to hand-write the C# code to deserialize the XDR. I agree, hand-writing this will be a maintenance nightmare. The only reasonable option with this approach is to auto-generate the C# code by customizing the XSD compiler. > One option might be to create a C++ library from the XSD generated > code, and then link that into the C# application. I believe that is > possible, though I haven't done it myself. I think (though I am not 100% sure), the code should be written in managed C++ for this to work. If you want to go this way, then using SWIG[1] seems the most promising. Though it looks too magical to me (for example, I cannot imagine how the wrappers will handle polymorphism). Unfortunately there does not seems to be an easy solution for your problem. In your situation (i.e., complex schema with polymorphism), binary XML, while sub-optimal, seems like the most realistic approach. [1] http://www.swig.org Boris From boris at codesynthesis.com Mon Jan 26 10:35:48 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) In-Reply-To: <474534909BE4064E853161350C47578E09C56B6D@ncrmail1.corp.navcan.ca> References: <474534909BE4064E853161350C47578E09C56B6D@ncrmail1.corp.navcan.ca> Message-ID: Hi Patrick, Paquette, Patrick writes: > > Actually, I think it should be pretty straightforward to extend XSD > > to automatically generate this code for C# classes. Maybe using > > partial classes or some such. > > Perhaps an implementation that involves performing the binary > serialization algorithm defined above as a subclass of > XmlWriter/XmlReader provided by the .NET framework, that way you don't > need to define a new language for the xsd compiler? Don't know which > would be easier for you. Because the binary format does not include meta-data (i.e., element and attribute names; which is one of the reasons it is faster than XML [binary or text]), one would still need to generate the C# code to perform extraction and forwarding to XmlWriter/XmlReader. But then, we might as well generate the extraction code directly to C# classes since going through XML will hurt performance. For example, an integer in XDR is already in binary so when we do XDR->C# we do binary to binary conversion. If we go though XML, we have binary to text (XDR->XML) and then text to binary (XML->C#) conversions, which seems quite wasteful to me. Boris From PaquetP at navcanada.ca Mon Jan 26 12:54:58 2009 From: PaquetP at navcanada.ca (Paquette, Patrick) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Efficient XML Interchange Format (Exi) Message-ID: <474534909BE4064E853161350C47578E09C56B71@ncrmail1.corp.navcan.ca> Hi Boris, > > Hi Patrick, > > Paquette, Patrick writes: > > > > Actually, I think it should be pretty straightforward to > extend XSD > > > to automatically generate this code for C# classes. Maybe using > > > partial classes or some such. > > > > Perhaps an implementation that involves performing the binary > > serialization algorithm defined above as a subclass of > > XmlWriter/XmlReader provided by the .NET framework, that > way you don't > > need to define a new language for the xsd compiler? Don't > know which > > would be easier for you. > > Because the binary format does not include meta-data (i.e., element > and attribute names; which is one of the reasons it is faster than > XML [binary or text]), one would still need to generate the C# code > to perform extraction and forwarding to XmlWriter/XmlReader. But then, > we might as well generate the extraction code directly to C# classes > since going through XML will hurt performance. > Of course. The recommendation is more along the lines of implementing a binary serializer/deserializer that works with existing .NET constructs to save time on implementing C# (or managed C++) bindings in CodeSynthesis XSD. As you're aware (but the reader might not be), a tool for .NET (http://msdn.microsoft.com/en-us/library/x6c1kb0s.aspx) exists to generate the code bindings to an XML schema already in the .NET SDK, but it would be usefull if it were more interoperable with bindings (ie binary serializers) generated from codesynthesis. By definition, it's already interoperable if the protocol is XML, but if we can do binary, then it's better. I thought the place to implement such serializers would be a subclass of XmlWriter/Reader - but it wouldn't. Other ideas (all dependent on using Microsofts XSD Schema Definition Tool): * Write a library that uses the .NET reflection API on the generated classes to perform the CodeSynthesis serialization algorithm on them in a generic way. * Write some classes that utilize the System.Runtime.Serialization namespace (http://msdn.microsoft.com/en-us/library/system.runtime.serialization.as px). Like writing a class that subclasses the Formatter class to serialize the way CodeSynthesis does, but on the classes generated by microsofts XSD compiler (ie: only serialize properties with the [XmlSerializable] attribute)? These are just places to look to research a way of reusing microsofts XSD compiler to expose CodeSythesis's binary protocols to .NET. But, doing it this way means it opens up developers to use other binding tools other than CodeSythesis, which probably isn't good for business ;) The idea about SWIG exposes the custom serialization algorithm to all languages it supports, which is better for CodeSythesis because it gets everybody using it. > For example, an integer in XDR is already in binary so when we do > XDR->C# we do binary to binary conversion. > have binary to text (XDR->XML) and then text to binary (XML->C#) > conversions, which seems quite wasteful to me. I agree - going binary, then to XML, then to C# classes would be innefficient. The recommendation above does not require this. > > Boris > > From a.omrani at gmail.com Mon Jan 26 12:23:32 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: <20090126151517.GA30691@karelia> References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> <20090126151517.GA30691@karelia> Message-ID: <183a50e60901260923v7814c8b2o8fa05fd2ac1e58c3@mail.gmail.com> Hello Boris, Thanks for you reply. I am sure the value of xsi:type is derived from SessionDescriptionBaseType. Amazingly, in order to make a small test case, when I was removing files from the VC++ project which were unrelated to this problem, after rebuiling the project, the error vanished! I have a schema file A1.xsd in which two schema files B.xsd and C.xsd are imported. I also have A2.xsd in which the schema files B.xsd and C.xsd are imported too. The schema structures of A1 and A2 are not the same but they have lots of types in common (i.e SessionDescriptionBaseType) but in different levels of the tree. the error I told you happened during parsing A1.xml. but when I remove A2.hxx and A2.cxx from the project, that mentioned error does not happen during parsing A1.xml!! Do you have any idea? I'm going to make a clear test case consisting of all those files to send to you. is that OK? Thank you Azadeh On Mon, Jan 26, 2009 at 6:45 PM, Boris Kolpackov wrote: > Hi Azadeh, > > Azadeh Omrani writes: > > > xsd::cxx::tree::not_derived at memory location 0x0012d5bc.." > > This exception means that the actual (dynamic) object type is not > derived from the (static) element type (SessionDescriptionBaseType, > in your case). Can you make sure that whatever type mentioned in > xsi:type is actually derived from SessionDescriptionBaseType? > > If that does not help, then I will need a small test case (i.e., > schema, test driver, and XML file) that reproduces the problem. > > Boris > From bpringle at sympatico.ca Mon Jan 26 13:52:58 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: Polymorphism enhancements. In-Reply-To: <20090109144623.GE29883@karelia> (Boris Kolpackov's message of "Fri, 9 Jan 2009 16:46:23 +0200") References: <874p1mledm.fsf@sympatico.ca> <20081202155906.GG1977@karelia> <87myfemj2d.fsf@sympatico.ca> <87k5aij9h9.fsf@sympatico.ca> <20081203081809.GG12327@karelia> <87zljcx335.fsf@sympatico.ca> <20081204142819.GA13539@karelia> <87iqpzeq4v.fsf_-_@sympatico.ca> <20081205084325.GC20354@karelia> <87mye3d5ls.fsf@sympatico.ca> <20090109144623.GE29883@karelia> Message-ID: <877i4hlx11.fsf@sympatico.ca> On 9 Jan 2009, boris@codesynthesis.com wrote: > Thanks for the feedback. My comments are below. >>> 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, >> >> >> >> >> >> >> >> >> >> >> 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? Sorry, I edited that email several times. I didn't compile it ;-) I was going to show the need to write, quaterino operator+(const quaterino &, int); quaterino operator+(int &, const quaterino&); If we don't have the conversion operator... but that is actually the int constructor that XSD generates. The need for the conversion function was to ful-fill other legacy requirements. I can not easily modify the other classes. The explicit conversion can be painful if you also wish to define conversion operators. Ie, 'operator int()'. This often leads to ambigious function calls as the compiler can pick multiple ways to match overloaded functions. You probably don't have many people doing this and they can just use the '--custom-type class=' syntax. > 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: > > We generate something like: > int foo_default_value_ = traits::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. Sounds much better than the idea I had. > 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? That is an excellent idea. I can see that someone might wish to have derived xsi:string values. However, the majority of people will just use one string type. Having auto_ptr variants of strings is not useful 99% of the time. It just generates extra code. I was lead to believe that the auto_ptr variants were to ease construction of composites. Ie, you build base complex types and use the auto_ptr variants to build up the higher level aggregate. This by itself is not really a good reason to do this. However, the use with polymorphism that you noted is. XSD must be using _clone and the auto_ptr variant to make this work in 'setXxxx'? That isn't obvious to a user of the tools. Would it be possible to detect the substition group to have this added automatically to the polymorphic type list? Hmmm. Actually that seems difficult as XSD has no idea that the base class is going to be extended. The abstract keyword is a very good clue for this though. Thanks again, Bill Pringlemeir. -- Someday we'll look back on all this and plow into a parked car. From boris at codesynthesis.com Mon Jan 26 13:52:19 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: <183a50e60901260923v7814c8b2o8fa05fd2ac1e58c3@mail.gmail.com> References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> <20090126151517.GA30691@karelia> <183a50e60901260923v7814c8b2o8fa05fd2ac1e58c3@mail.gmail.com> Message-ID: Hi Azadeh, Azadeh Omrani writes: > I have a schema file A1.xsd in which two schema files B.xsd and C.xsd are > imported. I also have A2.xsd in which the schema files B.xsd and C.xsd are > imported too. > > The schema structures of A1 and A2 are not the same but they have lots of > types in common (i.e SessionDescriptionBaseType) but in different levels > of the tree. > > the error I told you happened during parsing A1.xml. but when I remove > A2.hxx and A2.cxx from the project, that mentioned error does not happen > during parsing A1.xml!! If the types in A1.xsd and A2.xsd have the same name and the same XML namespace, then that would explain your problem. To implement support for polymorphism, XSD maintains a type map where every type is registered. The key in this map is type's qualified name (name + XML namespace). So if you have two schemas that have the same type in the same XML namespace, even though they may be mapped to two different C++ classes, they will conflict in that map. Internally, we have support for what we call "plates" where two sets of schemas can be compiled to use two different type maps. However, this mechanism is not yet exposed to the user since the situations where it would be needed are quite rare. > I'm going to make a clear test case consisting of all those files to > send to you. is that OK? If the above analysis is correct then I don't think it is necessary. It is quite clear what's going on now. Boris From bpringle at sympatico.ca Mon Jan 26 14:15:37 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Obscure problem with inlines and custom types. Message-ID: <873af5lvza.fsf@sympatico.ca> If you have a custom type that converts from one type to another, this can cause problems with the XSD generated inlines. [primary.xsd] [composite.xsd] ... [composite2.xsd] ... [secondary.xsd] Then 'CompositeWrapper.h' #include "secondary.h" class Composite : public Composite_base ... public: Secondary toSecondary(); Composite is a wrapped class. Including any generated XSD headers inside of the wrapper class when --hxx-epilogue is used can result in missing 'ixx' files. The end of composite.cxx will look like, #ifndef XSD_DONT_INCLUDE_INLINE #include "primary.ixx" #endif // XSD_DONT_INCLUDE_INLINE // Begin epilogue. // #include "CompositeWrapper.h" // // End epilogue. A work around is to alway include the 'converted' class in the composite file. Ie, include secondary.xsd even though the schema (composite.xsd) doesn't use it. Otherwise, including composite2.h will result in the secondary.ixx *not* being emitted and undefined externals can result. It seems possible that an additional XSD_IN_EPLIOGUE (along with standard header gaurds) can be used to check for this condition and warn the user. Ie, #ifndef SECONDARY_H #define SECONDARY_H #if defined(XSD_IN_EPLIOGUE) && defined(XSD_DONT_INCLUDE_INLINE) #error Huston we have a problem. #endif ... Fwiw, Bill Pringlemeir. From a.omrani at gmail.com Mon Jan 26 14:04:52 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> <20090126151517.GA30691@karelia> <183a50e60901260923v7814c8b2o8fa05fd2ac1e58c3@mail.gmail.com> Message-ID: <183a50e60901261104i4ef7e497nb2524dfa43dccae8@mail.gmail.com> No the types in A1.xsd and A2.xsd have not the same XML namespace. but they have the same name. is there any other reason for that strange problem you think? From boris at codesynthesis.com Mon Jan 26 14:50:45 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: <183a50e60901261104i4ef7e497nb2524dfa43dccae8@mail.gmail.com> References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> <20090126151517.GA30691@karelia> <183a50e60901260923v7814c8b2o8fa05fd2ac1e58c3@mail.gmail.com> <183a50e60901261104i4ef7e497nb2524dfa43dccae8@mail.gmail.com> Message-ID: Hi Azadeh, Azadeh Omrani writes: > No the types in A1.xsd and A2.xsd have not the same XML namespace. > but they have the same name. > > is there any other reason for that strange problem you think? No, if the targetNamespace attributes in A1.xsd and A2.xsd are different, then there is something else going on. Can you send the test case? Boris From delta42 at gmail.com Mon Jan 26 17:35:16 2009 From: delta42 at gmail.com (delta42) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Deleting empty elements Message-ID: <7f9416a70901261435k40c75933o3afe50c3e60fdaf6@mail.gmail.com> Hello, I've been working with the CodeSynthesis C++/Tree Mapping on a project for the last few months. It took me a while to get things going as I have over 8MB of schema files. Due to the complexity of the hierarchy, when creating a new XML document I often find it cleaner to code by adding elements before I know whether these elements will have any sub-elements. So naturally in some cases when I serialize I end up with many empty elements. Is there an easy way to have these removed prior to serializing to a stringstream? Or do I have to first serialize them to a stringstream and then pass them to Xerces directly and somehow traverse all the elements to deal with this? Thanks in advance, delta42. From boris at codesynthesis.com Tue Jan 27 09:18:01 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Deleting empty elements In-Reply-To: <7f9416a70901261435k40c75933o3afe50c3e60fdaf6@mail.gmail.com> References: <7f9416a70901261435k40c75933o3afe50c3e60fdaf6@mail.gmail.com> Message-ID: Hi, delta42 writes: > Due to the complexity of the hierarchy, when creating a new XML document > I often find it cleaner to code by adding elements before I know whether > these elements will have any sub-elements. So naturally in some cases when I > serialize I end up with many empty elements. > > Is there an easy way to have these removed prior to serializing to a > stringstream? Or do I have to first serialize them to a stringstream and > then pass them to Xerces directly and somehow traverse all the elements to > deal with this? You can serialize the object model to the DOM document first. This way you can traverse the document and remove all empty elements. After that you can serialize the DOM document to stringstream (there is sample code in the FAQ[1] on how to do this). The function which cleans up empty elements could look like this (haven't tested): void remove_empty_elements (DOMElement* e) { for (DOMNode* n = e->getFirstChild (); n != 0; ) { if (n->getNodeType () == DOMNode::ELEMENT_NODE) { DOMElement* ne = static_cast (n); n = n->getNextSibling (); if (ne->getFirstChild () == 0) { if (ne->getAttributes ().getLength () == 0) { e->removeChild (ne); ne->release (); } } else remove_empty_elements (ne); } else n = n->getNextSibling (); } } DOMDocument* doc = ... // Serialize object model to DOM remove_empty_elements (doc->getDocumentElement ()); [1] http://wiki.codesynthesis.com/Tree/FAQ Boris From boris at codesynthesis.com Tue Jan 27 09:39:03 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Obscure problem with inlines and custom types. In-Reply-To: <873af5lvza.fsf@sympatico.ca> References: <873af5lvza.fsf@sympatico.ca> Message-ID: <20090127143903.GA15685@karelia> Hi Bill, Bill Pringlemeir writes: > #ifndef XSD_DONT_INCLUDE_INLINE > > #include "primary.ixx" > > #endif // XSD_DONT_INCLUDE_INLINE > > // Begin epilogue. > // > #include "CompositeWrapper.h" > // > // End epilogue. Hm, that's unfortunate. We have all this XSD_DONT_INCLUDE_INLINE machinery to support schemas with include cycles. The proper solution would be to undefine this macro in prologues and epilogues, something along these lines: #ifdef XSD_DONT_INCLUDE_INLINE # undef XSD_DONT_INCLUDE_INLINE # define RESTORE_XSD_DONT_INCLUDE_INLINE #endif // Begin epilogue. // #include "CompositeWrapper.h" // // End epilogue. #ifdef RESTORE_XSD_DONT_INCLUDE_INLINE # define XSD_DONT_INCLUDE_INLINE #endif We will also probably need to use a header-specific RESTORE_* macro name to make sure it works when there are several levels of this. But then, it all looks very ugly so I am not sure we should do this. Maybe we should analyze the schemas and only use DONT_INCLUDE_INLINE when it is actually necessary. Then we can go all the way. BTW, an easier work around would be to include the .ixx file right after the header in CompositeWrapper.h: #include "secondary.h" #include "secondary.ixx" Thanks for reporting this! Boris From stefan.weber at efgfp.com Tue Jan 27 10:05:03 2009 From: stefan.weber at efgfp.com (WEBER Stefan) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Customize sequence and optionals Message-ID: Hi, so far I could successfully customize the mapping to suit my needs. Now, I ran into problems with optionals and sequences. In my schema, the reason to make some elements optional is mostly for convenience of the user writing the XML, such that the user does not have to explicitly specify the element in case he wants to use the default value anyway. (e.g. for configuration data) Now I would like to change the optional type such that whenever get() would return a NULL pointer, I create an element of the default value and return the newly created element. In other words, instead of having a typedef xsd::cxx::tree::optional MyTypeOptional I would rather provide a custom MyTypeOptional. Is this possible? A similar thing for the sequences: instead of having generated a typedef xsd::cxx::tree::sequence MyTypeSequence I would rather provide a MyTypeSequence myself. The reason I want to do that is that I would prefer to have a vector as return value rather than sequence for sequences (because an 3rd party API expects a const vector& and providing a custom sequence would save a lot of explicit conversions). Thanks, Stefan ==== The EFG Mail Gateway made the following annotation ===== This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the EFG Financial Products Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the EFG Financial Products Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.efgfp.com. If you suspect that the message may have been intercepted or amended, please call the sender. Should you require any further information, please contact the Compliance Manager on compliance@efgfp.com. ============================================================= From boris at codesynthesis.com Tue Jan 27 12:40:55 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> <20090126151517.GA30691@karelia> <183a50e60901260923v7814c8b2o8fa05fd2ac1e58c3@mail.gmail.com> <183a50e60901261104i4ef7e497nb2524dfa43dccae8@mail.gmail.com> Message-ID: Hi Azadeh, I took a look at your files. Both acquisition.xsd and esg.xsd have the same target namespace, namely urn:dvb:ipdc:esg:2005. They also define a number of types with the same name. This is exactly the problem I described a couple of emails back, see: http://www.codesynthesis.com/pipermail/xsd-users/2009-January/002160.html I am not sure why you have two schemas with the same target namespace defining duplicate types. Normally that would mean something is wrong with the schema design. Can you factor them out into a common schema and then include this schema in acquisition.xsd and esg.xsd? Boris From delta42 at gmail.com Tue Jan 27 13:39:52 2009 From: delta42 at gmail.com (delta42) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Deleting empty elements Message-ID: <7f9416a70901271039u16d120f7vf1ae1f502c698a35@mail.gmail.com> > You can serialize the object model to the DOM document first. This > way you can traverse the document and remove all empty elements. > After that you can serialize the DOM document to stringstream > (there is sample code in the FAQ[1] on how to do this). Thank you very much Boris, you set me on the right track. I did not find a definition for DomWriter in my* \CodeSynthesis XSD 3.2\include\xercesc* folders so I adapted the sample code to work with the DOMLSSerializer, as such: SerializeDOMtoXMLFormatTarget(xercesc::XMLFormatTarget& target, const xercesc::DOMDocument& doc, const std::string& encoding/*= "UTF-8"*/) { using namespace xercesc; namespace xml = xsd::cxx::xml; namespace tree = xsd::cxx::tree; const XMLCh ls_id [] = {chLatin_L, chLatin_S, chNull}; // Get an implementation of the Load-Store (LS) interface. // DOMImplementation* impl(DOMImplementationRegistry::getDOMImplementation(ls_id)); // Create a DOMLSSerializer. // xml::dom::auto_ptr writer(impl->createLSSerializer ()); DOMConfiguration* conf(writer->getDomConfig ()); // Set error handler. // tree::error_handler eh; xml::dom::bits::error_handler_proxy ehp (eh); conf->setParameter(XMLUni::fgDOMErrorHandler, &ehp); // Set some nice features if the serializer supports them. // if (conf->canSetParameter(XMLUni::fgDOMWRTDiscardDefaultContent, true)) conf->setParameter(XMLUni::fgDOMWRTDiscardDefaultContent, true); if (conf->canSetParameter(XMLUni::fgDOMWRTFormatPrettyPrint, true)) conf->setParameter (XMLUni::fgDOMWRTFormatPrettyPrint, true); if (conf->canSetParameter(XMLUni::fgDOMXMLDeclaration, true)) conf->setParameter(XMLUni::fgDOMXMLDeclaration, true); xml::dom::auto_ptr out(impl->createLSOutput()); out->setEncoding(xml::string (encoding).c_str()); out->setByteStream(&target); bool ret = writer->write(&doc, out.get()); eh.throw_if_failed > (); } and this work very well so far (I don't really care if the final output is a MemBufFormatTarget or a stringstream, I just need access to the bytes, as in void*). Thanks also for the remove_empty_elements, this worked perfectly. The only changes I made is to have remove_empty_elements return the number of elements it changed, and I added another function: remove_all_empty_elements { while (remove_empty_elements(e)); } Like this I can iterate to remove the empty items that have been revealed by the previous removal pass. For example, my current example looks like this (after renaming my tags): After the first pass I have: then: etc., etc., until this whole node disappears in 3 more passes. I'm not sure if there's a faster/better way to do this or not, but it is not taking any "noticeable" time on my PC, so this is good. Validation is another story for me, I find it takes forever, as in 10 seconds (E6600 processor/WinXP), but I suspect most of that time is parsing my huge amount of schemas, so when I get a chance I may cache the schemas in advance, or even implement the binary grammar object that I read about on your forum lately. Thank you once again Boris for your dedication to this wonderful project, delta42. From boris at codesynthesis.com Wed Jan 28 02:30:55 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Customize sequence and optionals In-Reply-To: References: Message-ID: Hi Stefan, WEBER Stefan writes: > In my schema, the reason to make some elements optional is mostly for > convenience of the user writing the XML, such that the user does not > have to explicitly specify the element in case he wants to use the > default value anyway. (e.g. for configuration data) Just as an aside, elements with default values in XML Schema are quite a strange construct. You cannot simply ommit an element with a default value. Rather, you will need to specify an empty element in order for it to have the default value. For example: This is invalid: This is valid and the value of 'a' is 123: So am not sure how convenient elements with default values will be in your situation. Attributes, on the other hand, have a more "sane" behavior in that if an optional attribute with default value is not present, then the attribute takes the default value. See Appendix A, "Default and Fixed Values" in the C++/Tree Mapping User Manual for more information. For an attribute with a default value XSD generates accessor/modifier functions as if it was required and automatically initializes it to the default value when it is not present. > Now I would like to change the optional type such that whenever get() > would return a NULL pointer, I create an element of the default value > and return the newly created element. > > In other words, instead of having a > > typedef xsd::cxx::tree::optional MyTypeOptional > > I would rather provide a custom MyTypeOptional. Is this possible? The only way to do this would be to customize the outer type that contains MyTypeOptional and redefine the typedef's and functions for elements with default values. For example, you could base your custom implementation on the generated version and then do something like this: class Outer: OuterBase { MyType& my () { MyTypeOptional& x = OuterBase::my (); if (x.present ()) return x.get (); else { // Return default value. } } }; If you have a lot of such elements scattered over many types, then this may require quite a bit of customization. > A similar thing for the sequences: > > instead of having generated a > > typedef xsd::cxx::tree::sequence MyTypeSequence > > I would rather provide a MyTypeSequence myself. The reason I want to do > that is that I would prefer to have a vector as return value > rather than sequence for sequences (because an 3rd party API > expects a const vector& and providing a custom sequence would save a lot > of explicit conversions). Again, you will need to customize the outer type for that. Also note that std::vector will store MyType by value which may be quite expensive. Boris From stefan.weber at efgfp.com Wed Jan 28 02:56:02 2009 From: stefan.weber at efgfp.com (WEBER Stefan) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Customize sequence and optionals In-Reply-To: References: Message-ID: Hi Boris, > Just as an aside, elements with default values in XML Schema > are quite a strange construct. You cannot simply ommit an > element with a default value. Rather, you will need to > specify an empty element in order for it to have the default value. > [...] > So am not sure how convenient elements with default values > will be in your situation. Thanks for the example. This is exactly the reason why I don't want to enforce the defaults by the schema, but by a preprocessor that creates an empty element whenever the optional element was not specified. This frees the consumer of the preprocessed object model to check for presence before each and every access. Now with customizing the standard optional behavior, I could get rid of the explicit preprocessing. > > Now I would like to change the optional type such that > whenever get() > > would return a NULL pointer, I create an element of the > default value > > and return the newly created element. > > > > In other words, instead of having a > > > > typedef xsd::cxx::tree::optional MyTypeOptional > > > > I would rather provide a custom MyTypeOptional. Is this possible? > > The only way to do this would be to customize the outer type > that contains MyTypeOptional and redefine the typedef's and > functions for elements with default values. Thanks for the hint. This indeed will require quite a bit of customization, I'll need to check whether this is worth it. The main concern I have with this is that it makes me redefine a non-virtual function coming from OuterBase... Stefan ==== The EFG Mail Gateway made the following annotation ===== This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the EFG Financial Products Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the EFG Financial Products Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.efgfp.com. If you suspect that the message may have been intercepted or amended, please call the sender. Should you require any further information, please contact the Compliance Manager on compliance@efgfp.com. ============================================================= From boris at codesynthesis.com Wed Jan 28 03:16:58 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Customize sequence and optionals In-Reply-To: References: Message-ID: Hi Stefan, WEBER Stefan writes: > Thanks for the hint. This indeed will require quite a bit of > customization, I'll need to check whether this is worth it. The main > concern I have with this is that it makes me redefine a non-virtual > function coming from OuterBase... Another, probably easier, approach would be to customize the parsing constructor for Outer. In it you will fist call the OuterBase version and then initialize the missing optional elements with default value. This way you won't need to "hide" any functions. The only drawback of this approach is that the user of your object model will still have to go though the optional interface though the check for presence is no longer necessary. Boris From stefan.weber at efgfp.com Wed Jan 28 04:34:19 2009 From: stefan.weber at efgfp.com (WEBER Stefan) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Customize sequence and optionals In-Reply-To: References: Message-ID: Hi Boris, > Another, probably easier, approach would be to customize the > parsing constructor for Outer. In it you will fist call the > OuterBase version and then initialize the missing optional > elements with default value. > This way you won't need to "hide" any functions. The only > drawback of this approach is that the user of your object > model will still have to go though the optional interface > though the check for presence is no longer necessary. That's another good idea, thanks a lot--however this only works for the optionals, not for the sequences. Another possibility to avoid hiding functions is to specify a regex for the accessors and modifiers of the optionals/sequences. Stefan ==== The EFG Mail Gateway made the following annotation ===== This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the EFG Financial Products Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the EFG Financial Products Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.efgfp.com. If you suspect that the message may have been intercepted or amended, please call the sender. Should you require any further information, please contact the Compliance Manager on compliance@efgfp.com. ============================================================= From boris at codesynthesis.com Wed Jan 28 10:32:41 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Deleting empty elements In-Reply-To: <7f9416a70901271039u16d120f7vf1ae1f502c698a35@mail.gmail.com> References: <7f9416a70901271039u16d120f7vf1ae1f502c698a35@mail.gmail.com> Message-ID: <20090128153241.GA26221@karelia> Hi, delta42 writes: > I did not find a definition for DomWriter in my* \CodeSynthesis XSD > 3.2\include\xercesc* folders so I adapted the sample code to work with > the DOMLSSerializer, as such: The sample code in the FAQ was for Xerces-C++ 2-series. I've updated it to include a version that works for both 2 and 3-series (XSD 3.2.0 ships with Xerces-C++ 3.0.0). > I'm not sure if there's a faster/better way to do this or not, but it is not > taking any "noticeable" time on my PC, so this is good. I think the following version will do the same much faster: void remove_empty_elements (DOMElement* e) { for (DOMNode* n = e->getFirstChild (); n != 0; ) { if (n->getNodeType () == DOMNode::ELEMENT_NODE) { DOMElement* ne = static_cast (n); n = n->getNextSibling (); if (ne->getFirstChild () != 0) remove_empty_elements (ne); if (ne->getFirstChild () == 0 && ne->getAttributes ().getLength () == 0) { e->removeChild (ne); ne->release (); } } else n = n->getNextSibling (); } } > Validation is another story for me, I find it takes forever, as in > 10 seconds (E6600 processor/WinXP), but I suspect most of that time > is parsing my huge amount of schemas, so when I get a chance I may > cache the schemas in advance, or even implement the binary grammar > object that I read about on your forum lately. Yes, that sounds like a good idea. The 'caching' example shows how to pre-load the schemas and reuse them to parse several documents. Boris From a.omrani at gmail.com Wed Jan 28 10:16:40 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] abstract types access In-Reply-To: References: <183a50e60901080251o8d71928pe6323ca33faab241@mail.gmail.com> <20090108113655.GA10046@karelia> <183a50e60901260443medf1064u36424ecdad67f4@mail.gmail.com> <20090126151517.GA30691@karelia> <183a50e60901260923v7814c8b2o8fa05fd2ac1e58c3@mail.gmail.com> <183a50e60901261104i4ef7e497nb2524dfa43dccae8@mail.gmail.com> Message-ID: <183a50e60901280716n39a11744j5578346ef2ca350f@mail.gmail.com> Thanks Boris for your previous hints. I change my program plan to comply with your suggestions and it worked :) From a.omrani at gmail.com Wed Jan 28 10:42:37 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] support for deviations from XML schema Message-ID: <183a50e60901280742w262a1d38gd4bc0017ac0aa763@mail.gmail.com> Hi, As far as I know for a program that uses XSD to work, it is necessary for the xml instance file(which is going to be parsed) to comply with the corresponding xml schema. assume that we can make static changes in the schema file (before compilation). but the xml file is out of reach to make changes in it. imagine a case an xml file is to be parsed with some small deviations from the precompiled schema. deviations like: 1-in the schema there is a complextype which has a sequence of ordered elements each having an unbounded cardinality, but in xml file those elements are not in order. (that problem will not be solved with a change in the schema from 'sequence' to 'all') 2-in the xml file, there are some elements which have typos in the element or attribute names 3- There are some required elements or attributes missing. at first sight the program will not work because the xml file can not be parsed. Is there any solution for each case of mentioned deviations? In a way that either the schema file can be changed to maintain some more flexibility ( in case 1) or the XSD xml parser can handle the situation and parse the rest of xml elements and ignore the typos or deviations without interrupting( in case 2 and 3)...? Thank you Azadeh From bkuschak at yahoo.com Wed Jan 28 15:52:52 2009 From: bkuschak at yahoo.com (Brian Kuschak) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] xsd build failure: g++ internal compiler error Message-ID: <426791.47277.qm@web38903.mail.mud.yahoo.com> I've seen some postings on the list regarding g++ compiler crashing when building libcult. Does anyone have a workaround, other than installing a new compiler? Thx. -Brian g++ (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13) GNU ld version 2.17.50.0.6-5.fc6 20061020 g++ -I/data/brian/work/build/libcult-native/libcult-1.4.2/cult/arch/i386/i486/i586/i686 -I/data/brian/work/build/libcult-native/libcult-1.4.2/cult/arch/i386/i486/i586 -I/data/brian/work/build/libcult-native/libcult-1.4.2/cult/arch/i386/i486 -I/data/brian/work/build/libcult-native/libcult-1.4.2/cult/arch/i386 -I/data/brian/work/build/libcult-native/libcult-1.4.2/cult/arch/generic -I/data/brian/work/build/libcult-native/libcult-1.4.2 -I/data/brian/work/build/libcult-native/libcult-1.4.2 -O2 -g -fPIC -o /data/brian/work/build/libcult-native/libcult-1.4.2/cult/eh/exception.o -c /data/brian/work/build/libcult-native/libcult-1.4.2/cult/eh/exception.cxx /data/brian/work/build/libcult-native/libcult-1.4.2/cult/eh/exception.cxx:27: internal compiler error: Segmentation fault From stefan.weber at efgfp.com Thu Jan 29 03:40:51 2009 From: stefan.weber at efgfp.com (WEBER Stefan) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Customize sequence and optionals In-Reply-To: References: Message-ID: Hi Boris, > > In my schema, the reason to make some elements optional is > mostly for > > convenience of the user writing the XML, such that the user > does not > > have to explicitly specify the element in case he wants to use the > > default value anyway. (e.g. for configuration data) > > [...] > > So am not sure how convenient elements with default values > will be in your situation. Because the element defaults are not very useful in XML schema, I implement this separately. I'm doing something like this: template void createIfNotPresent(Optional& optionalType) { if(!optionalType) { optionalType.set( std::auto_ptr(new NonOptional())); } } The call to this is a bit ugly because I don't know how to derive the NonOptional type from the Optional, e.g.: MyOptionalType myOptional; createIfNotPresent(myOptional); Isn't there a way to access the optionals containing type given the optional one? Such that I could do something like: template void createIfNotPresent(Optional& optionalType) { if(!optionalType) { optionalType.set( std::auto_ptr(new Optional::type())); } } This would be much more convenient but I could not find a typedef in the declaration of optional that seems to allow this. Is there still a way to derive the non optional type from the optional container? Thanks, Stefan ==== The EFG Mail Gateway made the following annotation ===== This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the EFG Financial Products Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the EFG Financial Products Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.efgfp.com. If you suspect that the message may have been intercepted or amended, please call the sender. Should you require any further information, please contact the Compliance Manager on compliance@efgfp.com. ============================================================= From boris at codesynthesis.com Thu Jan 29 04:06:51 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Customize sequence and optionals In-Reply-To: References: Message-ID: Hi Stefan, WEBER Stefan writes: > Isn't there a way to access the optionals containing type given the > optional one? Such that I could do something like: > > template > void createIfNotPresent(Optional& optionalType) { > if(!optionalType) { > optionalType.set( std::auto_ptr(new > Optional::type())); > } > } You can do it like this: template struct DefValueFactory; template struct DefValueFactory > { typedef xsd::cxx::tree::optional Optional; void set (Optional& x) { if (!x) x.set (std::auto_ptr (new T ()); } }; template struct DefValueFactory > { typedef xsd::cxx::tree::optional Optional; void set (Optional& x) { if (!x) x.set (T ()); } }; template void createIfNotPresent (Optional& optionalType) { DefValueFactory::set (optionalType); } The second template argument to tree::optional indicates whether T is a fundamental C++ type (e.g., int, double, etc.). For these types there is no auto_ptr version in the optional container. Boris From boris at codesynthesis.com Thu Jan 29 09:32:41 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] support for deviations from XML schema In-Reply-To: <183a50e60901280742w262a1d38gd4bc0017ac0aa763@mail.gmail.com> References: <183a50e60901280742w262a1d38gd4bc0017ac0aa763@mail.gmail.com> Message-ID: Hi Azadeh, Azadeh Omrani writes: > As far as I know for a program that uses XSD to work, it is necessary for > the xml instance file(which is going to be parsed) to comply with the > corresponding xml schema. The C++/Tree mapping uses XML Schema validation support from the underlying XML parser (Xerces-C++). The generated code itself performs minimal validation. Its only goal is to create a usable object model. For example, if a required element is not present in XML, then the object model will be unusable since if you try to access the element's value, you will end up with access violation and there is no way to check whether the value is present. As a result, the generated code catches this case. So, if you disable full validation against XML Schema (the dont_validate flag), then the parsing will be very lax as long as there are values for required attributes. In particular, the generated parsing code does not care about element order as long as there is no inheritance involved (if there is inheritance, then the base type will stop parsing as soon as it detects first unknown element). > assume that we can make static changes in the schema file (before > compilation). but the xml file is out of reach to make changes in it. Normally, if you want to make your schema as loose as possible, you would change all required elements/attributes to be optional. You can also add some wildcards (xs:any and xs:anyAttribute) to match misspelled elements and attributes. > 1-in the schema there is a complextype which has a sequence of ordered > elements each having an unbounded cardinality, but in xml file those > elements are not in order. This will work as long as you disable XML Schema validation and there is no inheritance. You can also change your schema to allow this: > 2-in the xml file, there are some elements which have typos in the > element or attribute names See above. Plus you can add wildcards to match them (obviously there is no magical solution to figure out the implied element name and parser it as such). > 3- There are some required elements or attributes missing. You will have to relax the schema for that. > Is there any solution for each case of mentioned deviations? In a way that > either the schema file can be changed to maintain some more flexibility ( in > case 1) or the XSD xml parser can handle the situation and parse the rest of > xml elements and ignore the typos or deviations without interrupting( in > case 2 and 3)...? If none of the above helps, you can always customize the generated types and implement custom parsing. This way you can be as flexible as you like. Boris From boris at codesynthesis.com Thu Jan 29 09:41:12 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] xsd build failure: g++ internal compiler error In-Reply-To: <426791.47277.qm@web38903.mail.mud.yahoo.com> References: <426791.47277.qm@web38903.mail.mud.yahoo.com> Message-ID: <20090129144112.GA2934@karelia> Hi Brian, Brian Kuschak writes: > I've seen some postings on the list regarding g++ compiler crashing > when building libcult. Does anyone have a workaround, other than > installing a new compiler? Yes, disabling debug helps. You can just edit libcult-1.4.2/build/cxx/configuration-dynamic.make And change cxx_debug:=y to cxx_debug:=n Boris From a.omrani at gmail.com Thu Jan 29 10:50:09 2009 From: a.omrani at gmail.com (Azadeh Omrani) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Serialization problem Message-ID: <183a50e60901290750y40fe271n6ccc9eb18e0b4ef5@mail.gmail.com> Hi, In Tree mapping, my program parses the xml instance successfully to the object model. When I serialize it (without any changes) to a file again, it has some elements missing data(empty elements) and even it has eliminated some required attributes. Why do you think is that? Thank you Azadeh From boris at codesynthesis.com Thu Jan 29 14:47:17 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Serialization problem In-Reply-To: <183a50e60901290750y40fe271n6ccc9eb18e0b4ef5@mail.gmail.com> References: <183a50e60901290750y40fe271n6ccc9eb18e0b4ef5@mail.gmail.com> Message-ID: Hi Azadeh, Azadeh Omrani writes: > When I serialize it (without any changes) to a file again, it has some > elements missing data(empty elements) and even it has eliminated some > required attributes. > Why do you think is that? Will need to see the schema, sample XML, and test driver to say for sure. Can you email me these so I can take a look? Boris From akramsaye at yahoo.se Fri Jan 30 06:57:47 2009 From: akramsaye at yahoo.se (Akram Saye) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Question about xml serialization Message-ID: <281883.76025.qm@web25501.mail.ukl.yahoo.com> Hello Boris! I have a question about xml serialization. My program worked find before. But I did not why ?Segmentation Fault (core dumped)? Or I get ?4) AdjCtcService:: handle_input(): :11:31 error: Expected end of tag 'POSITION_TRACK' Pure virtual function called? When I run the debug it says:? t@3 (l@3) terminated by signal ABRT (Abort) 0xfeec642c: __lwp_kill+0x0008:? bcc,a,pt? %icc,__lwp_kill+0x18? ! 0xfeec643c Current function is xsd::cxx::xml::dom::serialize ? 159???????????? DOMImplementation* impl ( (dbx) where current thread: t@3 dbx: can't find definition for symbol 'namespace_infomap ? [1] __lwp_kill(0x0, 0x6, 0xfe989fcc, 0xad260, 0xfeef12d8, 0x0), at 0xfeec642c ? [2] raise(0x6, 0x0, 0xfeef2e18, 0xfe989804, 0xffffffff, 0x6), at 0xfee64e14 ? [3] abort(0x149714, 0x1, 0xfe989fcc, 0xad260, 0xfeef12d8, 0x0), at 0xfee41198 ? [4] xercesc_2_8::DOMImplementationImpl::getDOMImplementation(0x149714, 0xfe57af1e, 0xfeb74d30, 0xfeb74d30, 0xa00, 0x800), at 0xfe989804 ? [5] xercesc_2_8::DOMImplementationRegistry::getDOMImplementation(0xfe57af1e, 0x126778, 0x0, 0xfe989904, 0x149718, 0xfeb8b22c), at 0xfe989fcc =>[6] xsd::cxx::xml::dom::serialize(el = CLASS, ns = CLASS, , line 159 in "serialization-source.txx" ? [7] xsd::cxx::xml::dom::serialize(root_element = 0x107bbe "TRAININFO", root_element_namespace = 0x107bc8 "", map = STRUCT, flags = 0), line 97 in "serialization-source.hxx" ? [8] TRAININFO_(s = CLASS, m = STRUCT, f = CLASS), line 1370 in "TrainPositionInfo.cpp" ? [9] TRAININFO_(o = CLASS, s = CLASS, m = STRUCT, e = CLASS, f = CLASS), line 1240 in "TrainPositionInfo.cpp" ? [10] Eis::SystemModule::MysHandler::MysHandlerSerializeXmlMsg(this = 0x12ce10, msg = CLASS), line 186 in "MysHandler.cpp"? In my MysHandler::MysHandlerSerializeXmlMsg function I have this code. string MysHandler::MysHandlerSerializeXmlMsg(const Myclass& msg) ?? ???? { ?? ?????? // Declare and initialize the Infomap for serialization. ?? ?????? xml_schema::namespace_infomap map; ?? ?????? //map[""].name = "http://www.bombardier.com/rcs/3NSS007094D0008"; ?? ?????? map[""].schema = "../xml/test.xsd"; ?? ?????? // Serialize. ?? ?????? std::ostringstream sxml; ?? ?????? try ?? ?????? { ?? ???????? //TRAININFO_( sxml,msg, map, "ISO8859-1"); ? ?? ??? ??? ?TRAININFO_(sxml, msg, map, "utf-8"); ?? ?????? } ?? ?????? catch (const xml_schema::no_namespace_mapping& e) ?? ?????? { ?? ???????? ACE_DEBUG ?? ?????????? ((LM_DEBUG, ACE_TEXT("(%t) MysHandler:: serializeMsg(): %s\n%s\n"), ?? ???????????? e.namespace_().c_str(), ?? ???????????? boost::lexical_cast(e).c_str() ?? ?????????? )); ?? ?????? } ?? ?????? catch (const xml_schema::exception& e) ?? ?????? { ?? ???????? ACE_DEBUG ?? ?????????? ((LM_DEBUG, ACE_TEXT("(%t) MysHandler:: serializeMsg(): %s\n"), ?? ???????????? boost::lexical_cast(e).c_str() ?? ?????????? )); ?? ?????? } ?? ?????? // Return the resulting string. ?? ?????? return sxml.str(); ?? ???? } Could you be nice and answer me where I do wrong. I have no namespace in my xml file. thank you for? your answer. __________________________________________________________ Ta semester! - s?k efter resor hos Kelkoo. J?mf?r pris p? flygbiljetter och hotellrum h?r: http://www.kelkoo.se/c-169901-resor-biljetter.html?partnerId=96914052 From delta42 at gmail.com Thu Jan 29 17:25:56 2009 From: delta42 at gmail.com (delta42) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Deleting empty elements In-Reply-To: <20090128153241.GA26221@karelia> References: <7f9416a70901271039u16d120f7vf1ae1f502c698a35@mail.gmail.com> <20090128153241.GA26221@karelia> Message-ID: <7f9416a70901291425x73e00067mc69cc11bb81d1c6@mail.gmail.com> > > >> I think the following version will do the same much faster: This is the same source example you gave me before, but this will only remove the empty tags, not the tags that become empty *after* you delete all the empty tags. For example, with Only the tag is empty, so only it will get deleted by your functions. However, after it gets deleted, you are left with so *now* there is another empty tag, hence my iteration over the entire set until no more changes are visible. From boris at codesynthesis.com Fri Jan 30 13:36:34 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Deleting empty elements In-Reply-To: <7f9416a70901291425x73e00067mc69cc11bb81d1c6@mail.gmail.com> References: <7f9416a70901271039u16d120f7vf1ae1f502c698a35@mail.gmail.com> <20090128153241.GA26221@karelia> <7f9416a70901291425x73e00067mc69cc11bb81d1c6@mail.gmail.com> Message-ID: Hi, delta42 writes: > This is the same source example you gave me before The two versions look very similar but there is a different. The original[1] version was checking if the element is empty and then processing its children. The second version[2] first processes element's children and then checks if it is empty. This way, if children are empty, they will be removed first. [1] http://www.codesynthesis.com/pipermail/xsd-users/2009-January/002165.html [2] http://www.codesynthesis.com/pipermail/xsd-users/2009-January/002174.html Boris From delta42 at gmail.com Fri Jan 30 14:03:15 2009 From: delta42 at gmail.com (delta42) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Deleting empty elements In-Reply-To: References: <7f9416a70901271039u16d120f7vf1ae1f502c698a35@mail.gmail.com> <20090128153241.GA26221@karelia> <7f9416a70901291425x73e00067mc69cc11bb81d1c6@mail.gmail.com> Message-ID: <7f9416a70901301103g69e74b87k63cf4062227b0c14@mail.gmail.com> > > The two versions look very similar but there is a different. > The original[1] version was checking if the element is empty > and then processing its children. > > The second version[2] first processes element's children > and then checks if it is empty. This way, if children are > empty, they will be removed first. > > > [1] > http://www.codesynthesis.com/pipermail/xsd-users/2009-January/002165.html > [2] > http://www.codesynthesis.com/pipermail/xsd-users/2009-January/002174.html > Yes! You are right of course, it makes sense to me now. I had not noted the difference. Thanks again.