From boris at codesynthesis.com Mon Feb 2 05:54:44 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Question about xml serialization In-Reply-To: <281883.76025.qm@web25501.mail.ukl.yahoo.com> References: <281883.76025.qm@web25501.mail.ukl.yahoo.com> Message-ID: Hi Akram, Akram Saye writes: > My program worked find before. But I did not why Segmentation Fault > (core dumped). I took a look at your code fragment but don't see anything that could cause this. It looks like something is corrupting application memory. Is your application multi-threaded? In other words, are you calling MysHandlerSerializeXmlMsg (or code that does XML parsing) from multiple threads? Boris From stefan.weber at efgfp.com Mon Feb 2 10:48:09 2009 From: stefan.weber at efgfp.com (WEBER Stefan) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Code generation error when using doubles and attributes (?) Message-ID: Hi, I have the following schema: This all worked fine when I used xs:float rather than xs:double as a base type of "Bar". However, with xs:double, there seems to be a problem/bug: When I want to access the value as follows: Foo foo; //... cout << foo.bar(); I get a completely different number than the one in the XML document. I tried to trace down the issue and found that double traits::create returns the correct value when called from fundamental_base constructor (which is called from the constructor of Bar because Bar derives from it): template fundamental_base::fundamental_base (const xercesc::DOMElement& e, flags f, container* c) : B (e, f, c), facet_table_ (0), x_ (traits::create (e, f, c)) {} However, x_ holds the wrong value (even though traits returns the correct value, as mentioned above). Returning from this constructor into the constructor of "Bar", I noticed that Visual Studio shows that Bar derives from fundamental_base rather than fundamental_base (e.g. by inspecting the this reference in the Locals/Auto window of the VS debugger). In the source, it is correct everywhere, it is just the runtime information of the visual studio debugger that says it's of type fundamental_base. Probably, this is the reason why x_ is set to the wrong value. When I remove the attribute, i.e. use xs:double as the type of the element "bar", everything works just fime. Is this a known bug or can someone reproduce that? 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 Feb 3 01:30:59 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Code generation error when using doubles and attributes (?) In-Reply-To: References: Message-ID: Hi Stefan, WEBER Stefan writes: > Returning from this constructor into the constructor of "Bar", I > noticed that Visual Studio shows that Bar derives from > fundamental_base rather than fundamental_base > (e.g. by inspecting the this reference in the Locals/Auto window > of the VS debugger). In the source, it is correct everywhere, it > is just the runtime information of the visual studio debugger that > says it's of type fundamental_base. Sounds like something wasn't recompiled/relinked properly after you changed float to double. Can you try to clean everything (including the XSD-generated code) and rebuild? If that does not help then I will need a test case that reproduces this problem (schema, xml file, test driver, as well as VC++ project and solution files; you can email them to me directly). Boris From boris at codesynthesis.com Wed Feb 4 03:06:40 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] XSD/e 3.0.0 released Message-ID: Hi, We have released XSD/e 3.0.0. XSD/e is our mobile/embedded systems version of XSD. This major release introduces the new Embedded C++/Hybrid mapping. C++/Hybrid provides a light-weight, tree-like object model with precise reproduction of the XML vocabulary structure and element order. The new mapping supports fully in-memory as well as hybrid, partially even-driven, partially in-memory XML processing while maintaining a small footprint and portability. For more information on the new mapping as well as for the complete list of new features in this release, refer to the announcement email on the xsde-announcements mailing list: http://www.codesynthesis.com/pipermail/xsde-announcements/2009/000005.html Boris From kshaban at cmu.edu Wed Feb 4 14:53:54 2009 From: kshaban at cmu.edu (Karim Shaban) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] error c1001 mcs1.cpp line 2701 Message-ID: <39364.64.22.160.1.1233777234.squirrel@64.22.160.1> Hi, I am seeing this weird compile error using XSD 3.0, VC 7.1. I narrowed it down to line 51 on tree\exceptions.hxx: currently it reads: value operator () {return _v}. this causes the visual c++ 2003 compiler to ICE. if I change the line to the following, everything compiles just fine: bool operator== (value v) const { return v==v_; } Is this a known issue with XSD 3.0 / VC7.1? I cannot change the compiler I am using, and I really dont want to change my XSD headers. Any help would be appreciated Thanks P.S: My code compiles fine on Linux (using GCC). From boris at codesynthesis.com Wed Feb 4 15:06:10 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] error c1001 mcs1.cpp line 2701 In-Reply-To: <39364.64.22.160.1.1233777234.squirrel@64.22.160.1> References: <39364.64.22.160.1.1233777234.squirrel@64.22.160.1> Message-ID: Hi Karim, Karim Shaban writes: > Is this a known issue with XSD 3.0 / VC7.1? No, this is the first time I hear about it. Strange thing is that none of the examples which we tested with VC 7.1 triggered this. Can you try XSD 3.2.0 and see if you still get the ICE? If so, can you send a small test case that reproduces the problem so that I can try to find a workaround? Boris From boris at codesynthesis.com Thu Feb 5 12:28:57 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] parsing/serialization performance In-Reply-To: <498144.92048.qm@web38908.mail.mud.yahoo.com> References: <318630.59433.qm@web38904.mail.mud.yahoo.com> <84934.16195.qm@web38904.mail.mud.yahoo.com> <498144.92048.qm@web38908.mail.mud.yahoo.com> Message-ID: Hi Brian, I've CC'ed the xsd-users mailing list in case someone else ran or will run into a similar problem. Brian Kuschak writes: > I have run into a major issue though, and that is performance on the > embedded target (arm7). On the PC, things complete in ~ 50 msec. > However, on the embedded target, it takes a very long 4.6 seconds > to parse a small XML message and generate a short response. > Unfortunately this is an order of magnitude too slow for me. I've > determined that the great bulk of this time is taken by the > construction of the top level object for parsing: > auto_ptr xml(top_(fname)); > and the construction of the top-level serializer object: > top_(fout, xml, map); Parsing and serialization functions do the following steps for each document being parsed/serialized which can be moved out and done only once during the application startup: 1. Initialization/termination of Xerces-C++ 2. Construction of parser/serializer objects 3. For parsing, if XML Schema validation is enabled, loading of the schema(s). The 'performance' example in the examples/cxx/tree/ directory shows how to do all this. For more information on how to parse from std::istream and serialize to std::ostream see the C++/Tree Mapping FAQ, Q2.4 and Q3.2: http://wiki.codesynthesis.com/Tree/FAQ Boris From js.homer at yahoo.com Thu Feb 5 15:04:17 2009 From: js.homer at yahoo.com (Homer J S) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Parsing an undefined floating point number Message-ID: <549104.7603.qm@web45611.mail.sp1.yahoo.com> Hello, using XSD I parsed an object that contains the following empty element (the missing value is supposed to be a float number): then I simply serialized it to standard output, I got 1.93164647928294e-317 I got other values in additon to 1.93164647928294e-317. Can someone please suggest a way to detect if the float value I am trying to retrieve (after parsing) is undefined. Many thanks, JS From boris at codesynthesis.com Thu Feb 5 15:27:37 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Parsing an undefined floating point number In-Reply-To: <549104.7603.qm@web45611.mail.sp1.yahoo.com> References: <549104.7603.qm@web45611.mail.sp1.yahoo.com> Message-ID: Hi, Homer J S writes: > Hello, using XSD I parsed an object that contains the following > empty element (the missing value is supposed to be a float number): > > What is the definition for the 'md' element and its type in your schema? Empty string is not a valid float representation in XML Schema. > then I simply serialized it to standard output, I got > > 1.93164647928294e-317 > > I got other values in additon to 1.93164647928294e-317. Can someone > please suggest a way to detect if the float value I am trying to > retrieve (after parsing) is undefined. One way would be to customize md's type. Let's assume you have the following in your schema: You can customize the generated md_type C++ class to do three things. You will want to add a member that indicates that the float value is "undefined". You will also want to provide your own implementation for the parsing c-tor that checks whether the float representation is empty and set the "undefined" flag (you can still call the base c-tor to handle the attribute and the float value parsing but then check if the DOMElement's value is empty and if so set the "undefined" flag). Finally, you will also want to override the serialization operator so that it checks the "undefined" flag and if it's set, writes an empty string instead of some bogus float value (again, you can first call the base implementation and then clear the DOMElement's value if the "undefined" flag is set). For more information on type customization see the C++/Tree Mapping Customization Guide: http://wiki.codesynthesis.com/Tree/Customization_guide The 'wildcard' example in the examples/cxx/tree/custom/ directory does things that are very similar to what you will need to do. Boris From boris at codesynthesis.com Fri Feb 6 04:06:05 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Serialization problem In-Reply-To: References: <183a50e60901290750y40fe271n6ccc9eb18e0b4ef5@mail.gmail.com> Message-ID: Hi, Boris Kolpackov writes: > 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? It turned out that some schemas weren't compiled with the --generate-serialization option. Boris From js.homer at yahoo.com Fri Feb 6 14:46:02 2009 From: js.homer at yahoo.com (Homer J S) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Question on XSD generated code Message-ID: <892580.23716.qm@web45614.mail.sp1.yahoo.com> Hello, I have the following class "depth" generated by XSD from an existing schema (not mine). The class is derived from xml_schema::double, with an optional attribute uom (string). I could set the attr uom for an object by myObject.uom("aString"); but I could not find a way to set the float value for an object without wiping out the existing uom attr of the object, e.g., myObject = 3.1416; //this will wipe the current value of uom attr Am I missing something here please? Thanks JS ---- class depth: public ::xsd::cxx::tree::fundamental_base< ::xml_schema::double_, char, ::xml_schema::simple_type, ::xsd::cxx::tree::schema_type::double_ > { public: // uom // typedef ::xml_schema::string uom_type; typedef ::xsd::cxx::tree::optional< uom_type > uom_optional; typedef ::xsd::cxx::tree::traits< uom_type, char > uom_traits; const uom_optional& uom () const; uom_optional& uom (); void uom (const uom_type& x); void uom (const uom_optional& x); void uom (::std::auto_ptr< uom_type > p); // Constructors. // depth (const ::xml_schema::double_&); depth (const ::xercesc::DOMElement& e, ::xml_schema::flags f = 0, ::xml_schema::container* c = 0); depth (const depth& x, ::xml_schema::flags f = 0, ::xml_schema::container* c = 0); virtual depth* _clone (::xml_schema::flags f = 0, ::xml_schema::container* c = 0) const; virtual ~depth (); // Implementation. // protected: void parse (::xsd::cxx::xml::dom::parser< char >&, ::xml_schema::flags); protected: uom_optional uom_; }; From boris at codesynthesis.com Fri Feb 6 15:14:21 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Question on XSD generated code In-Reply-To: <892580.23716.qm@web45614.mail.sp1.yahoo.com> References: <892580.23716.qm@web45614.mail.sp1.yahoo.com> Message-ID: Hi, Homer J S writes: > I could set the attr uom for an object by > > myObject.uom("aString"); > > but I could not find a way to set the float value for an object > without wiping out the existing uom attr of the object, e.g., > > myObject = 3.1416; //this will wipe the current value of uom attr What happens is the double value gets implicitly converted to the depth object using the depth(const ::xml_schema::double_&) c-tor and that is assigned to myObject. This is actually quite counter- intuitive and we will try to fix this for the next release. Meantime, you can do something like this: double& d = myObject; d = 3.1416; Or: static_cast (myObject) = 3.1416; Both are unfortunately quite ugly. Also, if you are customizing depth then you can either make that c-tor explicit or add operator=(double). Then the original assignment should work as expected. We will most likely use the latter approach in the next release. Boris From bkuschak at yahoo.com Fri Feb 6 17:33:52 2009 From: bkuschak at yahoo.com (Brian Kuschak) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Re: parsing/serialization performance References: <318630.59433.qm@web38904.mail.mud.yahoo.com> <84934.16195.qm@web38904.mail.mud.yahoo.com> <498144.92048.qm@web38908.mail.mud.yahoo.com> Message-ID: <466831.6629.qm@web38902.mail.mud.yahoo.com> Hi Boris, Thanks for the tip! After implementing something similar to the performance/parsing.cxx file, the operation is much, much faster on the embedded target (~100msec). It also allowed me to easily pass the XML message in a memory buffer instead of using a temporary file. Best regards, Brian ________________________________ From: Boris Kolpackov To: Brian Kuschak Cc: xsd-users@codesynthesis.com Sent: Thursday, February 5, 2009 9:28:57 AM Subject: parsing/serialization performance Hi Brian, I've CC'ed the xsd-users mailing list in case someone else ran or will run into a similar problem. Brian Kuschak writes: > I have run into a major issue though, and that is performance on the > embedded target (arm7). On the PC, things complete in ~ 50 msec. > However, on the embedded target, it takes a very long 4.6 seconds > to parse a small XML message and generate a short response. > Unfortunately this is an order of magnitude too slow for me. I've > determined that the great bulk of this time is taken by the > construction of the top level object for parsing: > auto_ptr xml(top_(fname)); > and the construction of the top-level serializer object: > top_(fout, xml, map); Parsing and serialization functions do the following steps for each document being parsed/serialized which can be moved out and done only once during the application startup: 1. Initialization/termination of Xerces-C++ 2. Construction of parser/serializer objects 3. For parsing, if XML Schema validation is enabled, loading of the schema(s). The 'performance' example in the examples/cxx/tree/ directory shows how to do all this. For more information on how to parse from std::istream and serialize to std::ostream see the C++/Tree Mapping FAQ, Q2.4 and Q3.2: http://wiki.codesynthesis.com/Tree/FAQ Boris From jaume.faus at vianova.no Mon Feb 9 05:46:33 2009 From: jaume.faus at vianova.no (jaume.faus@vianova.no) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] First question Message-ID: Hi, I'm new in the list. So, I'm very sorry if this is a repeating question. I've recently received the assignment of writing a GML ( http://www.opengeospatial.org/standards/gml) parser in C++ to import data from such file formats. As GML is XML I thought to find a tool that, like this one, generates the parser from the schemas. It is a good thing becaus GML is huge. It consts of 30 xsd files. I have several questions. As I didn't use this tool before, I can't generate the parser. I have downloaded all the xsd defining this standard into a file structure that emulates the one existing in http://schemas.opengis.net/gml/ but when I run the command xsdcxx parse schemafile I get several errors telling that AbstractFeature has been implicitly declared as anyType. Well, AbstractFeature is the base class in GML so I suspect that this anyType is made on purpose to make me map it into my app's base class. Is that right? How should I deal with it? should I edit the gml.xsd to make AbstractFeature be of my app's type? If so, how do I make it? In other way, I tried to make a CityGML parser which is a profile (more or less a subset with some specific additions) of GML, therefore its xsd are continuously referencing to GML ones. As I have all xsd in my harddrive in the same file structure I thought it will automatically find the resources in order to compile. But references in CityGML's schemas are made via http links (http://schemas.opengis/gml/...) and it seems that xsdcxx doesn't recognize them and tries to open this string as a file. Is it possible to configure xsdcxx to automatically download the xsd files needed instead of having to download them manually and, in this case, edit them to make its links to point to files in the filesystem instead of internet addresses? Thanks in advance! // jaume From boris at codesynthesis.com Mon Feb 9 06:56:22 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compiling GML/CityGML (was: First question) In-Reply-To: References: Message-ID: Jaume, In the future, please use more descriptive subject lines. The generic "First question" subject does not give any idea what the email is about. jaume.faus@vianova.no writes: > I've recently received the assignment of writing a GML ( > http://www.opengeospatial.org/standards/gml) parser in C++ to import data > from such file formats. As GML is XML I thought to find a tool that, like > this one, generates the parser from the schemas. It is a good thing becaus > GML is huge. It consts of 30 xsd files. Since you are trying to use CityGML, I assume you refer to GML 3.1.1 which is the version required by CityGML 1.0: http://schemas.opengis.net/gml/3.1.1/ http://schemas.opengis.net/citygml/ > I have downloaded all the xsd defining this standard into a file structure > that emulates the one existing in http://schemas.opengis.net/gml/ > > but when I run the command > > xsdcxx parse schemafile > > I get several errors telling that AbstractFeature has been implicitly > declared as anyType. Well, AbstractFeature is the base class in GML so I > suspect that this anyType is made on purpose to make me map it into my > app's base class. Is that right? How should I deal with it? should I edit > the gml.xsd to make AbstractFeature be of my app's type? If so, how do I > make it? The diagnostics you get about AbstractFeature being implicitly of anyType are warnings, not errors. There is a page on the Wiki for GML which provides more information on how to compile this schema. I suggest that you download the "single directory" package mentioned on that page: http://wiki.codesynthesis.com/Schemas/GML Also, GML is a fairly complex schema so I suggest that you start with the C++/Tree mapping because it is easier to use. Since this schema uses polymorphism, you will probably want to read 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 > In other way, I tried to make a CityGML parser which is a profile (more or > less a subset with some specific additions) of GML, therefore its xsd are > continuously referencing to GML ones. As I have all xsd in my harddrive in > the same file structure I thought it will automatically find the resources > in order to compile. But references in CityGML's schemas are made via http > links (http://schemas.opengis/gml/...) and it seems that xsdcxx doesn't > recognize them and tries to open this string as a file. There is a test available for CityGML 1.0: http://www.codesynthesis.com/~boris/tmp/citygml-test.tar.gz It contains the GML 3.1.1 and CityGML 1.0 schemas as well as a test driver and makefile. There is also the README file inside with more information. Note, that since you are using the "official" Debian package for XSD, you will need to change "XSD := xsd" to "XSD := xsdcxx" in the makefile. > Is it possible to configure xsdcxx to automatically download the xsd > files needed instead of having to download them manually and, in this > case, edit them to make its links to point to files in the filesystem > instead of internet addresses? XSD does not support remote schema retrieval so you will need to download the local copies of the schemas you are compiling. You, however, don't need to modify them. Instead, you can use the --location-map option to re-map include/import locations. See the citygml.options file in the above test for an example. Boris From jaume.faus at vianova.no Tue Feb 10 05:02:31 2009 From: jaume.faus at vianova.no (jaume.faus@vianova.no) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compiling GML/CityGML (was: First question) In-Reply-To: References: Message-ID: Hi Jaume, jaume.faus@vianova.no writes: > But it also happens that there are some refactoring proposals for our > object model and we are studing GML, CityGML, IFCxml and plain IFC to > extract ideas from them for the new model. In this case I'd like to have > an initial tool that let me study these standards in depth and I found > these automatic parser generator tools a good help to save me the time to > writing the parsers rather than concentrate in the model beneath. If after > all we decide to keep our model then it is no strict need for having a GML > model and we probably would discard it because of its size. While using C++/Tree may not be the optimal solution, it would definitely be the simplest from the development point of view unless your custom object model corresponds very closely to GML/CityGML. With C++/Parser you have to process data in the GML/CityGML order. With C++/Tree you have all of the data available to you so you can convert it in the most convenient way. > I've seen that object files created by the parser are of about > 100MB. That is a considerable footprint. The GML schema is quite large so the non-trivial footprint is expected. Having said that, I just build the CityGML test I mentioned earlier (contains both GML and CityGML schemas) with optimization on my 64-bit GNU/Linux box. After stripping, the driver executable is about 5MB. I am not sure where you have got 100MB. Well I've just create a new VS2005 project, added all the schemas in the resources folder, then selected the --generate-polymorphic option for each of them and compile. Since I having linking errors like the following 1>Linking... 1>mfcs80ud.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj) 1> Creating library C:\GML2\Debug\GML2.lib and object C:\GML2\Debug\GML2.exp 1>units.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl xercesc_3_0::XMLPlatformUtils::Initialize(char const * const,char const * const,class xercesc_3_0::PanicHandler * const,class xercesc_3_0::MemoryManager * const)" (__imp_?Initialize@XMLPlatformUtils@xercesc_3_0@@SAXQBD0QAVPanicHandler@2@QAVMemoryManager@2@@Z) 1>valueObjects.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl xercesc_3_0::XMLPlatformUtils::Initialize(char const * const,char const * const,class xercesc_3_0::PanicHandler * const,class xercesc_3_0::MemoryManager * const)" (__imp_?Initialize@XMLPlatformUtils@xercesc_3_0@@SAXQBD0QAVPanicHandler@2@QAVMemoryManager@2@@Z) 1>temporal.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl xercesc_3_0::XMLPlatformUtils::Initialize(char const * const,char const * const,class xercesc_3_0::PanicHandler * const,class xercesc_3_0::MemoryManager * const)" (__imp_?Initialize@XMLPlatformUtils@xercesc_3_0@@SAXQBD0QAVPanicHandler@2@QAVMemoryManager@2@@Z) 1>temporalReferenceSystems.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl xercesc_3_0::XMLPlatformUtils::Initialize(char const * const,char const * const,class xercesc_3_0::PanicHandler * const,class xercesc_3_0::MemoryManager * const)" (__imp_?Initialize@XMLPlatformUtils@xercesc_3_0@@SAXQBD0QAVPanicHandler@2@QAVMemoryManager@2@@Z) referenced in function "class std::auto_ptr __cdecl gml::_TimeReferenceSystem(class std::basic_string,class std::allocator > const &,class xsd::cxx::tree::flags,class xsd::cxx::tree::properties const &)" (?_TimeReferenceSystem@gml@@YA?AV?$auto_ptr@VAbstractTimeReferenceSystemType@gml@@@std@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@3@Vflags@tree@cxx@xsd@@ABV?$properties@D@678@@Z) 1>temporalTopology.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl xercesc_3_0::XMLPlatformUtils::Initialize(char const * const,char const * const,class xercesc_3_0::PanicHandler * const,class xercesc_3_0::MemoryManager * const)" (__imp_?Initialize@XMLPlatformUtils@xercesc_3_0@@SAXQBD0QAVPanicHandler@2@QAVMemoryManager@2@@Z) 1>topology.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static void __cdecl xercesc_3_0::XMLPlatformUtils::Initialize(char const * const,char const * const,class xercesc_3_0::PanicHandler * const,class xercesc_3_0::MemoryManager * const)" (__imp_?Initialize@XMLPlatformUtils@xercesc_3_0@@SAXQBD0QAVPanicHandler@2@QAVMemoryManager@2@@Z) Then I guessed that I'm missing the xerces library to the linkage. So I added it to the Project->properties->Configuration properties->Linker->Additional Dependencies. In my computer this is the path to what I guess is the missing dependency: "C:\Program Files\CodeSynthesis XSD 3.2\lib\vc-8.0\xerces-c_3.lib" Getting these output 1>------ Build started: Project: GML2, Configuration: Release Win32 ------ 1>Linking... 1>mfcs80u.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRT.lib(dllmain.obj) 1> Creating library C:\GML2\Release\GML2.lib and object C:\GML2\Release\GML2.exp 1>C:\GML2\Release\GML2.dll : fatal error LNK1169: one or more multiply defined symbols found 1>Build log was saved at "file://c:\GML2\GML2\Release\BuildLog.htm" 1>GML2 - 2 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Here is where I got lost and I couldn't build the dll despite I have been googling a lot since yesterday. It looks that my supposition was not true. So I don't really know how big is the resulting dll, but I've got a look to the obj files and yes, they are 110MB. It would be so helpful if someone knows what I'm doing wrong. >From now, Thanks a lot! Jaume From boris at codesynthesis.com Tue Feb 10 05:52:36 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compiling GML/CityGML (was: First question) In-Reply-To: References: Message-ID: Hi Jaume, jaume.faus@vianova.no writes: > 1>mfcs80u.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined > in MSVCRT.lib(dllmain.obj) > > [...] > > It would be so helpful if someone knows what I'm doing wrong. I am not sure what's wrong but I doubt it is related to XSD or the generated code. Looks like you are linking to conflicting DLLs. I suggest that for starters you try to create a plain Win32 DLL (not an MFC DLL) and add the generated code (and the Xerces-C++ dependency) to it. We have tested this and didn't run into any problems. Boris From jaume.faus at vianova.no Tue Feb 10 08:31:53 2009 From: jaume.faus at vianova.no (jaume.faus@vianova.no) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compiling GML/CityGML (was: First question) In-Reply-To: References: Message-ID: Yep, that was a solution. No I can compile. Thanks! However I still having some warnings even though I added the XML_LIBRARY macro at preprocessor definitions (I read it on the Xerces Tips wiki: http://wiki.codesynthesis.com/Xerces_tips ). I'm using the C:\Program Files\CodeSynthesis XSD 3.2\lib\vc-8.0\xerces-c_3.lib file as a dependency. At least I got the dll! This is the output 1>------ Build started: Project: GML3, Configuration: Release Win32 ------ 1>Linking... 1>Generating code 1>Finished generating code 1>valueObjects.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>units.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>topology.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>temporalTopology.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>temporalReferenceSystems.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>temporal.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>smil20-language.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>smil20.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>referenceSystems.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>observation.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>measures.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>grids.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>gmlBase.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>geometryPrimitives.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>geometryComplexes.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>geometryBasic2d.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>geometryBasic0d1d.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>geometryAggregates.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>feature.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>dynamicFeature.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>direction.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>dictionary.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>defaultStyle.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>datums.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>dataQuality.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>coverage.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>coordinateSystems.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>coordinateReferenceSystems.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>coordinateOperations.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>basicTypes.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>xml-mod.obj : warning LNK4248: unresolved typeref token (0100001B) for 'xercesc_3_0.DOMUserDataHandler'; image may not run 1>basicTypes.obj : warning LNK4248: unresolved typeref token (0100001F) for 'xercesc_3_0.XMLGrammarPool'; image may not run 1>Embedding manifest... 1>Build log was saved at "file://c:\GML3\GML3\Release\BuildLog.htm" 1>GML3 - 0 error(s), 32 warning(s) ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== It looks like this is the last thing to solve. After seeking info I've read that it can be due to xerces library has not been built using /clr option (which is something comprehensible). So I had to remove any CLR reference in my code and finally it compiled gracefully. Thanks Boris! Now it is time to give it the semantics. So, last question would be: what if I want to have CLR support? The target application is a mixture of all MS's .Net languages. The only way to solve this that comes into my mind is to get xerces source code and compil it in VS. But I have only a couple of weeks experience in this VS world. Is there any other way? Sorry for this question bombing. I promise that I try to fix it by my self and try to find information without disturb anyone. Thank's From: Boris Kolpackov To: jaume.faus@vianova.no Cc: xsd-users@codesynthesis.com Date: 10.02.2009 12:00 Subject: Re: [xsd-users] Compiling GML/CityGML (was: First question) Hi Jaume, jaume.faus@vianova.no writes: > 1>mfcs80u.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined > in MSVCRT.lib(dllmain.obj) > > [...] > > It would be so helpful if someone knows what I'm doing wrong. I am not sure what's wrong but I doubt it is related to XSD or the generated code. Looks like you are linking to conflicting DLLs. I suggest that for starters you try to create a plain Win32 DLL (not an MFC DLL) and add the generated code (and the Xerces-C++ dependency) to it. We have tested this and didn't run into any problems. Boris From boris at codesynthesis.com Tue Feb 10 08:52:43 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] Compiling GML/CityGML (was: First question) In-Reply-To: References: Message-ID: Hi Jaume, jaume.faus@vianova.no writes: > However I still having some warnings even though I added the XML_LIBRARY > macro at preprocessor definitions (I read it on the Xerces Tips wiki: > http://wiki.codesynthesis.com/Xerces_tips ). I'm using the C:\Program > Files\CodeSynthesis XSD 3.2\lib\vc-8.0\xerces-c_3.lib file as a > dependency. The MSI package for CodeSynthesis XSD comes with DLL versions of Xerces-C++. There are no static versions so you should not use the XML_LIBRARY macro. On Windows, to link to a DLL you still link to the .lib file which is an import stub library. It seems that you don't have a very good understanding of how dynamic libraries are built and used on Windows and this mailing list is not the right place to try to get this understanding. > So, last question would be: what if I want to have CLR support? The target > application is a mixture of all MS's .Net languages. The only way to > solve this that comes into my mind is to get xerces source code and compil > it in VS. But I have only a couple of weeks experience in this VS world. > Is there any other way? Neither XSD nor Xerces-C++ support CLR. To be usable from the .Net platform, the code should be written in Microsoft Managed C++ which is very different from Standard C++. If your application is going to run on .Net, then I suggest that you consider using the Microsoft's xsd.exe tool (I have no idea whether it can compile GML/CityGML). Boris From shardasaiwan at gmail.com Wed Feb 11 00:55:50 2009 From: shardasaiwan at gmail.com (sharda saiwan) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] error while using "xsd cxx-tree" Message-ID: hello all, i am trying to create the c++ library from my xml schema file. i used the command "./bin/xsd cxx-tree lfb.xsd" for the c++ binding, but got the following errors: [sharda@cmj-cnie-sharda xsd-3.2.0-i686-linux-gnu]$ ./bin/xsd cxx-parser lfb.xsd lfb.xsd:184:61: warning F001: element 'optional' is implicitly of anyType lfb.xsd:184:61: info: did you forget to specify 'type' attribute? lfb.xsd:419:61: warning F001: element 'optional' is implicitly of anyType lfb.xsd:419:61: info: did you forget to specify 'type' attribute? lfb.xsd:453:61: warning F001: element 'optional' is implicitly of anyType lfb.xsd:453:61: info: did you forget to specify 'type' attribute? lfb.xsd:484:59: warning F001: element 'eventCondition' is implicitly of anyType lfb.xsd:484:59: info: did you forget to specify 'type' attribute? lfb.xsd:486:55: warning F001: element 'eventCreated' is implicitly of anyType lfb.xsd:486:55: info: did you forget to specify 'type' attribute? lfb.xsd:488:55: warning F001: element 'eventDeleted' is implicitly of anyType lfb.xsd:488:55: info: did you forget to specify 'type' attribute? lfb.xsd:490:55: warning F001: element 'eventChanged' is implicitly of anyType lfb.xsd:490:55: info: did you forget to specify 'type' attribute? lfb.xsd:492:55: warning F001: element 'eventGreaterThan' is implicitly of anyType lfb.xsd:492:55: info: did you forget to specify 'type' attribute? lfb.xsd:494:55: warning F001: element 'eventLessThan' is implicitly of anyType lfb.xsd:494:55: info: did you forget to specify 'type' attribute? lfb.xsd:486:55: warning B101: substitution groups are used but --generate-polymorphic was not specified lfb.xsd:486:55: info: generated code may not be able to parse some conforming instances lfb.xsd:7:39: error: unable to map XML Schema namespace 'urn:ietf:params:xml:ns:forces:lfbmodel:1.0' to C++ namespace lfb.xsd:7:39: info: use the --namespace-map or --namespace-regex option to provide custom mapping what does these errors mean? As i am new to CodeSynthesis XSD, i dont understand how to solve these errors. plsssss help!! From boris at codesynthesis.com Wed Feb 11 01:16:01 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] error while using "xsd cxx-tree" In-Reply-To: References: Message-ID: Hi Sharda, sharda saiwan writes: > lfb.xsd:184:61: warning F001: element 'optional' is implicitly of anyType > lfb.xsd:184:61: info: did you forget to specify 'type' attribute? > > [...] > > lfb.xsd:494:55: warning F001: element 'eventLessThan' is implicitly of > anyType This set of warnings tells you that a bunch of elements in your schema don't have the 'type' attribute and default to being of the xsd:anyType built-in XML Schema type. If this is intentional then you can disable these warnings by adding --disable-warning F001 to the XSD command line. > lfb.xsd:486:55: warning B101: substitution groups are used but > --generate-polymorphic was not specified > lfb.xsd:486:55: info: generated code may not be able to parse some > conforming instances This warning tells you that your schema uses polymorphism but the generated code will be polymorphism-unaware unless you specify the --generate-polymorphic option. For more information on support for XML Schema polymorphism, 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 > lfb.xsd:7:39: error: unable to map XML Schema namespace > 'urn:ietf:params:xml:ns:forces:lfbmodel:1.0' to C++ namespace > lfb.xsd:7:39: info: use the --namespace-map or --namespace-regex option to > provide custom mapping This error tells you that the XSD compiler does not know how to map the urn:ietf:params:xml:ns:forces:lfbmodel:1.0 XML namespace to C++ namespace. You can use the --namespace-map option to provide a mapping, for example: --namespace-map urn:ietf:params:xml:ns:forces:lfbmodel:1.0=lfb1_0 See Section 3.3, "Namespace Mapping" in the C++/Tree Mapping Getting Started Guide for details: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#3.3 Boris From Daniel.Macumber at nrel.gov Wed Feb 11 18:19:55 2009 From: Daniel.Macumber at nrel.gov (Macumber, Daniel) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] SWIG output from xsd Message-ID: <9228D7EC9A32594191AA7530DB531449079EFA07@mail-3a.nrel.gov> Hello, I am wondering if there has been any effort to write SWIG interface files when writing out the auto generated C++ classes using the cxx-tree option of xsd. Doing this would allow the generated code to be used with C#, Ruby, Python, etc. Have there been any efforts towards this approach? Would it be feasible to try to do this? Thanks a lot, Dan From shardasaiwan at gmail.com Thu Feb 12 06:44:54 2009 From: shardasaiwan at gmail.com (sharda saiwan) Date: Sun Oct 11 15:34:07 2009 Subject: [xsd-users] error while using "xsd cxx-tree" In-Reply-To: References: Message-ID: yeah! fixed all the errors!! now i am successfully using it. thanks a lot for the help....[?] On Wed, Feb 11, 2009 at 1:16 AM, Boris Kolpackov wrote: > Hi Sharda, > > sharda saiwan writes: > > > lfb.xsd:184:61: warning F001: element 'optional' is implicitly of anyType > > lfb.xsd:184:61: info: did you forget to specify 'type' attribute? > > > > [...] > > > > lfb.xsd:494:55: warning F001: element 'eventLessThan' is implicitly of > > anyType > > This set of warnings tells you that a bunch of elements in your schema > don't have the 'type' attribute and default to being of the xsd:anyType > built-in XML Schema type. If this is intentional then you can disable > these warnings by adding > > --disable-warning F001 > > to the XSD command line. > > > > lfb.xsd:486:55: warning B101: substitution groups are used but > > --generate-polymorphic was not specified > > lfb.xsd:486:55: info: generated code may not be able to parse some > > conforming instances > > This warning tells you that your schema uses polymorphism but the > generated code will be polymorphism-unaware unless you specify the > --generate-polymorphic option. For more information on support for > XML Schema polymorphism, 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 > > > > lfb.xsd:7:39: error: unable to map XML Schema namespace > > 'urn:ietf:params:xml:ns:forces:lfbmodel:1.0' to C++ namespace > > lfb.xsd:7:39: info: use the --namespace-map or --namespace-regex option > to > > provide custom mapping > > This error tells you that the XSD compiler does not know how to map > the urn:ietf:params:xml:ns:forces:lfbmodel:1.0 XML namespace to C++ > namespace. You can use the --namespace-map option to provide a mapping, > for example: > > --namespace-map urn:ietf:params:xml:ns:forces:lfbmodel:1.0=lfb1_0 > > See Section 3.3, "Namespace Mapping" in the C++/Tree Mapping Getting > Started Guide for details: > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#3.3 > > Boris > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 611 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20090212/a25d629a/attachment.png From jan.klimke at hpi.uni-potsdam.de Thu Feb 12 08:23:13 2009 From: jan.klimke at hpi.uni-potsdam.de (Jan Klimke) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] sorting of a sequence of elements when IDs are contained, duplicate_id exception Message-ID: <499422C1.90607@hpi.uni-potsdam.de> Hi all, i would like to sort a sequence which was extracted from xml. Therefore i defined a comparison function like this bool TourTool::compareTourSectionBySectionNumber( gml::FeaturePropertyType& sec1,gml::FeaturePropertyType& sec2 ){ return (static_cast(sec1.getFeature())->getSectionNo() < static_cast(sec2.getFeature())->getSectionNo()); } The problem is when i call std::sort(tour->getTourSection().begin(), tour->getTourSection().end(), compareTourSectionBySectionNumber); where tourSection is a sequence of gml:FeaturePropertyType, a duplicate_id exception is thrown. This probably happens because of the gml:id of the entities is copied when a position switch in the sequence is necessary. Is there another way to sort such a sequence without throwing this exception ? Regards, Jan From boris at codesynthesis.com Thu Feb 12 13:06:11 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] SWIG output from xsd In-Reply-To: <9228D7EC9A32594191AA7530DB531449079EFA07@mail-3a.nrel.gov> References: <9228D7EC9A32594191AA7530DB531449079EFA07@mail-3a.nrel.gov> Message-ID: Hi Daniel, Macumber, Daniel writes: > Hello, I am wondering if there has been any effort to write SWIG > interface files when writing out the auto generated C++ classes using > the cxx-tree option of xsd. Doing this would allow the generated code > to be used with C#, Ruby, Python, etc. Have there been any efforts > towards this approach? Would it be feasible to try to do this? Using SWIG to provide XML data binding to scripting languages has been on our "potential future directions" list for some time now. There was also a discussion recently which mentioned SWIG in the context of providing access to C++/Tree object model from C#. So there is definitely some interest in this: http://www.codesynthesis.com/pipermail/xsd-users/2009-January/002155.html At this point, however, it is not clear whether it will be possible to "wrap" the generated code using SWIG. The C++/Tree object model is quite complex and I am having a hard time understanding how some more advanced techniques, for example support for polymorphism, will be handled. Though, even without support for these techniques (at least initially) the integration can be useful to quite a few people. Also SWIG seems to provide a fairly complete support for C++. The only things that is not supported is nested classes but that is not used in the generated code. Another unclear point is whether it will be possible to generate a single SWIG interface that can be used to generate wrappers for all possible target languages. If we have to generate some specific code for C#, Python, etc., then the approach looks a lot less attractive. But we would definitely be interested and provide assistance if you (or someone else) would like to take a stab at this. The first step should probably be a hand-written proof-of-concept SWIG interface for a simple schema that uses the most common features. Something along these lines: Here you would need to instantiate the xml_schema::string template as well as container classes for Bar::b and Baz::bar (I wonder how the typedef names inside Bar and Baz are translated to other languages). Boris From angelo at cedeo.net Thu Feb 12 13:25:39 2009 From: angelo at cedeo.net (Angelo Difino) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Keep a xsd library small Message-ID: <499469A3.5020609@cedeo.net> Hi xsd-users and all, first of all I'd like to say that xsd-codesynthesis rocks: after just few days of it i was able to create the c++ classes of a quite 'complicated' set of schemas (that was already posted here few mouths ago'). Since this set of schema suffer of cyclic dependencies with inheritance, I'm using the file-per-type option. I'm running the last release (3.2.0) of XSD on win32/vista... Everything works great, but the problem is the huge amount of files and its size when I try to compile it (i'm using MSVisual c++ 2003). The header and class file counts 872 and the built library is of 1GB of size (!!!) I've tried using the option/ external-xml-schema/ but it seems the situation doesn't change so much... Has anybody of you any suggestions to keep the compiled library smaller? The set of schema is attached in this email. The cmd line i use is: /xsd cxx-tree --extern-xml-schema xmlschema.hxx --generate-serialization --generate-polymorphic --file-per-type --location-map http://www.dmpf.org/schemas/msbp.xsd=msbp.xsd --location-map http://www.dmpf.org/schemas/dmprpp.xsd=dmprpp.xsd --location-map http://www.dmpf.org/schemas/didl-msx.xsd=didl-msx.xsd --location-map http://www.dmpf.org/schemas/didl.xsd=didl.xsd --location-map http://www.dmpf.org/schemas/didmodel.xsd=didmodel.xsd --location-map http://www.dmpf.org/schemas/dii.xsd=dii.xsd --location-map http://www.dmpf.org/schemas/ipmpdidl.xsd=ipmpdidl.xsd --location-map http://www.dmpf.org/schemas/ipmpinfo-msx.xsd=ipmpinfo-msx.xsd --location-map http://www.dmpf.org/schemas/ipmpinfo.xsd=ipmpinfo.xsd --location-map http://www.dmpf.org/schemas/ipmpmsg.xsd=ipmpmsg.xsd --location-map http://www.dmpf.org/schemas/mpeg4ipmp.xsd=mpeg4ipmp.xsd --location-map http://www.dmpf.org/schemas/mpeg7smp.xsd=mpeg7smp.xsd --location-map http://www.dmpf.org/schemas/rel-m1x.xsd=rel-m1x.xsd --location-map http://www.dmpf.org/schemas/rel-m2x.xsd=rel-m2x.xsd --location-map http://www.dmpf.org/schemas/rel-m3x.xsd=rel-m3x.xsd --location-map http://www.dmpf.org/schemas/rel-mx.xsd=rel-mx.xsd --location-map http://www.dmpf.org/schemas/rel-r.xsd=rel-r.xsd --location-map http://www.dmpf.org/schemas/rel-sx.xsd=rel-sx.xsd --location-map http://www.w3.org/2001/xml.xsd=xml.xsd --location-map http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd=dsig.xsd --location-map http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd=xenc.xsd --namespace-map urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007=msbp --namespace-map urn:dmp:idp:represent:PaymentProtocol:2008=dmprpp --namespace-map urn:mpeg:maf:schema:mediastreaming:DIDLextensions=didl_msx --namespace-map urn:mpeg:mpeg21:2006:07-DIDL-NS=didl --namespace-map urn:mpeg:mpeg21:2002:02-DIDMODEL-NS=didmodel --namespace-map urn:mpeg:mpeg21:2002:01-DII-NS=dii --namespace-map urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS=ipmpdidl --namespace-map urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007=ipmpinfo_msx --namespace-map urn:mpeg:mpeg21:2004:01-IPMPINFO-NS=ipmpinfo --namespace-map urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007=ipmpmsg --namespace-map urn:mpeg:mpeg4:IPMPSchema:2002=mpeg4ipmp --namespace-map urn:mpeg:mpeg7:smp:schema:2001=mpeg7smp --namespace-map urn:mpeg:mpeg21:2005:01-REL-M1X-NS=rel_m1x --namespace-map urn:mpeg:mpeg21:2006:01-REL-M2X-NS=rel_m2x --namespace-map urn:mpeg:mpeg21:2006:01-REL-M3X-NS=rel_m3x --namespace-map urn:mpeg:mpeg21:2003:01-REL-MX-NS=rel_mx --namespace-map urn:mpeg:mpeg21:2003:01-REL-R-NS=rel_r --namespace-map urn:mpeg:mpeg21:2003:01-REL-SX-NS=rel_sx --namespace-map http://www.w3.org/XML/1998/namespace=xml --namespace-map http://www.w3.org/2000/09/xmldsig#=dsig --namespace-map http://www.w3.org/2001/04/xmlenc#=xenc didl.xsd/ Best regards, Angelo -------------- next part -------------- A non-text attachment was scrubbed... Name: schemas.rar Type: application/octet-stream Size: 31727 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20090212/64afee07/schemas.obj From boris at codesynthesis.com Fri Feb 13 02:45:58 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] sorting of a sequence of elements when IDs are contained, duplicate_id exception In-Reply-To: <499422C1.90607@hpi.uni-potsdam.de> References: <499422C1.90607@hpi.uni-potsdam.de> Message-ID: Hi Jan, Jan Klimke writes: > The problem is when i call > > std::sort(tour->getTourSection().begin(), tour->getTourSection().end(), > compareTourSectionBySectionNumber); > > where tourSection is a sequence of gml:FeaturePropertyType, a > duplicate_id exception is thrown. This probably happens because of the > gml:id of the entities is copied when a position switch in the sequence > is necessary. Hm, that's an interesting problem. I think you are right about what happens: std::sort() first inserts a new copy and then removes the old one. So you end up with two objects with the same ID in the tree. I can't think of anything better than these two solutions: (1) Implement your own sort where you first remove the old element from the sequence and then insert the new one. (2) Copy the contents of the sequence into another, "free-standing" sequence which is not part of any object model. You can then sort that sequence and copy the result back. There is quite a bit of copying with this approach: TourSectionContainer tmp = tour->getTourSection(); std::sort(tmp.begin(), tmp.end(), compareTourSectionBySectionNumber); tour->getTourSection() = tmp; Note that using swap() here won't work. Boris From boris at codesynthesis.com Fri Feb 13 08:56:49 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Keep a xsd library small In-Reply-To: <499469A3.5020609@cedeo.net> References: <499469A3.5020609@cedeo.net> Message-ID: Hi Angelo, Angelo Difino writes: > first of all I'd like to say that xsd-codesynthesis rocks: after just few > days of it i was able to create the c++ classes of a quite 'complicated' > set of schemas (that was already posted here few mouths ago'). Thanks, I am glad you find it useful. > Since this set of schema suffer of cyclic dependencies with inheritance, > I'm using the file-per-type option. I'm running the last release (3.2.0) > of XSD on win32/vista... > > Everything works great, but the problem is the huge amount of files > and its size when I try to compile it (i'm using MSVisual c++ 2003). > The header and class file counts 872 and the built library is of 1GB > of size You are probably building a static library. Unfortunately with the file-per-type mode static libraries for non-trivial schemas are bound to be quite large. This is due to the large number of source files which, when compiled, all include instantiations of some common templates (this is especialy true when the --generate- polymorphic option is used). The static library is pretty much the archive of all the object files. When it is linked to an executable, the linker will remove all those duplicate template instantiations so the resulting binary will have the same size as if you used the file-per-schema mode. One solution to this problem is to use a shared library (DLL) instead of a static library since a shared library is mode like an executable in that all the duplicate template instantiations are removed. For example, I compiled your schemas on my GNU/Linux box and while the static library is 227MB, the shared library is 10MB. Here are some more tips for reducing the size/compilation time: 1. Specify root element with the --root-element option. In your schema I eliminated about a hundred parsing/serialization functions by adding '--root-element DIDL' to the command line. 2. Your schema is composed of several lower-level schema subsets. If only one of the lower-level subsets involve the cyclic dependency, then you can compile only this subset in the file-per-type mode and the rest in the default, file-per- schema mode. Note that here the subset needs to be fairly isolated in that all the schemas that it includes/imports will be handled in the file-per-type mode. In your case, there are two subsets that involve cyclic dependencies (rel-*.xsd and ipmpmsg.xsd/ipmpinfo.xsd) so the bulk of the schema has to be compiled in the file-per-type mode. However, there are still a few files that can be compiled in the file-per-schema mode, namely, didl.xsd, didl-msx.xsd, and mpeg4smp.xsd. I compiled your schemas like so: xsd cxx-tree --file-per-type ... rel-r.xsd ipmpinfo.xsd xsd cxx-tree ... didl.xsd didl-msx.xsd mpeg4smp.xsd And the static library size went down to 175Mb. 3. You can also try to split the offending schemas into two or more files so that they don't involve cyclic dependencies with inheritance (the resulting schema will be semantically equivalent to the original). Then you can use the file-per- schema mode. 4. When using the file-per-type mode it is recommended to use precompiled headers to speed-up compilation. You would normally include xml-schema.hxx into the precompiled header and then include the precompiled header into each generated source file using the --cxx-prologue option. Boris From aborodya at yahoo.com Fri Feb 13 12:15:40 2009 From: aborodya at yahoo.com (Anatoly Borodyansky) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] No declaration found for element 'people' Message-ID: <157923.79057.qm@web54607.mail.re2.yahoo.com> Hi, I'm trying to use parser version of the product, and when I build auto- generated example based on the people XML example in the users guide(pp 8-9 of cxx-parser-guide.PDF), parsing fails with the message above. There is no ppl namespace, or target namespace specified in this example, so XML looks like ... Is there a way to make it work without altering the XML file? Thanks a lot, Anatoly From boris at codesynthesis.com Fri Feb 13 13:41:25 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] No declaration found for element 'people' In-Reply-To: <157923.79057.qm@web54607.mail.re2.yahoo.com> References: <157923.79057.qm@web54607.mail.re2.yahoo.com> Message-ID: Hi Anatoly, Anatoly Borodyansky writes: > I'm trying to use parser version of the product, and when I build auto- > generated example based on the people XML example in the users > guide(pp 8-9 of cxx-parser-guide.PDF), parsing fails with the message > above. There is no ppl namespace, or target namespace specified in > this example, so XML looks like > > > ... > > > Is there a way to make it work without altering the XML file? The reason you get this error is because the underlying XML parser (Xerces-C++) cannot find the schema to validate the document against. There are several ways to fix this without modifying the XML document: 1. You can disable XML Schema validation by passing the dont_validate flag to the parse() function. See Section 7.1, "Xerces-C++ Document Parser" for details. 2. You can disable XML Schema validation in the underlying XML parser as per (1) but enable it in the generating code by compiling your schemas with --generate-validation option. See Section 5.3, "XML Schema Validation" for details. 3. If you would like to use XML Schema validation in the underlying parser, then there are several methods to locate the schemas other that specifying them inside the document with schemaLocation and noNamespaceSchemaLocation attributes. The easiest way would be use the properties argument to the parse() function as described in the above-mentioned Section 7.1. It is also possible to pre-load the schemas in to the XML parser object and use that to parse several documents. This way the schemas will be loaded and parsed only once. For this methos you will need to use one of the parse() functions that take the SAX2XMLReader object which you will need to create and load the schemas into. Boris From aborodya at yahoo.com Fri Feb 13 17:49:17 2009 From: aborodya at yahoo.com (Anatoly Borodyansky) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] No declaration found for element 'people' Message-ID: <454918.61397.qm@web54603.mail.re2.yahoo.com> Boris, thanks a lot! One more question, if you don't mind: If I need to parse a large XML file, adjust some elements, and serialize the whole structure again, what is the best way to do it ( it works beautifully with Tree, but my input Is too large for it to handle) Anatoly On Feb 13, 2009, at 1:41 PM, Boris Kolpackov wrote: Hi Anatoly, Anatoly Borodyansky writes: I'm trying to use parser version of the product, and when I build auto- generated example based on the people XML example in the users guide(pp 8-9 of cxx-parser-guide.PDF), parsing fails with the message above. There is no ppl namespace, or target namespace specified in this example, so XML looks like ... Is there a way to make it work without altering the XML file? The reason you get this error is because the underlying XML parser (Xerces-C++) cannot find the schema to validate the document against. There are several ways to fix this without modifying the XML document: 1. You can disable XML Schema validation by passing the dont_validate flag to the parse() function. See Section 7.1, "Xerces-C++ Document Parser" for details. 2. You can disable XML Schema validation in the underlying XML parser as per (1) but enable it in the generating code by compiling your schemas with --generate-validation option. See Section 5.3, "XML Schema Validation" for details. 3. If you would like to use XML Schema validation in the underlying parser, then there are several methods to locate the schemas other that specifying them inside the document with schemaLocation and noNamespaceSchemaLocation attributes. The easiest way would be use the properties argument to the parse() function as described in the above-mentioned Section 7.1. It is also possible to pre-load the schemas in to the XML parser object and use that to parse several documents. This way the schemas will be loaded and parsed only once. For this methos you will need to use one of the parse() functions that take the SAX2XMLReader object which you will need to create and load the schemas into. Boris From boris at codesynthesis.com Sun Feb 15 09:19:41 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Posting guidelines Message-ID: Hi, We have created a page which lists a few basic guidelines that we would like you to follow when posting to the mailing lists hosted by Code Synthesis: http://www.codesynthesis.com/support/posting-guidelines.xhtml As an incentive to follow these guidelines, Code Synthesis staff assigns higher priority to questions that do not violate any of the listed rules. Boris From boris at codesynthesis.com Mon Feb 16 02:04:41 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] XQilla 2.2.0 released Message-ID: Hi, This is a belated announcement of the XQilla 2.2.0 release. XQilla is an XPath and XQuery processor built on top of Xerces-C++. It can be used to locate C++/Tree object model nodes using XPath 2.0 as shown in the 'xpath' example in the XSD distribution. For more information on XQilla, see the project's website: http://xqilla.sourceforge.net/HomePage The official announcement for the 2.2.0 release is here: http://sourceforge.net/forum/forum.php?forum_id=905141 One of the changes that is particularly relevant to XSD is better integration of the XPath functionality and the DOM API. Prior to Xerces-C++ 3.0.0 and XQilla 2.2.0, running XPath on DOM involved a lot of type casting. Boris From jaume.faus at vianova.no Mon Feb 16 04:51:52 2009 From: jaume.faus at vianova.no (jaume.faus@vianova.no) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Fw: GML3.1.1 parser compile succeed but still not able to parse any file Message-ID: Hi, I forgot to say that you don't need to download everything. If you want to you only need to download the file http://superbumbot.sytes.net/xsd-gml/xsd-gml3.1.1-parsing.tgz which contains all the sources. It is also interesting that by calling the classic "make clean" every generated file is deleted. Thanks, jaume From jaume.faus at vianova.no Mon Feb 16 06:03:54 2009 From: jaume.faus at vianova.no (jaume.faus@vianova.no) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] GML3.1.1 parser compile succeed but still not able to parse any file Message-ID: Hello, it seems that the mailing list doesn't process the first message. Maybe because it es too long? Anyway I have pasted it into this url ( http://superbumbot.sytes.net/xsd-gml/message) so hopefully you all can read it. Please, don't panic. It takes less than 1 minute to read. It is about problems running compiled code for GML 3.1.1. Please, notice that you don't need to download everything (i'm following the mailing lists posting guidelines). If you want to, you only need to download the file http://superbumbot.sytes.net/xsd-gml/xsd-gml3.1.1-parsing.tgz (80Kb) which contains all the sources. A "make" call will prepare everything. It is also interesting that by calling the classic "make clean" every generated file is deleted. Thanks!, jaume From jaume.faus at vianova.no Mon Feb 16 05:23:45 2009 From: jaume.faus at vianova.no (jaume.faus@vianova.no) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] GML3.1.1 parser compile succeed but still not able to parse any file Message-ID: Hello list! I think I've managed to compile GML parser with XSD. And despite I can't parse files because I always get the same error I'm pretty convinced that xsd is the correct way to go. I've uploaded what I have to the following url: http://superbumbot.sytes.net/xsd-gml/ It is all the schemas evolving GML 3.1.1 and fixed by codesynthesis guys, a hello world C++ file (hello_gml.cpp), a makefile for linux gcc and three gml sample files. The gml samples are quite simple. But when I run the hello_gml program (which just takes the first argument as the filename) I always get the follwing error. terminate called after throwing an instance of 'xsd::cxx::tree::parsing' what(): instance document parsing failed Aborted Summarizing, what I did is to compile each schema with --generate-serialization --generate-doxigen --generate-polymorphism. And in addition to these flags, I used --root-element _FeatureCollection for the feature.xsd schema. I did this because, for the moment I only want to take care about the feature model in GML. Maybe I did wrong with this decision. Having these settings, here is the output of the make command $ time make xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic basicTypes.xsd gcc -I.../libxsd -c basicTypes.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic xlinks.xsd gcc -I.../libxsd -c xlinks.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic gmlBase.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? gmlBase.xsd: warning: generating parsing and serialization functions for 14 global elements gmlBase.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c gmlBase.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic xml-mod.xsd gcc -I.../libxsd -c xml-mod.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic smil20-base.xsd gcc -I.../libxsd -c smil20-base.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic temporal.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? temporal.xsd: warning: generating parsing and serialization functions for 10 global elements temporal.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c temporal.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic dictionary.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? dictionary.xsd: warning: generating parsing and serialization functions for 8 global elements dictionary.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c dictionary.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic units.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? units.xsd: warning: generating parsing and serialization functions for 10 global elements units.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c units.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic dataQuality.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? dataQuality.xsd: warning: generating parsing and serialization functions for 10 global elements dataQuality.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c dataQuality.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic measures.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? measures.xsd: warning: generating parsing and serialization functions for 7 global elements measures.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c measures.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic geometryBasic0d1d.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? geometryBasic0d1d.xsd: warning: generating parsing and serialization functions for 17 global elements geometryBasic0d1d.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c geometryBasic0d1d.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic geometryBasic2d.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? geometryBasic2d.xsd: warning: generating parsing and serialization functions for 11 global elements geometryBasic2d.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c geometryBasic2d.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic referenceSystems.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? referenceSystems.xsd: warning: generating parsing and serialization functions for 14 global elements referenceSystems.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c referenceSystems.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic coordinateOperations.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? coordinateOperations.xsd: warning: generating parsing and serialization functions for 63 global elements coordinateOperations.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c coordinateOperations.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic direction.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? direction.xsd: warning: generating parsing and serialization functions for 3 global elements direction.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c direction.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic smil20-language.xsd smil20-language.xsd: warning: generating parsing and serialization functions for 4 global elements smil20-language.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c smil20-language.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic smil20.xsd smil20.xsd: warning: generating parsing and serialization functions for 4 global elements smil20.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c smil20.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic geometryPrimitives.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? geometryPrimitives.xsd: warning: generating parsing and serialization functions for 45 global elements geometryPrimitives.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c geometryPrimitives.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic geometryAggregates.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? geometryAggregates.xsd: warning: generating parsing and serialization functions for 31 global elements geometryAggregates.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c geometryAggregates.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic geometryComplexes.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? geometryComplexes.xsd: warning: generating parsing and serialization functions for 4 global elements geometryComplexes.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c geometryComplexes.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic topology.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? topology.xsd: warning: generating parsing and serialization functions for 27 global elements topology.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c topology.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic datums.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? datums.xsd: warning: generating parsing and serialization functions for 35 global elements datums.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c datums.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic coordinateSystems.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? coordinateSystems.xsd: warning: generating parsing and serialization functions for 30 global elements coordinateSystems.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c coordinateSystems.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic coordinateReferenceSystems.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? coordinateReferenceSystems.xsd: warning: generating parsing and serialization functions for 37 global elements coordinateReferenceSystems.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c coordinateReferenceSystems.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic --root-element _FeatureCollection feature.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? gcc -I.../libxsd -c feature.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic dynamicFeature.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? dynamicFeature.xsd: warning: generating parsing and serialization functions for 6 global elements dynamicFeature.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c dynamicFeature.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic valueObjects.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? valueObjects.xsd: warning: generating parsing and serialization functions for 16 global elements valueObjects.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c valueObjects.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic observation.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? observation.xsd: warning: generating parsing and serialization functions for 7 global elements observation.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c observation.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic temporalTopology.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? temporalTopology.xsd: warning: generating parsing and serialization functions for 4 global elements temporalTopology.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c temporalTopology.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic temporalReferenceSystems.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? temporalReferenceSystems.xsd: warning: generating parsing and serialization functions for 7 global elements temporalReferenceSystems.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c temporalReferenceSystems.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic defaultStyle.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? defaultStyle.xsd: warning: generating parsing and serialization functions for 14 global elements defaultStyle.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c defaultStyle.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic grids.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? grids.xsd: warning: generating parsing and serialization functions for 3 global elements grids.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c grids.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic coverage.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? coverage.xsd: warning: generating parsing and serialization functions for 26 global elements coverage.xsd: info: use --root-element-* options to specify document root(s) gcc -I.../libxsd -c coverage.cxx xsdcxx cxx-tree --generate-serialization --generate-doxygen --generate-polymorphic gml.xsd gmlBase.xsd:38:42: warning: element '_Object' is implicitly of anyType gmlBase.xsd:38:42: info: did you forget to specify 'type' attribute? gcc -I.../libxsd -c gml.cxx gcc -I.../libxsd -c hello_gml.cpp gcc -o hello_gml hello_gml.o gml.o basicTypes.o coverage.o dictionary.o geometryPrimitives.o geometryAggregates.o referenceSystems.o smil20.o temporal.o xlinks.o \ coordinateOperations.o dataQuality.o direction.o geometryBasic0d1d.o gmlBase.o measures.o smil20-base.o topology.o xml-mod.o \ coordinateReferenceSystems.o datums.o dynamicFeature.o geometryBasic2d.o observation.o smil20-language.o temporalReferenceSystems.o units.o \ coordinateSystems.o defaultStyle.o feature.o geometryComplexes.o grids.o temporalTopology.o valueObjects.o \ -lxerces-c chmod 755 hello_gml real 4m8.302s user 3m51.166s sys 0m13.501s As you see, it takes 4 minutes to compile everything Okay, so now when I call the resulting program with any of those three files I get this $ ./hello_gml line.gml terminate called after throwing an instance of 'xsd::cxx::tree::parsing' what(): instance document parsing failed Aborted If someone who has dealt with GML and XSD had success or someone can recognize what may be happening is so nice to give me a hand I would really appreciate it. My intention is to publish a how-to for very beginners like me to make this task easy for them. And of course, all the code will be shared. For example, may it be caused for any derived schema that is not available? Thanks a lot and hope not to bother with my questions. Jaume From boris at codesynthesis.com Mon Feb 16 07:36:50 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] GML3.1.1 parser compile succeed but still not able to parse any file In-Reply-To: References: Message-ID: Hi Jaume, Your email was held for moderation because its length exceeding the 40KB limit. jaume.faus@vianova.no writes: > But when I run the hello_gml program (which just takes the first > argument as the filename) always get the follwing error. > > terminate called after throwing an instance of > 'xsd::cxx::tree::parsing' > what(): instance document parsing failed > Aborted If you read the Getting Started Guide or study the examples, you will see that the code catches and prints xml_schema::exception to get more information about the error. If I change your code to wrap the call to the parsing function into this try-catch block: try { ... } catch (const xml_schema::exception& e) { cerr << e << endl; } And try to run it on your sample GML documents, I get: ./hello_gml polygon.gml :0:0 error: unable to resolve host/address 'aneto.oco' ./hello_gml point.gml :0:0 error: unable to resolve host/address 'aneto.oco' ./hello_gml line.gml line.gml:2:393 error: schemaLocation does not contain namespace-location pairs You may want to read Section 5.1, "XML Schema Validation and Searching" in the Getting Started Guide for some background information on this. I also noticed that the examples refer to the WFS-basic.xsd schema which is not compiled in your test application. > As you see, it takes 4 minutes to compile everything You can reduce it (along with the generated code size) by specifying the --root-element-none option for most of your schemas. Boris From boris at codesynthesis.com Mon Feb 16 08:03:03 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] sorting of a sequence of elements when IDs are contained, duplicate_id exception In-Reply-To: References: <499422C1.90607@hpi.uni-potsdam.de> Message-ID: <20090216130303.GA20838@karelia> Hi Jan, Boris Kolpackov writes: > Hm, that's an interesting problem. I think you are right about what > happens: std::sort() first inserts a new copy and then removes the > old one. So you end up with two objects with the same ID in the tree. Actually, there is another, bigger problem with this in that the sequence contains polymorphic objects and _clone() should be used instead of the copy constructor to copy them. > (1) Implement your own sort where you first remove the old element > from the sequence and then insert the new one. With this approach you should be able to use _clone() without any problems. > (2) Copy the contents of the sequence into another, "free-standing" > sequence which is not part of any object model. You can then sort > that sequence and copy the result back. There is quite a bit of > copying with this approach: > > TourSectionContainer tmp = tour->getTourSection(); > std::sort(tmp.begin(), tmp.end(), compareTourSectionBySectionNumber); > tour->getTourSection() = tmp; This approach will need to be modified slightly to work with polymorphic objects. Something along these lines: bool compareTourSectionBySectionNumber (gml::FeaturePropertyType* sec1, gml::FeaturePropertyType* sec2) { return (static_cast(sec1->getFeature())->getSectionNo() < static_cast(sec2->getFeature())->getSectionNo()); } TourSectionContainer& tsc = tour->getTourSection(); // Copy polymorphically into a temporary sort vector. // typedef std::vector SortVector; SortVector tmp; tmp.reserve (tsc.size ()); for (TourSectionIterator i (tsc.begin ()); i != tsc.end (); ++i) { tmp.push_back (i._clone ()); } // Sort. // std::sort(tmp.begin(), tmp.end(), compareTourSectionBySectionNumber); // Copy back. // tsc.clear (); for (SortVector::iterator i (tmp.begin ()); i != tmp.end (); ++i) { tsc.push_back (std::auto_ptr (*i)); } Boris From boris at codesynthesis.com Mon Feb 16 08:32:42 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Parsing and serializing large documents Message-ID: Hi Anatoly, Anatoly Borodyansky writes: > If I need to parse a large XML file, adjust some elements, and > serialize the whole structure again, what is the best way to do > it (it works beautifully with Tree, but my input Is too large > for it to handle) In XSD, currently, the only way is to use the C++/Parser mapping for parsing and perform custom XML serialization (you can either do it by hand if the XML vocabulary is quite simple or use an XML serializer such as GenX[1], libxml2, etc.) as your parse the input stream. In XSD/e[2], our mobile/embedded systems version of XSD, we have the C++/Serializer mapping which is a counterpart to the C++/Parser mapping in that it provides event-driven, stream-oriented XML serialization. You can certainly use XSD/e on general-purpose platforms as well. The only problem with using the C++/Parser and C++/Serializer mappings to perform the transformation you have described is that it is not easy to "pipe-line" them because they both are callback-based. One way to overcome this would be to have two threads with the first performing parsing and sending the modified data to the second thread which performs serialization (it is also possible to achieve the same with parser suspension though it is more complex). There is also a third mapping, C++/Hybrid, which can greatly simplify passing of the data around since it provides a light- weight object model on top of C++/Parser and C++/Serializer. The 'streaming' example in the examples/cxx/hybrid/ directory in the XSD/e distribution shows how to performs partially in- memory, partially event-driven XML processing (that is, you get the convenience of C++/Tree but handle the document in chunks). [1] http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus [2] http://www.codesynthesis.com/products/xsde/ Boris From bpringle at sympatico.ca Wed Feb 18 21:07:13 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Non-xml data in attributes with xsd:string, xsd:normalizedString Message-ID: <87r61vb2ni.fsf@sympatico.ca> I believe this problem is generic to C++ tree and not specific to any architecture [I am using RHEL 4.x, AIX 5.x, and debian lenny on (x86_64, Power3/4 and northwood chips)]. We are using data that is 99.9999% printable. However, there are occasional characters that violate the attribute values. For example, 'tabs', 'lf', 'cr', etc. I see that the normalizedString does seem to attempt to convert these to spaces; but only on parsing? The schema can be converted to use a binary type, but then the XML is un-readable and in-efficient. As most of the data is printable the occasional escape is more efficient. I have a full test case, but it is rather brief to just introduce the xml and schema. [test.xsd] [test.xml] blah test value - Harness code with the likes of, normTest copy("file"); //... copy.e1().append("\t\t\t\t\t\tno\ttabs?"); copy.a1().append("\t\t\t\t\t\tno\ttabs?"); Can generate serialization errors (actually parser errors on the other side, but it was actually an error to generate invalid XML unless it is program error not to put non-printables in the std::string?). Can I force the accessors to 'a1()', 'e1()' to escape strings? Can I customize just the 'operator<<()' to escape the data? Escaping on serialization seems the most efficient. Most parsers on the other side will barf if we include non-printable characters in the xsd:string space. Using xs:normalizedString would be acceptable, but it also seems to exhibit the same problems. It just enforce that input is normalized and not that someone has programatically altered the xsd_schema::string (aliased to std::string, etc.) with some non-XML data. Elements seem to handle this better, but the attributes provide a much better mapping in C++ space [ie, cardinal 'one']. Thanks. Bill Pringlemeir. From boris at codesynthesis.com Thu Feb 19 08:25:07 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Non-xml data in attributes with xsd:string, xsd:normalizedString In-Reply-To: <87r61vb2ni.fsf@sympatico.ca> References: <87r61vb2ni.fsf@sympatico.ca> Message-ID: Hi Bill, Bill Pringlemeir writes: > Harness code with the likes of, > > normTest copy("file"); //... > copy.e1().append("\t\t\t\t\t\tno\ttabs?"); > copy.a1().append("\t\t\t\t\t\tno\ttabs?"); > > Can generate serialization errors (actually parser errors on the other > side, but it was actually an error to generate invalid XML unless it > is program error not to put non-printables in the std::string?). I tried the above fragment with XSD 3.2.0 and both Xerces-C++ 2.8.0 and 3.0.0. I get the following XML: file no tabs? Is this not what you expect to get? Which version of Xerces-C++ are you using? Boris From bpringle at sympatico.ca Thu Feb 19 11:17:56 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Non-xml data in attributes with xsd:string, xsd:normalizedString In-Reply-To: (Boris Kolpackov's message of "Thu, 19 Feb 2009 15:25:07 +0200") References: <87r61vb2ni.fsf@sympatico.ca> Message-ID: <87bpsye6yz.fsf@sympatico.ca> On 19 Feb 2009, boris@codesynthesis.com wrote: > Bill Pringlemeir writes: >> Harness code with the likes of, >> normTest copy("file"); //... >> copy.e1().append("\t\t\t\t\t\tno\ttabs?"); >> copy.a1().append("\t\t\t\t\t\tno\ttabs?"); >> Can generate serialization errors (actually parser errors on the other >> side, but it was actually an error to generate invalid XML unless it >> is program error not to put non-printables in the std::string?). > I tried the above fragment with XSD 3.2.0 and both Xerces-C++ 2.8.0 > and 3.0.0. I get the following XML: > > file no tabs? > > Is this not what you expect to get? Which version of Xerces-C++ are you > using? You are correct. I think that I had put an invalid character entity like " " without an semi-colon and didn't pay attention to the Xerces message (and believed it was the same problem). I am using XSD 3.2.0 and Xerces-C++ 3.0.0. And this is the actual case, copy.e1().append("\x4"); copy.a1().append("\x4"); It appears that 'tab', etc are escaped. I guess that there is no allowable XML character reference for some values. I thought that only 'null'/zero would be disallowed. I see here, http://www.w3.org/TR/REC-xml/#NT-Char that XML has this restriction. In theory even '\0' can be put in a std::string; so it appears that decimal values of 0-8,11,12,14-31 are not allowed in the strings. It appears that 'CDATA' also does not allow escaping of these values. So it seems if the data contains this range, you must use 'base64Binary'? A problem is that the serializer doesn't bother to tell you that the value is illegal. If we are scannning for character entity escaping, cann't an exception be thrown when this value range is encountered? That would be more friendly in that the error would be closer to the source (as opposed to the opposite side which will retreives the bad XML). Alternatively the values could be stripped. Selectable via a flag to the serializer or class specific modifier. Ie, copy.a1().stripInvalidXml(true); // or some other simple_type method. copy.e1().stripInvalidXml(true); Sorry, my mistake with the 'semi-colon' confused me and made my original report nebulous. The invalid stripping could just as well be accomplished by user code, so perhaps an 'everything is stripped' or an exception is the best approach; especially as the modifier probably implies extra memory overhead. I will try to strip the values in my code that comes from 'untrusted sources'. This is difficult to guarantee and a XSD/serializer mechanism would be nicer. Thanks, Bill Pringlemeir. -- How do we make long-term thinking automatic and common instead of difficult and rare? - Stewart Brand From boris at codesynthesis.com Fri Feb 20 05:48:56 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Xerces-C++ 3.0.1 released Message-ID: Hi, Xerces-C++ 3.0.1 was released yesterday. This version contains a handful of minor memory leak and bug fixes and is binary- compatible with 3.0.0. For the official announcement please see: http://marc.info/?l=xerces-c-users&m=123505089705851&w=2 Source code as well as precompiled binaries for a range of platforms can be downloaded from the Xerces-C++ Download page: http://xerces.apache.org/xerces-c/download.cgi We have also repackaged the MSI installer for XSD 3.2.0 to include precompiled libraries for Xerces-C++ 3.0.1 instead of 3.0.0. The new installer can be downloaded via this link: http://www.codesynthesis.com/download/xsd/3.2/windows/i686/xsd-3.2.msi The new SHA sum: 5724ba32f21ea61c9d60dcf6359953ea46e38529 Enjoy, Boris From steve at finagle.org Fri Feb 20 12:20:09 2009 From: steve at finagle.org (Steve Sloan) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Code Generation with AutoTools Message-ID: <499EE649.5000701@finagle.org> I'm starting a project using XSD, but am having some trouble generating the C++ (tree) code with AutoTools. My simplistic approach was just to add the generated filenames (e.g. Schema.hxx, Schema.cxx) to the "app_SOURCES" line in Makefile.am, and add a rule to run XSD to create them from the .xsd file. I have two issues with this: 1. It tries to compile the generated files, fails because they don't exist, then generates them. On a fresh source tree, I have to run make twice to get a successful build. I suspect this is a side effect of libtool or automake. 2. The generated files must reside in $srcdir, instead of $builddir. This is only an issue when building under KDevelop, but it clutters up the source tree. Any advice would be greatly appreciated ... -- Steve From bpringle at sympatico.ca Fri Feb 20 15:55:38 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Code Generation with AutoTools In-Reply-To: <499EE649.5000701@finagle.org> (Steve Sloan's message of "Fri, 20 Feb 2009 09:20:09 -0800") References: <499EE649.5000701@finagle.org> Message-ID: <87wsbk25h1.fsf@sympatico.ca> On 20 Feb 2009, steve@finagle.org wrote: > 1. It tries to compile the generated files, fails because they don't > exist, then generates them. On a fresh source tree, I have to run > make twice to get a successful build. I suspect this is a side effect > of libtool or automake. I would take a look at the 'yacc' rules in other projects. Ie, some other project with a code generator. I have hand written makefile and use Gnu Make order-only rules to ensure that the files are built in a fresh build. Your depends should take care of incremental builds. I am pretty sure that this is not XSD specific. > 2. The generated files must reside in $srcdir, instead of > $builddir. This is only an issue when building under KDevelop, but it > clutters up the source tree. Try the '--output-dir' option. hth, Bill Pringlemeir. From boris at codesynthesis.com Sun Feb 22 11:46:30 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Code Generation with AutoTools In-Reply-To: <499EE649.5000701@finagle.org> References: <499EE649.5000701@finagle.org> Message-ID: Hi Steve, Steve Sloan writes: > I'm starting a project using XSD, but am having some trouble generating > the C++ (tree) code with AutoTools. My simplistic approach was just to > add the generated filenames (e.g. Schema.hxx, Schema.cxx) to the > "app_SOURCES" line in Makefile.am, and add a rule to run XSD to create > them from the .xsd file. Take a look at Section 9.4, "Built sources" in the automake documentation: http://sources.redhat.com/automake/automake.html#Sources I tried both approaches described there on the hello example. Here are the corresponding Makefile.am files: # Using BUILT_SOURCES. # bin_PROGRAMS = hello hello_SOURCES = driver.cxx hello.cxx hello_LDADD= -lxerces-c BUILT_SOURCES = hello.hxx hello.cxx CLEANFILES = hello.hxx hello.cxx XSD := xsd %.hxx %.cxx: %.xsd $(XSD) cxx-tree $(XSDFLAGS) $< # Using explicit dependecy tracking. # bin_PROGRAMS = hello hello_SOURCES = driver.cxx hello.cxx hello_LDADD= -lxerces-c CLEANFILES = hello.hxx hello.cxx driver.$(OBJEXT): hello.hxx hello.$(OBJEXT): hello.hxx XSD := xsd %.hxx %.cxx: %.xsd $(XSD) cxx-tree $(XSDFLAGS) $< Both of them work as expected both when building in the source directory and in a separate directory. The BUILT_SOURCES approach is easier, especially if you have many object files that depend on many generated header files. Boris From boris at codesynthesis.com Sun Feb 22 12:42:25 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Non-xml data in attributes with xsd:string, xsd:normalizedString In-Reply-To: <87bpsye6yz.fsf@sympatico.ca> References: <87r61vb2ni.fsf@sympatico.ca> <87bpsye6yz.fsf@sympatico.ca> Message-ID: Hi Bill, Bill Pringlemeir writes: > It appears that 'tab', etc are escaped. I guess that there is no > allowable XML character reference for some values. I thought that > only 'null'/zero would be disallowed. XML 1.0 disallows quite a few control characters. XML 1.1 only disallows zero. > So it seems if the data contains this range, you must use > 'base64Binary'? Correct. Or XML 1.1 which is supported by Xerces-C++. > A problem is that the serializer doesn't bother to tell you that > the value is illegal. If we are scanning for character entity > escaping, can't an exception be thrown when this value range is > encountered? Yes, I think that's how it should be. I filed a bug report and we will be fixing this for the next release of Xerces-C++: https://issues.apache.org/jira/browse/XERCESC-1854 The fix will most likely be to simply fail (i.e., no "remove bad characters for me, please" behavior). > I will try to strip the values in my code that comes from 'untrusted > sources'. You can do it this way or you can serialize the object model to a DOM document and then "sanitize" that document by detecting/removing bad characters. This way you can do it in one place and it will take just a few lines of code. Boris From boris at codesynthesis.com Sun Feb 22 12:56:43 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Re: Polymorphism enhancements. In-Reply-To: <877i4hlx11.fsf@sympatico.ca> References: <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> <877i4hlx11.fsf@sympatico.ca> Message-ID: Hi Bill, Bill Pringlemeir writes: > On 9 Jan 2009, boris@codesynthesis.com wrote: > > > 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. > > 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. Right, and auto_ptr c-tors are only a part of it. Parsing and serialization code for polymorphic objects is also more complex. > 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. That's one reason. And XSD will still generate auto_ptr versions for arguments with "complex" types (i.e., types that have elements or attributes). > XSD must be using _clone and the auto_ptr variant to make this work > in 'setXxxx'? Yes, modifiers always use _clone(). > 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 only tricky part is when you have a type and element defined in one schema and then include/import that schema in another schema which defines a substituting element. So when you compile the first schema without saying that the type is polymorphic, there is not way for XSD to detect this. But, when you compile the second schema and did not specify that the type in the included schema is polymorphic, we will issue a warning. Other cases (e.g., single schema with substitution groups) can be handled auto-magically. Overall, I think we will be able to make it quite robust. Boris From steve at finagle.org Sun Feb 22 20:09:43 2009 From: steve at finagle.org (Steve Sloan) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Code Generation with AutoTools In-Reply-To: References: <499EE649.5000701@finagle.org> Message-ID: <49A1F757.3020609@finagle.org> Boris Kolpackov wrote: >> I'm starting a project using XSD, but am having some trouble generating >> the C++ (tree) code with AutoTools. My simplistic approach was just to >> add the generated filenames (e.g. Schema.hxx, Schema.cxx) to the >> "app_SOURCES" line in Makefile.am, and add a rule to run XSD to create >> them from the .xsd file. > > Take a look at Section 9.4, "Built sources" in the automake documentation: > > http://sources.redhat.com/automake/automake.html#Sources That's exactly what I was looking for, thanks. -- Steve From greg at permedia.ca Mon Feb 23 12:07:34 2009 From: greg at permedia.ca (Greg Carter) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] (Windows) mixing debug/release Xerces lib In-Reply-To: References: <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> <877i4hlx11.fsf@sympatico.ca> Message-ID: Hello, We have an application that has a plug-in interface, where each plug-in is a separate dll on windows. We use XML extensively in the interface. It is conceivable that a 3rd party developing a plug-in will be using XSD/xerces. We designed the interface so that all new/delete of exported objects occurs within the plug-in dll. This way it doesn't matter if the plug-in is debug while the application calling the plug-in is built in release mode. However I have noticed that if the plug-in uses a different xerces lib (xerces-c_3_0D.dll vs xerces-c_3_0.dll) then in the parse routine for an XML type we get an access violation. If I switch the debug plug-in dll build to use xerces-c_3_0.dll, all is fine. Reading the xerces faq I found: http://xerces.apache.org/xerces-c/faq-build-2.html#faq-13 Is XSD generated code calling delete[] directly on the strings allocated by the xerces parser? Or is this another problem? If it is indeed calling delete[] directly, could it call XMLString::release() instead? According to the faq that would fix the problem. This isn't that big of a problem for us since I don't foresee us or our users debugging xerces code, but it would be one less thing to worry about. Thanks. Greg. From boris at codesynthesis.com Mon Feb 23 13:05:14 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] (Windows) mixing debug/release Xerces lib Message-ID: Hi Greg, Greg Carter writes: > We have an application that has a plug-in interface, where each plug-in > is a separate dll on windows. We use XML extensively in the interface. > It is conceivable that a 3rd party developing a plug-in will be using > XSD/xerces. We designed the interface so that all new/delete of > exported objects occurs within the plug-in dll. This way it doesn't > matter if the plug-in is debug while the application calling the plug-in > is built in release mode. However I have noticed that if the plug-in > uses a different xerces lib (xerces-c_3_0D.dll vs xerces-c_3_0.dll) then > in the parse routine for an XML type we get an access violation. If I > switch the debug plug-in dll build to use xerces-c_3_0.dll, all is > fine. What is the stack trace? Is it memory allocation related? Normally, when you try to free a memory block by calling a wrong heap, you get an assertion in VC++ runtime, not access violation. > Reading the xerces faq I found: > http://xerces.apache.org/xerces-c/faq-build-2.html#faq-13 Is any of the components in your application linking to the static VC++ runtime? If they all use DLL runtimes and, as you said, memory allocation does not cross plugin boundaries, then this shouldn't be a problem. > Is XSD generated code calling delete[] directly on the strings allocated > by the xerces parser? Or is this another problem? In the default configuration (XSD_USE_LCP is not defined), XSD- generated code does not call any Xerces-C++ code that allocates and returns strings. When XSD_USE_LCP is defined, XMLString::transcode is called but then we pass a memory manager to make sure that allocation and deallocation happens on the same heap. This memory manager is also used in the call to Base64::decode which allocates a byte array. Boris P.S.: Your email violates rule #2 in the Posting Guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml While you changed the subject in your reply, it still contains the wrong In-Reply-To header which breaks threading. See archives for example (your message is at the bottom): http://www.codesynthesis.com/pipermail/xsd-users/2009-February/thread.html From greg at permedia.ca Tue Feb 24 12:06:12 2009 From: greg at permedia.ca (Greg Carter) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] (Windows) mixing debug/release Xerces lib In-Reply-To: References: Message-ID: Boris Kolpackov wrote: > Hi Greg, > > Is any of the components in your application linking to the static > VC++ runtime? If they all use DLL runtimes and, as you said, memory > allocation does not cross plugin boundaries, then this shouldn't > be a problem. > > In the default configuration (XSD_USE_LCP is not defined), XSD- > generated code does not call any Xerces-C++ code that allocates and > returns strings. When XSD_USE_LCP is defined, XMLString::transcode > is called but then we pass a memory manager to make sure that > allocation and deallocation happens on the same heap. This memory > manager is also used in the call to Base64::decode which allocates > a byte array. > > They all use dll runtimes. Since the problem went away after switching the xerces lib I figured it must have been in how XSD used it, as the only call I make directly to xerces is the initialization call (XMLPlatformUtils::Initialize). However it sounds like XSD is doing all the right things. Must be something else that is causing the problem. It occurs somewhere in DOMImplementation* impl (DOMImplementationRegistry::getDOMImplementation (ls_id)); I'll look into it more when I have some time to figure out the exact cause. Thanks. From boris at codesynthesis.com Tue Feb 24 12:46:32 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] (Windows) mixing debug/release Xerces lib In-Reply-To: References: Message-ID: Hi Greg, Greg Carter writes: > They all use dll runtimes. Since the problem went away after switching > the xerces lib I figured it must have been in how XSD used it, as the > only call I make directly to xerces is the initialization call > (XMLPlatformUtils::Initialize). However it sounds like XSD is doing all > the right things. Must be something else that is causing the problem. > It occurs somewhere in DOMImplementation* impl > (DOMImplementationRegistry::getDOMImplementation (ls_id)); In my experience, access violation in getDOMImplementation() almost invariably means that XMLPlatformUtils::Initialize() hasn't been called. Perhaps here is what happens: when both plugins use the same Xerces-C++ DLL, dynamic linker only loads it once and the second plugin simply reuses the same Xerces-C++ DLL. When one plugin uses the release and the other uses the debug versions of Xerces-C++, since the DLL are different, the linker probably loads both of them. My guess would be that the second DLL does not get a call to its Initialize() (you may actually be calling Initialize() twice but both calls may be routed to the same DLL). I am no expert in dynamic linking on Windows so I don't know how loading of two DLLs with the same symbols should be handled by the application. Perhaps you can try to obtain the pointer to Initialize() dynamically using the DLL handle and call it via this pointer. Boris From boris at codesynthesis.com Fri Feb 27 09:40:03 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:08 2009 Subject: [xsd-users] Cxx-Tree binding the LandXML schema - Help accessint the elements data In-Reply-To: References: Message-ID: Hi Constantin, You sent your email to the wrong mailing list. xsde-users is for XSD/e while your question is for XSD and should be sent instead to xsd-user. In the future, please make sure you use the correct mailing list. Constantin Iacobescu writes: > Hello, > > I'm a bit beginner with XML parsing and less with XSD, so some help would be > appreciated. > > I'm using Windows version of XSD Cxx-Tree for binding the LandXML schema and > so on the binding was without errors. This is the command line used: > xsd cxx-tree --generate-serialization --generate-polymorphic > --generate-doxygen --generate-wildcard --generate-ostream --type-naming java > --function-naming java --file-per-type --namespace-map > http://www.landxml.org/schema/LandXML-1.0=LandXML_10 LandXML-1.0.xsd > > Then I'm parsing some xml file and display the content on the screen. > Striped code should be some like this: > > ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > using namespace xercesc; > > XMLPlatformUtils::Initialize (); > > try > { > namespace xml = xsd::cxx::xml; > > std::auto_ptr objLandXML ( > LandXML_10::parseLandXML(argv[1], xml_schema::Flags::dont_initialize)); > > LandXML_10::LandXML::CgPointsSequence& > cgPoints(objLandXML->getCgPoints()); > > for (LandXML_10::LandXML::CgPointsIterator ptsIter(cgPoints.begin()); > ptsIter != cgPoints.end (); > ++ptsIter) > { > LandXML_10::CgPoints::NameOptional& optName(ptsIter->getName()); > if (optName.present()) > cerr <<"name:"<< optName.get() << endl; > > LandXML_10::CgPoints::CgPointSequence > cgPoint(ptsIter->getCgPoint()); > > for (LandXML_10::CgPoints::CgPointIterator ptIter(cgPoint.begin()); > ptIter != cgPoint.end (); > ++ptIter) > { > LandXML_10::CgPoint::NameOptional& optCode(ptIter->getCode()); > if (optCode.present()) > cerr <<"code:" << optCode.get() << endl; > > cerr << *ptIter < ???????????? How to get the data stored here ????? The CgPoint type has mixed content. There are two ways to handle this. You can use the DOM association feature and retrieve the text from the corresponding DOM node. The 'mixed' example in the examples/cxx/tree/ directory shows how to do this. This method will only work for parsing. Alternatively, you can customize the generated CgPoint class and add a string member to it that will store the element value. You will also need to override the parsing constructor to extract the element value from DOMElement and store it in the member as well as the serialization operator to serialize the element value to DOMElement. The 'wildcard' example in the examples/cxx/tree/custom/ directory shows how to do something like this. For more information on type customization refer to the C++/Tree Mapping Customization Guide: http://wiki.codesynthesis.com/Tree/Customization_guide [The rest of the original email follows for context.] > > } > } > catch (const xml_schema::Exception& e) > { > cerr << e << endl; > } > > XMLPlatformUtils::Terminate (); > } > ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > > As can be seen I can access the elements and display the attributes of them. > Even more, using the --generate-ostream option I can display all the content > of an element attributes + data. > > My question is how I can get the data stored by a element in a std::string > for process it further more. > > I've tried to made something like this (like I seen in some example): > > DOMElement& e (*ptIter); > > But got a compiler error: >>> error C2440: 'initializing' : cannot convert > from 'LandXML_10::CgPoint' to 'xercesc_3_0::DOMElement &' > > Please if someone can give me some advices. Thanks > > Best Regards, > Constantin Iacobescu Boris