From boris at codesynthesis.com Sat Jul 1 15:50:30 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] SPAM on xsd-users Message-ID: <20060701195030.GB12842@karelia> Good day, There were a few SPAM messages that slipped through recently. Sorry about that. For those of you who are interested in the details, the first message (a few days ago) was a mis-moderation from my side. The more recent bunch was from a presumably malicious user who actually subscribed prior to posting. I have removed him from the mailing list and notified his ISP (The Planet) about the abuse. I also cleaned the archives of this junk. Again, sorry for the inconvenience. -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060701/74f56a68/attachment.pgp From boris at codesynthesis.com Sun Jul 2 14:41:11 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: [xsstl-users] Failed to use http://www.w3.org/2001/XMLSchema.xsd with the xds tool In-Reply-To: <1151852153.4420.24.camel@localhost> References: <1151852153.4420.24.camel@localhost> Message-ID: <20060702184111.GA15361@karelia> Hi David, First off, this a wrong mailing list ;-). xsstl-users is for XSSTL - XML Schema Standard Type Library. You probably want to use xsd-users for XSD (I've CC'ed xsd-users to this reply). David Eriksson writes: > I recently downloaded xds 2.1.1 and started experimenting a bit. > > Out of curiosity I tried to generate C++ code for > http://www.w3.org/2001/XMLSchema.xsd but it didn't go very well. > > First it complained a lot about the DTD defintions, so I removed the > DOCTYPE entry and continued. > > It also complained about "'http://www.w3.org/2001/xml.xsd' is not a > valid filesystem path" so I downloaded that file and provided the file > system path instead. > > After that, I get each of the following error messages at least once. I > have removed dups for brevity: > > [...] > > It looks like all of the errors are issues with the XML Schema itself, > am I right? This sort of question pops up periodically on the xmlschema-dev mailing list. The thing is XMLSchema.xsd is not really a valid XML Schema definition and as such is pretty useless. W3C people say it is not normative and is just for illustration. If you want to play with some real-world schemas, I suggest you take a look at the "Supported Standards and Schemas" page: http://codesynthesis.com/projects/xsd/extras/supported-schemas.xhtml It lists quite a few schemas from various industries. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060702/9ee4a698/attachment.pgp From Abhishek.Jain at honeywell.com Wed Jul 5 08:44:41 2006 From: Abhishek.Jain at honeywell.com (Abhishek, Jain (IE10)) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Error in driver.cpp file Message-ID: <4641FAFFE1203E48B6BD97A33AE16BB5CD6116@IE10EV801.global.ds.honeywell.com> Hi I generate the files using: xsd cxx-tree library.xsd --generate-serialization The following line prompts an error in driver.cpp file: xml_schema::namespace_infomap map; Error is: error C2039: 'namespace_infomap' : is not a member of 'xml_schema' I take library.xsd and driver.cpp from samples available in web site. Can you please let me know what could be the possibilities? Regards Abhishek Jain From boris at codesynthesis.com Wed Jul 5 14:13:04 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Error in driver.cpp file In-Reply-To: <4641FAFFE1203E48B6BD97A33AE16BB5CD6116@IE10EV801.global.ds.honeywell.com> References: <4641FAFFE1203E48B6BD97A33AE16BB5CD6116@IE10EV801.global.ds.honeywell.com> Message-ID: <20060705181304.GA11834@karelia> Hi Jain, Abhishek, Jain (IE10) writes: > I generate the files using: > > xsd cxx-tree library.xsd --generate-serialization Options should be specified before arguments. Try to move the --generate-serialization option before library.xsd: xsd cxx-tree --generate-serialization library.xsd hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060705/41c73786/attachment.pgp From mwburn at mhpcc.hpc.mil Fri Jul 7 23:57:23 2006 From: mwburn at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Adding namspaces Message-ID: <44AF2D23.6050306@mhpcc.hpc.mil> Boris, For are the CoT schemas that I technically don't control, the "root" elements have very generic names (event, request, etc.) that I'd like to protect again name collisions. Is there anyway to add a namespace to the generated cxx-tree classes? I've looked at the --namespace-map and "prologue/postlogue" options, but don't seem to see anyway to do it. If needed, I would be willing to add an "xsn" to the schema if the --namespace-map would work, I just don't know were to add it. Thanks, Matt From boris at codesynthesis.com Sat Jul 8 08:45:21 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <44AF2D23.6050306@mhpcc.hpc.mil> References: <44AF2D23.6050306@mhpcc.hpc.mil> Message-ID: <20060708124521.GA2273@karelia> Hi Matt, Matt Burnham writes: > For are the CoT schemas that I technically don't control, the "root" > elements have very generic names (event, request, etc.) that I'd like to > protect again name collisions. Is there anyway to add a namespace to > the generated cxx-tree classes? I've looked at the --namespace-map and > "prologue/postlogue" options, but don't seem to see anyway to do it. If > needed, I would be willing to add an "xsn" to the schema if the > --namespace-map would work, I just don't know were to add it. In 2.1.1 you will need to use the following option: --namespace-regex '/.* /foo::bar/' Here change foo::bar to whatever C++ namespace you need. In the upcoming 2.2.0, you will be able to write --namespace-map =foo::bar hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060708/61caf174/attachment.pgp From gerardlanois at gmail.com Mon Jul 10 19:37:24 2006 From: gerardlanois at gmail.com (Gerard Lanois) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Parser maintains state between parsing attempts? Message-ID: Version 1 of my program, works as expected (a Bannana arrives, and is successfully parsed): char* msg = ... // read text from somewhere std::istringstream iss(msg); try { std::auto_ptr b(Bannana(iss, xml_schema::flags::dont_validate)); } catch (...) { } ------------------------------------------------------------------ Version 2 of my program - doesn't work (explanation below). char* msg = ... // read text from somewhere std::istringstream iss(msg); try { std::auto_ptr a(Apple(iss, xml_schema::flags::dont_validate)); } catch (...) { } try { std::auto_ptr b(Bannana(iss, xml_schema::flags::dont_validate)); } catch (...) { } ---------------------------------------------------------- In this version of the program, the attempted parsing of an incoming Bannana causes the Apple to throw an execption, as you would expect. However, when the program makes the attempt to parse the Bannana as a Bannana, the parser fails. The error is occurring down inside template auto_ptr parse (xercesc::DOMInputSource const& is, xercesc::DOMErrorHandler& eh, properties const& prop, bool validate); which is a function in namespace xsd::cxx::xml::dom. This parse function (toward the bottom) has these lines of code: bits::error_handler_proxy ehp (eh); parser->setErrorHandler (&ehp); auto_ptr doc (parser->parse (is)); if (ehp.failed ()) doc.reset (); The call to parser->parse() is setting ehp.failed_ to true. I think this means that the failed attempt to parse a Bannana by the Apple constructor is leaving the DOMBuilder::parser() in a state where it cannot successfully parse anything further. Is there some initialization or re-initialization I should perform between the Apple and Bannana parsing attempts? What I'm trying to do: I have an input stream which can have two types of documents arriving (Apple, and Bannana). I don't have any way of knowing in advance what is going to arrive. Is there an easier way to find out what the document type is before submitting it? (brute force peeking into the document?) Thanks in advance for your help. -Gerard From mwburn at mhpcc.hpc.mil Mon Jul 10 17:59:50 2006 From: mwburn at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <20060708124521.GA2273@karelia> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> Message-ID: <44B2CDD6.9090202@mhpcc.hpc.mil> When I use this to add a namespace, the namespace is added, but then I get a lot of compiler errors when compiling the generated cxx file. Boris Kolpackov wrote: Hi Matt, Matt Burnham [1] writes: For are the CoT schemas that I technically don't control, the "root" elements have very generic names (event, request, etc.) that I'd like to protect again name collisions. Is there anyway to add a namespace to the generated cxx-tree classes? I've looked at the --namespace-map and "prologue/postlogue" options, but don't seem to see anyway to do it. If needed, I would be willing to add an "xsn" to the schema if the --namespace-map would work, I just don't know were to add it. In 2.1.1 you will need to use the following option: --namespace-regex '/.* /foo::bar/' Here change foo::bar to whatever C++ namespace you need. In the upcoming 2.2.0, you will be able to write --namespace-map =foo::bar hth, -boris References 1. mailto:mwburn@mhpcc.hpc.mil From boris at codesynthesis.com Tue Jul 11 05:13:36 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] xsd 2.2.0 released Message-ID: <20060711091336.GC10361@karelia> Good day, We've released xsd 2.2.0. The NEWS file entries for this version are as follows: * Detection of a version mismatch between the generated code and the runtime. C++/Tree * Escaping of a global element name that conflicts with a global type name. This is a backwards-incompatible change. Previous versions map them to the same name. * New options, --generate--insertion and --generate-extraction, trigger generation of (binary) data representation stream insertion and extraction operators, respectively. This allows one to serialize/deserialize in-memory representation to/from data representation streams such as XSD, CDR, etc. ACE CDR streams are supported out of the box (see the binary example). User-supplied streams can be used via an adaptation layer. * New serialization flag, no_xml_declaration, instructs the XML serialization functions to omit an XML declaration. This is useful for streaming serialization (see the streaming example). * Optimizations to reduce generated code size. C++/Parser * New options, --generate-validation and --suppress-validation, trigger and suppress generation of the validation code, respectively. The validation code is the implementation of the XML Schema validation in the generated code (also known as "perfect" parser). In this version validation of the element structure has been implemented. * New architecture for underlying XML parsers. This is a backwards- incompatible change. Existing applications will have to be modified. See examples for details. In addition to this, a number of bugs have been fixed. Thanks to the following individuals for reporting bugs and/or suggesting fixes and improvements: Ricky H Linh Moss, David R Cheung, Yeung Franklin Johnstun, Clifford Thomas Biedermann Anatolii Belomestnov Andrew Ward Matt Burnham Precompiled binary distributions for various platforms are available from the product's download page: http://codesynthesis.com/products/xsd/download.xhtml Source code for this release is available from the project's web page: http://codesynthesis.com/projects/xsd/ SHA1 checksums for the files: 17cd94b7e0dd0133899281c74533f3687cffae3a xsd-2.2.0.tar.bz2 5f975e6d3185c799f8566fb518a8194dc05d6dcf xsd_2.2.0-1_i386.deb 0f42dba3e852f0c5d46e51575e9030e3c5c238a8 xsd-2.2.0-1.i686.rpm 45dcdb6796a9f7ecc530fb4714d51ad52a030ad2 xsd-2.2.0-i686-linux-gnu.tar.bz2 63cd0a123d901023099578439afbe691af4ef9ac xsd_2.2.0-1_amd64.deb 4de69f2a0c8f594efc538617db848dd8f8bbd545 xsd-2.2.0-1.x86_64.rpm cdebb2a0e781cb1a517e8a9565b21b821d414ea8 xsd-2.2.0-x86_64-linux-gnu.tar.bz2 066b3d4471f1ce2d1c4c8acd3081f25d68f88067 xsd-2.2.0-hppa-hpux.tar.gz 37bdfbb27b6dee3832d7787dd2f96cbbcadb6b87 xsd-2.2.0-hppa-hpux.tar.bz2 1867eae9fe3d78fca557ba1af5ec58afaacbb2b5 xsd-2.2.0-powerpc-macosx.tar.bz2 c49548058c0a6414b39f00a0f0b4c974e6106088 xsd-2.2.0-sparc-solaris.tar.gz fb7318cb2ac75f93bcd07739d70ce5fd59b4fe80 xsd-2.2.0-sparc-solaris.tar.bz2 3cb618d634ebaefa48a2e45a28a7c8052629d78c xsd-2.2.0-i686-windows.zip have fun, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060711/6a6e21cd/attachment.pgp From boris at codesynthesis.com Tue Jul 11 09:51:17 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <44B2CDD6.9090202@mhpcc.hpc.mil> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> Message-ID: <20060711135117.GA11113@karelia> Hi Matt, Matt Burnham writes: > When I use this to add a namespace, the namespace is added, but then > I get a lot of compiler errors when compiling the generated cxx file. Hm, that's strange. I compiled CoT event.xsd with the following command (using XSD 2.1.1): $ xsd cxx-tree --namespace-regex '/.* /foo::bar/' event.xsd The resulting event.cxx compiles fine for me with g++. Can you provide exact steps to reproduce this error? Also note that if you have any .xsd files including or importing event.xsd, you will need to pass the --namespace-regex option above when you compile them. I also tried the new 2.2.0: $ xsd cxx-tree --namespace-map =foo::bar event.xsd And it also works fine. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060711/b1921a16/attachment.pgp From boris at codesynthesis.com Tue Jul 11 10:22:35 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Parser maintains state between parsing attempts? In-Reply-To: References: Message-ID: <20060711142235.GB11113@karelia> Hi Gerard, Gerard Lanois writes: > Version 2 of my program - doesn't work (explanation below). > > char* msg = ... // read text from somewhere > std::istringstream iss(msg); > > try { > std::auto_ptr a(Apple(iss, xml_schema::flags::dont_validate)); > } > catch (...) { > } > > try { > std::auto_ptr b(Bannana(iss, > xml_schema::flags::dont_validate)); > } > catch (...) { > } > > > In this version of the program, the attempted parsing of an incoming > Bannana causes the Apple to throw an execption, as you would > expect. > > However, when the program makes the attempt to parse the > Bannana as a Bannana, the parser fails. This is because the call to the Apple parser function has read all the data from iss (i.e., iss internal position is at the end of the string). You can fix this by "rewinding" the stream in your second try block: try { iss.seekg (0); // rewind to the beginning iss.clear (); // clear eof bit std::auto_ptr b(Bannana(iss, xml_schema::flags::dont_validate)); } > What I'm trying to do: I have an input stream which can have two > types of documents arriving (Apple, and Bannana). I don't have > any way of knowing in advance what is going to arrive. Is there > an easier way to find out what the document type is before > submitting it? (brute force peeking into the document?) The approach above should work though it is definitely not the most efficient one especially if your messages are large. If you want to get the best performance then you can split the parsing into two steps: parsing of XML to DOM and parsing DOM to Apple or Banana. Between the two stages you can insert a check which looks at the name of the root element and decides which parsing function to call. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060711/db6a4fcf/attachment.pgp From mwburn at mhpcc.hpc.mil Tue Jul 11 13:09:13 2006 From: mwburn at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <20060711135117.GA11113@karelia> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> Message-ID: <44B3DB39.7020607@mhpcc.hpc.mil> Boris , If I add the namespace to my test case (a simple event and embedded schema) it works fine, when I use the actual CoT schema's I get the errors. I'm using the following to generate the cxx-tree: xsd.exe cxx-tree --root-element event --morph-anonymous --namespace-regex /.*/cot/ --generate-inline --generate-ostream --generate-serialization cot_event.xsd In order to get the namespace added: 1 - I can't enclode the regex with quotes 2 - The first expression can't have a space 3 - I still need the --root-element and --morph-anonymous for the root event element I'm compiling with Visual Studio 7.1. I'm attaching a zip file containing the generated class along with the build log file. I'll also download and try 2.2.0 Thanks, Matt Boris Kolpackov wrote: Hi Matt, Matt Burnham [1] writes: When I use this to add a namespace, the namespace is added, but then I get a lot of compiler errors when compiling the generated cxx file. Hm, that's strange. I compiled CoT event.xsd with the following command (using XSD 2.1.1): $ xsd cxx-tree --namespace-regex '/.* /foo::bar/' event.xsd The resulting event.cxx compiles fine for me with g++. Can you provide exact steps to reproduce this error? Also note that if you have any .xsd files including or importing event.xsd, you will need to pass the --namespace-regex option above when you compile them. I also tried the new 2.2.0: $ xsd cxx-tree --namespace-map =foo::bar event.xsd And it also works fine. hth, -boris References 1. mailto:mwburn@mhpcc.hpc.mil -------------- next part -------------- A non-text attachment was scrubbed... Name: error.zip Type: application/octet-stream Size: 13907 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060711/c1b5db21/error.obj From sbalasub at qualcomm.com Wed Jul 12 02:48:34 2006 From: sbalasub at qualcomm.com (Balasubramanyam, Shivakumar) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Conditional parameters Message-ID: Is there support for conditional parameters in the schema ? Can we describe an element in the XSD to be conditional on a different element ? Thanks, Shiva From mwburn at mhpcc.hpc.mil Tue Jul 11 22:38:43 2006 From: mwburn at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <20060711135117.GA11113@karelia> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> Message-ID: <44B460B3.1020508@mhpcc.hpc.mil> Boris, I've upgraded to 2.2.0 and am using the --namespace-map to add in a namespace, and everything is working great (and the 2.2.0 release couldn't have come at a better time). I have one last issue that I need to fix ASAP. I need to create an in-memory tree and then serialize it to XML. I have it all working except for the "detail" section. When I parse this section, I use the keep-dom flag, and then load the various sub-schema's using the xerces DOMElement's. So I'm not sure how to "create" the tree on the fly. I'm assuming I need to create new DOMElements and populate them, but can't seem to get it working. Thanks, Matt Boris Kolpackov wrote: Hi Matt, Matt Burnham [1] writes: When I use this to add a namespace, the namespace is added, but then I get a lot of compiler errors when compiling the generated cxx file. Hm, that's strange. I compiled CoT event.xsd with the following command (using XSD 2.1.1): $ xsd cxx-tree --namespace-regex '/.* /foo::bar/' event.xsd The resulting event.cxx compiles fine for me with g++. Can you provide exact steps to reproduce this error? Also note that if you have any .xsd files including or importing event.xsd, you will need to pass the --namespace-regex option above when you compile them. I also tried the new 2.2.0: $ xsd cxx-tree --namespace-map =foo::bar event.xsd And it also works fine. hth, -boris References 1. mailto:mwburn@mhpcc.hpc.mil From boris at codesynthesis.com Wed Jul 12 11:59:59 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Conditional parameters In-Reply-To: References: Message-ID: <20060712155959.GA14902@karelia> Hi Shivakumar, Balasubramanyam, Shivakumar writes: > Is there support for conditional parameters in the schema ? > > Can we describe an element in the XSD to be conditional on a different > element ? No, there is no such mechanism in XML Schema. The closest you get are xsd:unique, xsd:key and xsd:keyref. BTW, for general questions about XML Schema I suggest you post to the xmlschema-dev[1] mailing list at W3C. This mailing is for questions about CodeSynthesis XSD - XML Schema to C++ data binding compiler. [1] http://lists.w3.org/Archives/Public/xmlschema-dev/ hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060712/16f5eb00/attachment.pgp From boris at codesynthesis.com Wed Jul 12 12:43:20 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <44B460B3.1020508@mhpcc.hpc.mil> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> <44B460B3.1020508@mhpcc.hpc.mil> Message-ID: <20060712164320.GB14902@karelia> Hi Matt, Matt Burnham writes: > I have one last issue that I need to fix ASAP. I need to create an > in-memory tree and then serialize it to XML. > > I have it all working except for the "detail" section. When I parse this > section, I use the keep-dom flag, and then load the various sub-schema's > using the xerces DOMElement's. So I'm not sure how to "create" the tree > on the fly. I'm assuming I need to create new DOMElements and populate > them, but can't seem to get it working. The easiest way to achieve this is to (1) serialize event and embedded_data into two separate DOM documents, then (2) move the embedded_data sub-tree to the event document, and finally (3) write the resulting DOM document to XML. The code for these operations will look something like this: (1): using namespace xerces-c namespace xml = xsd:cxx::xml; namespace dom = xml::dom; event_type& e = ... embedded_data_type& ed = ... dom::auto_ptr event_doc (event (e)); dom::auto_ptr ed_doc (detail (ed)); (2): DOMElement* ed_el (ed_doc->getDocumentElement ()); // 'embedded_data' element event_doc->adoptNode (ed_el); // ed_el not belongs to event_doc // Now we need to insert the embedded_data element (ed_el) in the right // place in the event document. // DOMElement* event_el (event_doc->getDocumentElement ()) // 'event' element DOMNodeList* nl (event_el->getElementsByTagName("detail")); DOMElement* detail_el (static_cast (nl->item (0))); detail_el->appendChild (ed_el); // insert 'embedded_data' element (3): // See Xerces-C++ examples for more information. // DOMImplementation* impl ( DOMImplementationRegistry::getDOMImplementation ( xml::string ("LS").c_str ())); dom::auto_ptr writer (impl->createDOMWriter ()); if (writer->canSetFeature (XMLUni::fgDOMWRTDiscardDefaultContent, true)) writer->setFeature (XMLUni::fgDOMWRTDiscardDefaultContent, true); if (writer->canSetFeature (XMLUni::fgDOMWRTFormatPrettyPrint, true)) writer->setFeature (XMLUni::fgDOMWRTFormatPrettyPrint, true); LocalFileFormatTarget ft ("out.xml"); writer->writeNode (&ft, *event_doc); hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060712/a22e0002/attachment.pgp From mwburn at mhpcc.hpc.mil Wed Jul 12 22:36:47 2006 From: mwburn at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <20060712164320.GB14902@karelia> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> <44B460B3.1020508@mhpcc.hpc.mil> <20060712164320.GB14902@karelia> Message-ID: <44B5B1BF.7090109@mhpcc.hpc.mil> Boris, I understand the concepts of this, but can't get the implementation to work. I've attached a test case that has an "event" schema and "embedded" sub-schema. The code I'm trying to get working is the createXML() function in test_xsd.cxx, where I create an event "tree" and an "embedded" tree and then need to "add" the embedded tree to the detail element of the event. I'm trying to create the same xml "string" that is in the test_event.xml file. Thanks, Matt Boris Kolpackov wrote: Hi Matt, Matt Burnham [1] writes: I have one last issue that I need to fix ASAP. I need to create an in-memory tree and then serialize it to XML. I have it all working except for the "detail" section. When I parse this section, I use the keep-dom flag, and then load the various sub-schema's using the xerces DOMElement's. So I'm not sure how to "create" the tree on the fly. I'm assuming I need to create new DOMElements and populate them, but can't seem to get it working. The easiest way to achieve this is to (1) serialize event and embedded_data into two separate DOM documents, then (2) move the embedded_data sub-tree to the event document, and finally (3) write the resulting DOM document to XML. The code for these operations will look something like this: (1): using namespace xerces-c namespace xml = xsd:cxx::xml; namespace dom = [2]xml::dom; event_type& e = ... embedded_data_type& ed = ... dom::auto_ptr event_doc (event (e)); dom::auto_ptr ed_doc (detail (ed)); (2): DOMElement* ed_el (ed_doc->getDocumentElement ()); // 'embedded_data' element event_doc->adoptNode (ed_el); // ed_el not belongs to event_doc // Now we need to insert the embedded_data element (ed_el) in the right // place in the event document. // DOMElement* event_el (event_doc->getDocumentElement ()) // 'event' element DOMNodeList* nl (event_el->getElementsByTagName("detail")); DOMElement* detail_el (static_cast (nl->item (0))); detail_el->appendChild (ed_el); // insert 'embedded_data' element (3): // See Xerces-C++ examples for more information. // DOMImplementation* impl ( DOMImplementationRegistry::getDOMImplementation ( [3]xml::string ("LS").c_str ())); dom::auto_ptr writer (impl->createDOMWriter ()); if (writer->canSetFeature (XMLUni::fgDOMWRTDiscardDefaultContent, true)) writer->setFeature (XMLUni::fgDOMWRTDiscardDefaultContent, true); if (writer->canSetFeature (XMLUni::fgDOMWRTFormatPrettyPrint, true)) writer->setFeature (XMLUni::fgDOMWRTFormatPrettyPrint, true); LocalFileFormatTarget ft ("out.xml"); writer->writeNode (&ft, *event_doc); hth, -boris References 1. mailto:mwburn@mhpcc.hpc.mil 2. xml::dom 3. xml::string -------------- next part -------------- A non-text attachment was scrubbed... Name: test_xsd.zip Type: application/octet-stream Size: 18323 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060712/04a88983/test_xsd.obj From boris at codesynthesis.com Thu Jul 13 10:55:53 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <44B5B1BF.7090109@mhpcc.hpc.mil> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> <44B460B3.1020508@mhpcc.hpc.mil> <20060712164320.GB14902@karelia> <44B5B1BF.7090109@mhpcc.hpc.mil> Message-ID: <20060713145553.GA17294@karelia> Hi Matt, Matt Burnham writes: > I understand the concepts of this, but can't get the implementation to > work. I've attached a test case that has an "event" schema and "embedded" > sub-schema. While we only help with your application code if you have a priority support contract with us, I guess we can make an exception ;-). I've fixed your example to print: Two things you need to do to get it working: (1) Recompile embedded.xsd with --root-element embedded instead of --root-element-none because we need serialization functions for the embedded element. (2) Here is the modified createXML function: void createXML() { foo::type event_type( "embedded" ); foo::stuff my_stuff( "test" ); foo::event my_event( my_stuff, event_type ); my_event.detail (foo::detail ()); // create empty detail element foo::embedded::attr1::type a1( "X" ); foo::embedded::attr2::type a2( "Y" ); foo::embedded my_embedded( a1, a2 ); std::cerr << "event: " << my_event << std::endl; std::cerr << std::endl; std::cerr << "embedded: " << my_embedded << std::endl; std::ostringstream buff; using namespace xercesc; namespace xml = xsd::cxx::xml; namespace dom = xml::dom; XMLPlatformUtils::Initialize (); { // (1) serialize event and embedded into two separate DOM documents xml_schema::namespace_infomap nsm; dom::auto_ptr event_doc( foo::event_(my_event, nsm) ); dom::auto_ptr embedded_doc( foo::embedded_(my_embedded, nsm) ); // (2) copy the embedded sub-tree to the event document DOMElement* ed_el( embedded_doc->getDocumentElement() ); // 'embedded' element DOMNode* ed_el_copy (event_doc->importNode( ed_el, true)); // Now we need to insert the embedded element (ed_el_copy) in // the right place in the event document. DOMElement* event_el( event_doc->getDocumentElement() ); // 'event' element DOMNodeList* nl( event_el->getElementsByTagName(xml::string ("detail").c_str ())); DOMElement* detail_el( static_cast(nl->item (0)) ); detail_el->appendChild (ed_el_copy); // insert 'embedded' element // (3) write the resulting DOM document to XML DOMImplementation* impl( DOMImplementationRegistry::getDOMImplementation( xml::string("LS").c_str()) ); std::auto_ptr writer( impl->createDOMWriter() ); if( writer->canSetFeature(XMLUni::fgDOMWRTDiscardDefaultContent, true) ) { writer->setFeature( XMLUni::fgDOMWRTDiscardDefaultContent, true ); } if( writer->canSetFeature(XMLUni::fgDOMWRTFormatPrettyPrint, true) ) { writer->setFeature( XMLUni::fgDOMWRTFormatPrettyPrint, true ); } dom::ostream_format_target ft (buff); writer->writeNode (&ft, *event_doc); } XMLPlatformUtils::Terminate (); std::cerr << std::endl; std::cerr << buff.str() << std::endl; } hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060713/53a75ffb/attachment.pgp From boris at codesynthesis.com Thu Jul 13 11:38:49 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Adding namspaces In-Reply-To: <44B3DB39.7020607@mhpcc.hpc.mil> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> <44B3DB39.7020607@mhpcc.hpc.mil> Message-ID: <20060713153849.GB17294@karelia> Hi Matt, Matt Burnham writes: > If I add the namespace to my test case (a simple event and embedded > schema) it works fine, when I use the actual CoT schema's I get the > errors. > > I'm using the following to generate the cxx-tree: > > xsd.exe cxx-tree --root-element event --morph-anonymous --namespace-regex > /.*/cot/ --generate-inline --generate-ostream --generate-serialization > cot_event.xsd > > In order to get the namespace added: > 1 - I can't enclode the regex with quotes > 2 - The first expression can't have a space > 3 - I still need the --root-element and --morph-anonymous for the root > event element I tracked this problem down, in case you are interested. When you remove the space from '/.* /cot/', it starts to also match XML Schema namespace (actually it matches any XML namespace). As a result, both XML Schema and CoT types are generated into the same C++ namespace (cot). It happened that both namespaces define types with name 'type' which results in redefinition. I think on Windows you can use " instead of ', e.g., --namespace-regex "/.* /cot/" hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060713/a32f4c81/attachment.pgp From mwburn at mhpcc.hpc.mil Thu Jul 13 22:21:33 2006 From: mwburn at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Setting element text content In-Reply-To: <20060712164320.GB14902@karelia> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> <44B460B3.1020508@mhpcc.hpc.mil> <20060712164320.GB14902@karelia> Message-ID: <44B6FFAD.6010403@mhpcc.hpc.mil> Boris, If I have the following schema: And I'm generating the cxx-tree, in memory with the following code: stuff::attr1::type a1( "X" ); stuff my_stuff( a1 ); std::string data = "Text Goes Here"; dom::auto_ptr dom_doc( stuff_(my_stuff, nsm) ); XMLCh *xml_data = xercesc::XMLString::transcode( data.c_str() ); dom_doc->setTextContent( xml_data); xercesc::XMLString::release( &xml_data ); // serialize DOMDodument back to xml I get the following: How can I add "text content" to the element to generate the following xml: Text Goes Here Thanks, Matt From boris at codesynthesis.com Fri Jul 14 02:56:35 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Setting element text content In-Reply-To: <44B6FFAD.6010403@mhpcc.hpc.mil> References: <44AF2D23.6050306@mhpcc.hpc.mil> <20060708124521.GA2273@karelia> <44B2CDD6.9090202@mhpcc.hpc.mil> <20060711135117.GA11113@karelia> <44B460B3.1020508@mhpcc.hpc.mil> <20060712164320.GB14902@karelia> <44B6FFAD.6010403@mhpcc.hpc.mil> Message-ID: <20060714065635.GA19497@karelia> Hi Matt, Matt Burnham writes: > If I have the following schema: > > > > > > > > And I'm generating the cxx-tree, in memory with the following code: > > stuff::attr1::type a1( "X" ); > stuff my_stuff( a1 ); > std::string data = "Text Goes Here"; > dom::auto_ptr dom_doc( stuff_(my_stuff, nsm) ); > XMLCh *xml_data = xercesc::XMLString::transcode( data.c_str() ); > dom_doc->setTextContent( xml_data); > xercesc::XMLString::release( &xml_data ); > > // serialize DOMDodument back to xml > > I get the following: > > > > How can I add "text content" to the element to generate the following xml: > > Text Goes Here Well, you realize that this document is not valid per your schema (e.g., if you try to parse it back with validation enabled, you will get a parsing error). To set text content for a DOM element you will need to call setTextContent on that node (as opposed to on the document node as you've done above): DOMElement* e (dom_doc->getDocumentElement ()); 'stuff' e->setTextContent (xml_data); Also note that this is a question about DOM rather than XSD which this mailing list is for. I suggest for question like this you use Xerces-C++ documentation[1], examples[2] and mailing lists[3]. In particular, the CreateDOMDocument example does exactly what you've asked. [1] http://xml.apache.org/xerces-c/program.html [2] http://xml.apache.org/xerces-c/samples.html [3] http://xml.apache.org/xerces-c/feedback.html hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060714/54df0d32/attachment.pgp From Henrik.buchholz at hpi.uni-potsdam.de Wed Jul 19 13:30:13 2006 From: Henrik.buchholz at hpi.uni-potsdam.de (Buchholz Henrik) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] GML classes Message-ID: <5AC0F51A926CD442BC08D55DA7DAB1D4036E37AC@3mxma1r.hpi.uni-potsdam.de> Hi, I am searching for a way to generate C++ classes from the CityGML schema, which is built on GML. I found GML in the list of schemas that have successfully been processed with xsd. I tried it out - including the recommended "--generate-polymorphic" option - but got a large number of errors like this: "citygml.xsd:1105:49: error: Recurse: There is not a complete functional mapping between the particles" I googled for this error and found out that other people also had this problem, but found no solution. Is there a way to fix these errors without having to change the schema? Thx, Henrik From boris at codesynthesis.com Thu Jul 20 03:07:46 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] GML classes In-Reply-To: <5AC0F51A926CD442BC08D55DA7DAB1D4036E37AC@3mxma1r.hpi.uni-potsdam.de> References: <5AC0F51A926CD442BC08D55DA7DAB1D4036E37AC@3mxma1r.hpi.uni-potsdam.de> Message-ID: <20060720070746.GA7695@karelia> Hi Henrik, Buchholz Henrik writes: > I am searching for a way to generate C++ classes from the CityGML > schema, which is built on GML. I found GML in the list of schemas that > have successfully been processed with xsd. I tried it out - including > the recommended "--generate-polymorphic" option - but got a large number > of errors like this: > > "citygml.xsd:1105:49: error: Recurse: There is not a complete functional > mapping between the particles" > > I googled for this error and found out that other people also had this > problem, but found no solution. Is there a way to fix these errors > without having to change the schema? If you look at the supported schema list, GML section[1] you will see that the supported version is 3.1.1s which is (quoting from the readme.txt): "a version of the GML 3.1.1 schema with all "deprecated" components removed. This copy of the schema is provided for convenience in developing new application schemata to ensure that they do not use any deprecated components." This version was given to me by James Boyden of The University of Sydney. He is working on the GPlates project which uses GML. He posted quite a few emails about GML to this mailing list; you might be interested in searching for them or getting in contact with him. I could not find GML 3.1.1s on the www.opengeospatial.org so if you would like I can send you the archive. As of the error you see, it is a bug[2] in the Xerces-C++ schema processor. You can improve its chances of being fixed for Xerces-C++ 3.0.0 by voting on it. [1] http://codesynthesis.com/projects/xsd/extras/supported-schemas.xhtml#gml [2] https://issues.apache.org/jira/browse/XERCESC-1281 hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060720/1295fa43/attachment.pgp From boris at codesynthesis.com Thu Jul 20 06:02:10 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] GML classes In-Reply-To: <5AC0F51A926CD442BC08D55DA7DAB1D4036E37E9@3mxma1r.hpi.uni-potsdam.de> References: <20060720070746.GA7695@karelia> <5AC0F51A926CD442BC08D55DA7DAB1D4036E37E9@3mxma1r.hpi.uni-potsdam.de> Message-ID: <20060720100210.GA8237@karelia> Hi Henrik, Buchholz Henrik writes: > If it makes you not too much effort, I would be grateful if you could > send me the GML3.1.1s files you mentioned. Here you go: http://codesynthesis.com/~boris/tmp/gml-3.1.1s.tar.gz Note that it still includes deprecated and unused files; their inclusion was just commented out (see gml.xsd). hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060720/a61aba41/attachment.pgp From Suresh.M at Honeywell.com Fri Jul 28 07:40:42 2006 From: Suresh.M at Honeywell.com (Suresh, M (IE10)) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] problem in generating Parser template.. Message-ID: <3C4E17A26BBEE549A90182CE51DA92056426DC@AZ18EV805.global.ds.honeywell.com> Hi, I am very new to XML parser and using this tool. I went through the details in the web and tried the example given in website(C++/Parser). I am not able to generate parser templates from Schema hello.xsd. When I run this command xsd cxx-parser hello.xsd under suse linux..it gives the following error.. "Can only generate one of classes or datasets." Can you please help me in solving this problem.. Thanks.. Regards Suresh From boris at codesynthesis.com Fri Jul 28 08:06:45 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] problem in generating Parser template.. In-Reply-To: <3C4E17A26BBEE549A90182CE51DA92056426DC@AZ18EV805.global.ds.honeywell.com> References: <3C4E17A26BBEE549A90182CE51DA92056426DC@AZ18EV805.global.ds.honeywell.com> Message-ID: <20060728120645.GA27060@karelia> Hi, Suresh, M (IE10) writes: > I am not able to generate parser templates from Schema hello.xsd. > > When I run this command xsd cxx-parser hello.xsd under suse linux..it > gives the following error.. > > > > "Can only generate one of classes or datasets." Our compiler never prints a message like this. I think you have some other tool with the name 'xsd' in your path. To see which program gets executed when you type xsd run 'which' in your shell: $ which xsd You can also run this command in the shell: $ xsd --version With CodeSynthesis XSD it should print something like this: XML Schema Definition Compiler 2.2.0 Copyright (C) 2005-2006 Code Synthesis Tools CC This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may resolve your issue by specifying the full path to the CodeSynthesis XSD executable, e.g., $ ~/xsd-2.2.0-i686-linux-gnu/bin/xsd cxx-parser hello.xsd hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060728/b34e9b2e/attachment.pgp From David.Miller at kbcfp.com Fri Jul 28 08:42:19 2006 From: David.Miller at kbcfp.com (Miller, David) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] x86 for Solaris Message-ID: We are successfully using xsd to generate documents based on FpML and are find the generated code very useful. I think we should be able to compile our own version if needed, but are there any plans to have a built version available for Solaris x86 ? ----- This message may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived by any transmission to an unintended recipient. If you are not an intended recipient, please notify the sender and delete this message immediately. Any views expressed in this message are those of the sender, not those of KBC Financial Products or any affiliate thereof. This message does not create any obligation, contractual or otherwise, on the part of any such entity. It is not an offer (or solicitation of an offer) of, or a recommendation to buy or sell, any financial product. Any prices or other values included in this message are indicative only, and do not necessarily represent current market prices, the prices at which any KBC entity would enter into a transaction or the prices at which similar transactions may be carried on that entity's own books. The information contained in this message is provided "as is", without representations or warranties, express or implied, of any kind. Past performance is not indicative of future returns. From boris at codesynthesis.com Fri Jul 28 08:49:48 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] x86 for Solaris In-Reply-To: References: Message-ID: <20060728124948.GA27176@karelia> Hi David, Miller, David writes: > We are successfully using xsd to generate documents based on FpML and > are find the generated code very useful. Great! Thanks for letting us know. > I think we should be able to compile our own version if needed, but are > there any plans to have a built version available for Solaris x86 ? I will build one now. Should be ready in a couple of hours. I will let you know. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060728/f09a4985/attachment.pgp From boris at codesynthesis.com Fri Jul 28 11:10:18 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] xsd-2.2.0-i686-solaris released Message-ID: <20060728151018.GA27588@karelia> Hi, We've released precompiled binaries of XSD for Solaris x86. They can be downloaded from the usual place: http://codesynthesis.com/products/xsd/download.xhtml SHA1 checksums for the files are as follows: ed88368b15a7c02d5b8d14da9bf6aabe08ec02b0 xsd-2.2.0-i686-solaris.tar.bz2 b47720c2a0e1a5cc57cfd6a189f0ca8d9437a4cc xsd-2.2.0-i686-solaris.tar.gz have fun, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060728/55213b0a/attachment.pgp From Suresh.M at Honeywell.com Mon Jul 31 02:47:33 2006 From: Suresh.M at Honeywell.com (Suresh, M (IE10)) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] problem in generating Parser template.. In-Reply-To: <20060728120645.GA27060@karelia> Message-ID: <3C4E17A26BBEE549A90182CE51DA920567A0CD@AZ18EV805.global.ds.honeywell.com> Hi, Thankyou so much... Regards Suresh -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, July 28, 2006 5:37 PM To: Suresh, M (IE10) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] problem in generating Parser template.. Hi, Suresh, M (IE10) writes: > I am not able to generate parser templates from Schema hello.xsd. > > When I run this command xsd cxx-parser hello.xsd under suse linux..it > gives the following error.. > > > > "Can only generate one of classes or datasets." Our compiler never prints a message like this. I think you have some other tool with the name 'xsd' in your path. To see which program gets executed when you type xsd run 'which' in your shell: $ which xsd You can also run this command in the shell: $ xsd --version With CodeSynthesis XSD it should print something like this: XML Schema Definition Compiler 2.2.0 Copyright (C) 2005-2006 Code Synthesis Tools CC This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may resolve your issue by specifying the full path to the CodeSynthesis XSD executable, e.g., $ ~/xsd-2.2.0-i686-linux-gnu/bin/xsd cxx-parser hello.xsd hth, -boris From rschmilinsky at yahoo.ca Mon Jul 31 06:09:07 2006 From: rschmilinsky at yahoo.ca (Remsy Schmilinsky) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] unicode support Message-ID: <20060731100907.3994.qmail@web53906.mail.yahoo.com> Hi. I modified the parser-rules.make for the hello example to enable --char-type wchar_t option because I need my application to support unicode. Now the driver application won't compile, I get the following errors. What do I have to change? It looks like string is no longer the appropiate data type at line 52 of driver.cxx. The application works fine if I don't activate char-type option as wchar_t. Please help. xsd cxx-parser --xml-parser xerces --char-type wchar_t --hxx-suffix .h hello.xsd g++ -Wall -g -I/usr/local/include -c driver.cpp driver.cpp: In function ?int main(int, char**)?: driver.cpp:52: error: no matching function for call to ?hello_parser::greeting_parser(xml_schema::string&)? hello.txx:48: note: candidates are: void _xsd_hello_type::hello_type<_xsd_greeting_, _xsd_name_>::greeting_parser(xsd::cxx::parser::parser&) [with _xsd_greeting_ = std::basic_string, std::allocator >, _xsd_name_ = std::basic_string, std::allocator >] driver.cpp:53: error: no matching function for call to ?hello_parser::name_parser(xml_schema::string&)? hello.txx:59: note: candidates are: void _xsd_hello_type::hello_type<_xsd_greeting_, _xsd_name_>::name_parser(xsd::cxx::parser::parser<_xsd_name_, wchar_t>&) [with _xsd_greeting_ = std::basic_string, std::allocator >, _xsd_name_ = std::basic_string, std::allocator >] driver.cpp:59: error: no matching function for call to ?xml_schema::document::document(hello_parser&, const char [6])? hello.h:89: note: candidates are: xml_schema::document::document(xsd::cxx::parser::parser&, const std::basic_string, std::allocator >&, const std::basic_string, std::allocator >&) [with X = void] hello.h:80: note: xml_schema::document::document(xsd::cxx::parser::parser&, const std::basic_string, std::allocator >&) [with X = void] hello.h:78: note: xml_schema::document::document(const xml_schema::document&) /usr/local/include/xercesc/sax/InputSource.hpp:244: error: ?xercesc_2_7::InputSource::InputSource(const char*, xercesc_2_7::MemoryManager*)? is protected driver.cpp:61: error: within this context driver.cpp:61: error: cannot allocate an object of abstract type ?const xercesc_2_7::InputSource? /usr/local/include/xercesc/sax/InputSource.hpp:63: note: because the following virtual functions are pure within ?const xercesc_2_7::InputSource?: /usr/local/include/xercesc/sax/InputSource.hpp:91: note: virtual xercesc_2_7::BinInputStream* xercesc_2_7::InputSource::makeStream() const driver.cpp:65: error: no match for ?operator<& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ostream<_CharT, _Traits>& (*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:78: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_ios<_CharT, _Traits>& (*)(std::basic_ios<_CharT, _Traits>&)) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:90: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::ios_base& (*)(std::ios_base&)) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:125: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:159: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:102: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:176: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:187: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(short unsigned int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:191: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:202: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(unsigned int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:183: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:218: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long long unsigned int) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:242: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(double) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:217: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(float) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:265: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(long double) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:288: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(const void*) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:311: note: std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT, _Traits>::operator<<(std::basic_streambuf<_CharT, _Traits>*) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:502: note: std::basic_ostream& std::operator<<(std::basic_ostream&, const unsigned char*) [with _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:497: note: std::basic_ostream& std::operator<<(std::basic_ostream&, const signed char*) [with _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:616: note: std::basic_ostream& std::operator<<(std::basic_ostream&, const char*) [with _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:571: note: std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const char*) [with _CharT = char, _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:463: note: std::basic_ostream& std::operator<<(std::basic_ostream&, unsigned char) [with _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:458: note: std::basic_ostream& std::operator<<(std::basic_ostream&, signed char) [with _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/bits/ostream.tcc:509: note: std::basic_ostream& std::operator<<(std::basic_ostream&, char) [with _Traits = std::char_traits] /usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../include/c++/4.0.3/ostream:447: note: std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, char) [with _CharT = char, _Traits = std::char_traits] /usr/include/xsd/cxx/parser/exceptions.hxx:28: note: std::basic_ostream >& xsd::cxx::parser::operator<<(std::basic_ostream >&, const xsd::cxx::parser::exception&) /usr/include/xsd/cxx/parser/exceptions.ixx:130: note: std::basic_ostream >& xsd::cxx::parser::operator<<(std::basic_ostream >&, const xsd::cxx::parser::errors&) /usr/include/xsd/cxx/parser/exceptions.ixx:119: note: std::basic_ostream >& xsd::cxx::parser::operator<<(std::basic_ostream >&, const xsd::cxx::parser::error&) make: *** [driver.o] Error 1 --------------------------------- Make free worldwide PC-to-PC calls. Try the new Yahoo! Canada Messenger with Voice From boris at codesynthesis.com Mon Jul 31 06:30:19 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] unicode support In-Reply-To: <20060731100907.3994.qmail@web53906.mail.yahoo.com> References: <20060731100907.3994.qmail@web53906.mail.yahoo.com> Message-ID: <20060731103019.GA6575@karelia> Remsy Schmilinsky writes: > Hi. I modified the parser-rules.make for the hello example to enable > --char-type wchar_t option because I need my application to support > unicode. > > Now the driver application won't compile, I get the following errors. > What do I have to change? It looks like string is no longer the > appropiate data type at line 52 of driver.cxx. The application works > fine if I don't activate char-type option as wchar_t. Please help. When compiled with wchar_t, the generated code uses wchar_t instead of char and std::wstring instead of std::string. Your code will need to account for this. Here is a modified driver.cxx from the hello example that is meant to be used with the --char-type wchar_t. We will also add this example to the next version. hth, -boris #include #include #include #include "hello.hxx" using std::wcerr; using std::endl; using std::wstring; struct hello_parser: hello_type // name { virtual void greeting (const wstring& greeting) { greeting_ = greeting; } virtual void name (const wstring& name) { wcerr << greeting_ << ", " << name << "!" << endl; } private: wstring greeting_; }; int main (int argc, char* argv[]) { if (argc != 2) { wcerr << "usage: " << argv[0] << " hello.xml" << endl; return 1; } try { // Construct the parser. // xml_schema::string string_p; hello_parser hello_p; hello_p.greeting_parser (string_p); hello_p.name_parser (string_p); // Parse the XML instance document. The second argument to the // document's constructor is the document's root element name. // xml_schema::document doc_p (hello_p, L"hello"); // // std::ifstream ifs (argv[1]); doc_p.parse (ifs); } catch (const xml_schema::exception& e) { wcerr << e << endl; return 1; } catch (const std::ios_base::failure&) { wcerr << "io failure" << endl; return 1; } } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060731/3abcc5e9/attachment.pgp From boris at codesynthesis.com Mon Jul 31 16:19:00 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Building examples on Linux In-Reply-To: <44CE6016.6000001@saic-asd.com> References: <44CE16F6.1000104@saic-asd.com> <20060731153208.GA8747@karelia> <44CE2B8F.4020202@saic-asd.com> <20060731191827.GA9224@karelia> <44CE6016.6000001@saic-asd.com> Message-ID: <20060731201900.GA9374@karelia> Jason, I've CC'ed the xsd-users mailing list to my reply. This is the place to ask technical questions about XSD. Archives of this mailing list are available[1]. Jason Wang writes: > I need some help (or more detailed documents) on building the xsd for > different platform (starting from Linux). I am not quite familiar with > build (I have been using autoconf). So any help is appreciated. You don't really have to build XSD; precompiled binaries are available[2] for all supported platforms (including Windows, Linux and Solaris). If you really want build XSD from scratch yourself, there are build instructions for Windows[3] which you can also use for Unix-like platforms. > I also failed to compile the examples with in > xsd-2.2.0-i686-linux-gnu/examples/.../hello > > I know I need to set up a few libraries and env variables. I may need a > little more detailed document/forum archives, etc. The usage of precompiled binaries is described in the accompanying README files which are also available from the download page[2]. For Linux you will need to install (or build) Xerces-C++. There are RPMs for Redhat; just search for xerces-c and xerces-c-devel on http://rpm.pbone.net (you will need both xerces-c and xerces-c-devel packages). After that you should be all set to build the examples (as described in the README). Let me know if you have further questions or run into any problems. [1] http://codesynthesis.com/pipermail/xsd-users/ [2] http://codesynthesis.com/products/xsd/download.xhtml [3] http://codesynthesis.com/projects/xsd/extras/build-windows.xhtml hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060731/ae572a42/attachment.pgp From jwang at saic-asd.com Mon Jul 31 17:31:19 2006 From: jwang at saic-asd.com (Jason Wang) Date: Sun Oct 11 15:33:47 2009 Subject: [xsd-users] Re: Building examples on Linux In-Reply-To: <20060731201900.GA9374@karelia> References: <44CE16F6.1000104@saic-asd.com> <20060731153208.GA8747@karelia> <44CE2B8F.4020202@saic-asd.com> <20060731191827.GA9224@karelia> <44CE6016.6000001@saic-asd.com> <20060731201900.GA9374@karelia> Message-ID: <44CE76A7.3070909@saic-asd.com> Boris, I think I got it. Thanks so much! one more question. I have a set of xml schema files and some of them are common xml files used by a few others. Is there a issue with xsd? or will duplicated c++ classes being generated or name collisions? any document on that? Thanks, Jason Boris Kolpackov wrote: > Jason, > > I've CC'ed the xsd-users mailing list to my reply. This is the place > to ask technical questions about XSD. Archives of this mailing list > are available[1]. > > Jason Wang writes: > >> I need some help (or more detailed documents) on building the xsd for >> different platform (starting from Linux). I am not quite familiar with >> build (I have been using autoconf). So any help is appreciated. > > You don't really have to build XSD; precompiled binaries are available[2] > for all supported platforms (including Windows, Linux and Solaris). > If you really want build XSD from scratch yourself, there are build > instructions for Windows[3] which you can also use for Unix-like > platforms. > > >> I also failed to compile the examples with in >> xsd-2.2.0-i686-linux-gnu/examples/.../hello >> >> I know I need to set up a few libraries and env variables. I may need a >> little more detailed document/forum archives, etc. > > The usage of precompiled binaries is described in the accompanying > README files which are also available from the download page[2]. For > Linux you will need to install (or build) Xerces-C++. There are RPMs > for Redhat; just search for xerces-c and xerces-c-devel on > http://rpm.pbone.net (you will need both xerces-c and xerces-c-devel > packages). After that you should be all set to build the examples (as > described in the README). > > Let me know if you have further questions or run into any problems. > > [1] http://codesynthesis.com/pipermail/xsd-users/ > [2] http://codesynthesis.com/products/xsd/download.xhtml > [3] http://codesynthesis.com/projects/xsd/extras/build-windows.xhtml > > hth, > -boris