From jason.friess at lmco.com Mon Oct 3 16:46:46 2011 From: jason.friess at lmco.com (Friess, Jason) Date: Mon Oct 3 16:47:03 2011 Subject: [xsd-users] Serialization Methods For Polymorphic Types Message-ID: Hi, I have polymorphic types in several schemas that we are working with using CodeSynthesis XSD. I generated C++ code for these schemas using CodeSynthesis XSD (with the "--generate-serialization" option - which resulted in serialization methods for each of the global elements in my schemas). My problem is that I would like to be able to call 1 serialization method created for the parent type regardless of which of the child types I am handling. I don't want to have to first determine which child type I have and then have to call the corresponding serialization method. For instance I want to be able to do the following: xml_schema::namespace_infomap map; std::ostringstream oss; Parent_(oss, obj, map); // "Parent_" would be a serialization method generated for the element associated with the parent type, //"obj" is an object which has a type which is one of the child types of the parent type std::string xml(oss.str()); //"xml" is the resulting XML string Is this possible? If so - will it result in XML that is appropriate for the child type? Thanks, Jason From erik.sjolund at gmail.com Mon Oct 3 17:54:28 2011 From: erik.sjolund at gmail.com (=?ISO-8859-1?Q?Erik_Sj=F6lund?=) Date: Mon Oct 3 17:54:35 2011 Subject: [xsd-users] Serialization Methods For Polymorphic Types In-Reply-To: References: Message-ID: Yes, it should be possible. If we modify examples/cxx/tree/polymorphism somewhat, I think we see the result you are expecting. Replace "root-element-last" with "--root-element supermen --root-element person" in the file examples/cxx/tree/polymorphism/makefile and then incorporate this into examples/cxx/tree/polymorphism/driver.cxx ----------------------- auto_ptr sm(supermen_ (argv[1])); xml_schema::namespace_infomap map; map[""].schema = "supermen.xsd"; for (supermen::person_const_iterator i (sm->person ().begin ()); i != sm->person ().end (); ++i) { person_ (std::cout, *i, map); } ----------------------------------- If we now run "./driver supermen.xml" we get this output: John Doe James "007" Bond Bruce Wayne Only one thing is a bit suprising. The last person is a References: Message-ID: Hi Jason, Friess, Jason writes: > xml_schema::namespace_infomap map; > std::ostringstream oss; > Parent_(oss, obj, map); // "Parent_" would be a serialization method generated for the element associated with the parent type, > //"obj" is an object which has a type which is one of the child types of the parent type > std::string xml(oss.str()); //"xml" is the resulting XML string > > Is this possible? Yes, as Erik mentioned, this works out of the box and you don't need to do anything special. > If so - will it result in XML that is appropriate for the child type? Yes, if there is a substitution group element available for this child type, then that element will be used. Otherwise, the parent element will be used and xsi:type attribute will be added. Boris From jason.friess at lmco.com Wed Oct 5 09:35:06 2011 From: jason.friess at lmco.com (Friess, Jason) Date: Wed Oct 5 09:35:21 2011 Subject: EXTERNAL: Re: [xsd-users] Serialization Methods For Polymorphic Types In-Reply-To: References: Message-ID: Boris and Erik, Thanks for your assistance with this! I have been able to confirm that I see the behavior you both described. What about going the other way - from XML to objects? Can we call the parent type deserialization method with some XML (that could represent a child type) and then get a child type object instance back?...or would we always get an instance of the parent type? Thanks! Jason -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, October 04, 2011 9:47 AM To: Friess, Jason Cc: xsd-users@codesynthesis.com Subject: EXTERNAL: Re: [xsd-users] Serialization Methods For Polymorphic Types Hi Jason, Friess, Jason writes: > xml_schema::namespace_infomap map; > std::ostringstream oss; > Parent_(oss, obj, map); // "Parent_" would be a serialization method generated for the element associated with the parent type, > //"obj" is an object which has a type which is one of the child types of the parent type > std::string xml(oss.str()); //"xml" is the resulting XML string > > Is this possible? Yes, as Erik mentioned, this works out of the box and you don't need to do anything special. > If so - will it result in XML that is appropriate for the child type? Yes, if there is a substitution group element available for this child type, then that element will be used. Otherwise, the parent element will be used and xsi:type attribute will be added. Boris From boris at codesynthesis.com Wed Oct 5 09:42:36 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Oct 5 09:43:32 2011 Subject: EXTERNAL: Re: [xsd-users] Serialization Methods For Polymorphic Types In-Reply-To: References: Message-ID: Hi Jason, Friess, Jason writes: > What about going the other way - from XML to objects? Can we call the > parent type deserialization method with some XML (that could represent > a child type) and then get a child type object instance back? Yes, the other way works as well. Boris From jason.friess at lmco.com Wed Oct 5 17:16:50 2011 From: jason.friess at lmco.com (Friess, Jason) Date: Wed Oct 5 17:18:57 2011 Subject: EXTERNAL: Re: [xsd-users] Serialization Methods For Polymorphic Types In-Reply-To: References: Message-ID: Thanks Boris! I have been able to confirm this works as well. Jason -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, October 05, 2011 9:43 AM To: Friess, Jason Cc: xsd-users@codesynthesis.com Subject: Re: EXTERNAL: Re: [xsd-users] Serialization Methods For Polymorphic Types Hi Jason, Friess, Jason writes: > What about going the other way - from XML to objects? Can we call the > parent type deserialization method with some XML (that could represent > a child type) and then get a child type object instance back? Yes, the other way works as well. Boris From mendell at ca.ibm.com Thu Oct 6 16:43:16 2011 From: mendell at ca.ibm.com (Mark Mendell) Date: Thu Oct 6 16:43:54 2011 Subject: [xsd-users] How do you enter mixed text when creating an element? Message-ID: If I have this xsd fragment: .... I want to allow either: 5 or: ... I know how to handle creating the list entry, and (from a different problem) how to read the text '5' using the DOMNode, but I can't figure out how to create a 'literal' with just the text 5. I would never have a and text. Any ideas on how to create the node? I want to do: auto_ptr l(new literalType); l->setText("5"); use l Is there a way to force a DOMText node to be created, so that I can replace the text? Mark Mendell InfoSphere Streams IBM Toronto Laboratory, 8200 Warden Ave, Markham, Ontario, Canada, L6G 1C7 Tel: 905-413-3485 Tie: 313-3485 Internet: mendell@ca.ibm.com From boris at codesynthesis.com Fri Oct 7 09:57:12 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 7 09:57:55 2011 Subject: [xsd-users] How do you enter mixed text when creating an element? In-Reply-To: References: Message-ID: Hi Mark, Mark Mendell writes: > If I have this xsd fragment: > > > > > > .... > > > > > > I know how to handle creating the list entry, and (from a different > problem) how to read the text '5' using the DOMNode, but I can't figure > out how to create a 'literal' with just the text 5. Using DOM association (which is what, I assume, you are using to read the text) works well for reading but not for writing. If you need to modify/create elements mixed content, then the best option is to customize the type(s) with mixed content. The 'custom/mixed' example in the examples/cxx/tree/ directory in the XSD distribution shows how to do exactly that. In particular, there is this sentence in the accompanying README file: "The use of DOM for mixed content storage is one of the options. You may find other data structures (e.g., a string) more suitable depending on your situation." In your case, string will be exactly what you would want to use. Also in the parsing constructor you would want to check if there are any child elements in the content. If so, then you would want to delegate parsing to the base (generated) implementation so that it can parse the list element sequence. However, if there are not nested elements, then you would assume this is a string literal and extract the text into the string member. Similarly, in the serialization operator, you would first check if the string member is not empty. If so, then you create a DOMText child node. Otherwise, you again delegate to the base implementation so that it can write out the list element sequence. Boris From jc.fernandez.navarro at gmail.com Thu Oct 13 07:27:08 2011 From: jc.fernandez.navarro at gmail.com (Jose) Date: Thu Oct 13 07:27:16 2011 Subject: [xsd-users] [XSD] Mac binaries compatibility problem Message-ID: Hi everyone, I have an app written in C++ using Xsd. It runs perfectly in Ubuntu and Fedora but I'm now trying to compile and run it under Mac. I downloaded the Xsd Mac binaries from the website. My app compiles okay but it fails while building. The problem is located in : /xsd-3.3.0-i686-macosx/libxsd/xsd/cxx/tree/xdr-stream-extraction.hxx That classes uses some functions located in /usr/include/rpc/xdr.h They are called in the way : xdr_uint8 ....xdr_uint16..... and so on But those are the names used in Linux systems, in Mac my xdr.h uses these names : xdr_u_int8....and so on. Solutions : 1) I can either modify xdr.h or xdr-stream-extraction.hxx to add the definitions like #define xdr_uint32_t xdr_u_int32_t 2) I can try to compile XSD from the source, although I get this error when I do it : ../build/bootstrap.make:16: build-0.3/bootstrap.make: No such file or directory Probably I need to install something like bjam to get to compile. Is there any solution for this? Does anyone know if compiling the source fixes issue? If so, have anyone stumbled upon the error I get when I try to compile it? Thank you so much Regards Jose From boris at codesynthesis.com Fri Oct 14 06:59:44 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 14 06:59:52 2011 Subject: [xsd-users] [XSD] Mac binaries compatibility problem In-Reply-To: References: Message-ID: Hi Jose, Jose writes: > That classes uses some functions located in /usr/include/rpc/xdr.h > > They are called in the way : xdr_uint8 ....xdr_uint16..... and so on > > But those are the names used in Linux systems, in Mac my xdr.h uses these > names : > > xdr_u_int8....and so on. Seems BSD (on which MacOS X is based) had to be different here as well. Anyways, I have committed a fix that works around these differences. You can also get it for XSD 3.3.0: http://www.codesynthesis.com/~boris/tmp/xsd/xsd-3.3.0-macosx-xdr.tar.bz Simply override the files in the binary XSD distribution with the ones in the archive and everything should work fine. Boris From boris at codesynthesis.com Fri Oct 14 09:04:08 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 14 09:04:20 2011 Subject: [xsd-users] Re: Question about XML versionning In-Reply-To: References: Message-ID: Hi Bruno, [CC'ing the xsd-users mailing list to my reply.] Ledoux, Bruno writes: > Many of the "external" XML vocabularies (GML, HMA) we are handling using > libxsd are versioned. Each time a new version is issued a new set of XSD > files is produced and need to be integrated in our parsing mechanism. > These new XSD files are not backward compatible. > > We would like to set up a factory mechanism allowing us to build the > appropriate parser based on the version number of the XML file that > needs to be parsed. This would allow us to build a unique parsing > program handling the different versions. > > What would be the best approach to address this issue with respect > to performance and memory usage ? While having a separate program (e.g., an executable) that handles a particular version of the XML vocabulary will work, it is probably not the most efficient approach, unless you know which version each XML file corresponds to without looking inside the file. If you have to look inside the XML file, which would be needed, for example, if the version is specified as an attribute in the root element, then the best approach in this setup would be to have a special "starter" program which parses just enough of the XML file to determine its version and then starts the corresponding "parsing" program. The easiest way to parse just the prefix of an XML file would be to use a SAX (SAX2XMLReader) parser and stop (e.g., by throwing an exception from the handler or simply by doing exec()) once you've got the version. A more efficient way to handle this would be to handle all the versions in a single executable. This way, you can first parse the XML document to DOM, determine its version, and then pass this same DOM tree to the corresponding XSD-generated parsing function to be parsed to the object model. In fact, this approach is very similar to how one can handle XML documents with varying root elements. The 'multiroot' example in the examples/cxx/tree/ directory in the XSD distribution shows how to do this. Of course, if the files that you are parsing a quite large, then the overhead of parsing a prefix in the starter program will be fairly minor and the multi-program approach may prove more suitable since you can encapsulate handling of each version into a standalone executable. This will especially be true if different schema versions still use the same XML namespace. In this situation, in order to be able to handle multiple versions in the same program, you would need to map the XML namespaces of different versions to different C++ namespaces (see --namespace-map and --namespace-regex XSD options). Boris From boris at codesynthesis.com Fri Oct 14 09:48:49 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 14 09:48:56 2011 Subject: [xsd-users] [XSD] Mac binaries compatibility problem In-Reply-To: References: Message-ID: Hi Jose, In the future please keep your replies CC'ed to the xsd-users mailing list as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml Jose writes: > But the problem is that the xdr.h file in MAC does not have int8 defined. Yes, you are correct. I tried the 'binary/xdr' example and it worked. But it doesn't use any 8-bit integers so it didn't pick this up. > I can get a work around like this : "not really the best solution since > technically int8 is not equal to int" No, this is not a good workaround since the resulting binary representation will be incompatible with other platforms (it will use 4 bytes while other platforms will expect 1 byte). A better workaround would be to use the xdr_char() and xdr_u_char() functions. I have re-implemented the fix and updated the archive. Can you try it and see if it works for you? http://www.codesynthesis.com/~boris/tmp/xsd/xsd-3.3.0-macosx-xdr.tar.bz > So now it builds okay although I have gotten dependency errors in the > linking with xercesc, I actually have the same problem when I compile it in > windows and I can not really find a solution because the xercesc libraries > that I am using have been compiled for either windows and mac with the flags > indicated in the website. Do you know if something special has to be done to > compile and/or link xercesc libraries in Windows and Mac, specially while > using it with XSD?? No, things normally work out of the box. It is hard for me to say what's going on without seeing the actual diagnostics (for both Mac OS X and Windows). Boris From jc.fernandez.navarro at gmail.com Fri Oct 14 10:31:50 2011 From: jc.fernandez.navarro at gmail.com (Jose) Date: Fri Oct 14 10:31:58 2011 Subject: [xsd-users] [XSD] Mac binaries compatibility problem In-Reply-To: References: Message-ID: Hi Boris, Ohh Yes, I'm sorry for not replying to everyone. I will never get used to Thunderbird. Your solution worked out but I'm still having the linking problems which are obviously not related to your solution. the output is : Undefined symbols for architecture x86_64: "_curl_global_cleanup", referenced from: xercesc_3_1::CurlNetAccessor::cleanupCurl() in libxerces-c.a(CurlNetAccessor.o) xercesc_3_1::CurlNetAccessor::~CurlNetAccessor()in libxerces-c.a(CurlNetAccessor.o) xercesc_3_1::CurlNetAccessor::~CurlNetAccessor()in libxerces-c.a(CurlNetAccessor.o) "_curl_global_init", referenced from: xercesc_3_1::CurlNetAccessor::initCurl() in libxerces-c.a(CurlNetAccessor.o) xercesc_3_1::CurlNetAccessor::CurlNetAccessor()in libxerces-c.a(CurlNetAccessor.o) "_curl_multi_init", referenced from: xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*)in libxerces-c.a(CurlURLInputStream.o) "_curl_easy_init", referenced from: xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*)in libxerces-c.a(CurlURLInputStream.o) "_curl_easy_setopt", referenced from: xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*)in libxerces-c.a(CurlURLInputStream.o) "_curl_slist_append", referenced from: xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*)in libxerces-c.a(CurlURLInputStream.o) "_curl_slist_free_all", referenced from: xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*)in libxerces-c.a(CurlURLInputStream.o) "_curl_multi_add_handle", referenced from: xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*)in libxerces-c.a(CurlURLInputStream.o) "_curl_easy_getinfo", referenced from: xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL const&, xercesc_3_1::XMLNetHTTPInfo const*)in libxerces-c.a(CurlURLInputStream.o) "_curl_multi_perform", referenced from: xercesc_3_1::CurlURLInputStream::readMore(int*) in libxerces-c.a(CurlURLInputStream.o) "_curl_multi_info_read", referenced from: xercesc_3_1::CurlURLInputStream::readMore(int*) in libxerces-c.a(CurlURLInputStream.o) "_curl_multi_fdset", referenced from: xercesc_3_1::CurlURLInputStream::readMore(int*) in libxerces-c.a(CurlURLInputStream.o) "_curl_multi_remove_handle", referenced from: xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in libxerces-c.a(CurlURLInputStream.o) xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in libxerces-c.a(CurlURLInputStream.o) "_curl_easy_cleanup", referenced from: xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in libxerces-c.a(CurlURLInputStream.o) xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in libxerces-c.a(CurlURLInputStream.o) "_curl_multi_cleanup", referenced from: xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in libxerces-c.a(CurlURLInputStream.o) xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in libxerces-c.a(CurlURLInputStream.o) ld: symbol(s) not found for architecture x86_64 I have tried many compilations flabs to compile xercesc but I always get his error. Whereas in windows I get hundreds of : "undefined reference to ..'_imp__ZN11xercesc_3_11XXXXXXX ...." where XXX are names of functions. I'm sorry I could not copy and paste the output because it has been run on a virtual machine. I have tried the same in windows, compile xercesc with different compilation flags (always under mingw msys) . I wish I did not have to make this app compatible to windows and mac because it works well in Linux but well... It should be possible since I don't have many dependencies. Thank you so much again. Regards Jose 2011/10/14 Boris Kolpackov > Hi Jose, > > In the future please keep your replies CC'ed to the xsd-users mailing > list as discussed in the posting guidelines: > > http://www.codesynthesis.com/support/posting-guidelines.xhtml > > > Jose writes: > > > But the problem is that the xdr.h file in MAC does not have int8 defined. > > Yes, you are correct. I tried the 'binary/xdr' example and it worked. But > it doesn't use any 8-bit integers so it didn't pick this up. > > > > I can get a work around like this : "not really the best solution since > > technically int8 is not equal to int" > > No, this is not a good workaround since the resulting binary representation > will be incompatible with other platforms (it will use 4 bytes while other > platforms will expect 1 byte). A better workaround would be to use the > xdr_char() and xdr_u_char() functions. I have re-implemented the fix and > updated the archive. Can you try it and see if it works for you? > > http://www.codesynthesis.com/~boris/tmp/xsd/xsd-3.3.0-macosx-xdr.tar.bz > > > > So now it builds okay although I have gotten dependency errors in the > > linking with xercesc, I actually have the same problem when I compile it > in > > windows and I can not really find a solution because the xercesc > libraries > > that I am using have been compiled for either windows and mac with the > flags > > indicated in the website. Do you know if something special has to be done > to > > compile and/or link xercesc libraries in Windows and Mac, specially while > > using it with XSD?? > > No, things normally work out of the box. It is hard for me to say what's > going on without seeing the actual diagnostics (for both Mac OS X and > Windows). > > Boris > From jc.fernandez.navarro at gmail.com Fri Oct 14 10:45:05 2011 From: jc.fernandez.navarro at gmail.com (Jose) Date: Fri Oct 14 10:45:14 2011 Subject: [xsd-users] [XSD] Mac binaries compatibility problem In-Reply-To: References: Message-ID: Well, I have gotten it to work under Mac. The compilation flags that I used are : ./configure --disable-dependency-tracking --disable-netaccessor-curl --enable-transcoder-iconv --enable-msgloader-inmemory CFLAGS="-Os -arch i386 -arch x86_64" CXXFLAGS="-Os -arch i386 -arch x86_64" Im still getting the undefined references to...all the xercesc functions when I link in Windows so I am still trying to find the right flags combination. I will try now to compile it with cgwin instead of mingw. Jose 2011/10/14 Jose > Hi Boris, > > Ohh Yes, I'm sorry for not replying to everyone. I will never get used to > Thunderbird. > > Your solution worked out but I'm still having the linking problems which > are obviously not related to your solution. > > the output is : > > Undefined symbols for architecture x86_64: > "_curl_global_cleanup", referenced from: > xercesc_3_1::CurlNetAccessor::cleanupCurl() in > libxerces-c.a(CurlNetAccessor.o) > xercesc_3_1::CurlNetAccessor::~CurlNetAccessor()in > libxerces-c.a(CurlNetAccessor.o) > xercesc_3_1::CurlNetAccessor::~CurlNetAccessor()in > libxerces-c.a(CurlNetAccessor.o) > "_curl_global_init", referenced from: > xercesc_3_1::CurlNetAccessor::initCurl() in > libxerces-c.a(CurlNetAccessor.o) > xercesc_3_1::CurlNetAccessor::CurlNetAccessor()in > libxerces-c.a(CurlNetAccessor.o) > "_curl_multi_init", referenced from: > > xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL > const&, xercesc_3_1::XMLNetHTTPInfo const*)in > libxerces-c.a(CurlURLInputStream.o) > "_curl_easy_init", referenced from: > > xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL > const&, xercesc_3_1::XMLNetHTTPInfo const*)in > libxerces-c.a(CurlURLInputStream.o) > "_curl_easy_setopt", referenced from: > > xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL > const&, xercesc_3_1::XMLNetHTTPInfo const*)in > libxerces-c.a(CurlURLInputStream.o) > "_curl_slist_append", referenced from: > > xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL > const&, xercesc_3_1::XMLNetHTTPInfo const*)in > libxerces-c.a(CurlURLInputStream.o) > "_curl_slist_free_all", referenced from: > > xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL > const&, xercesc_3_1::XMLNetHTTPInfo const*)in > libxerces-c.a(CurlURLInputStream.o) > "_curl_multi_add_handle", referenced from: > > xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL > const&, xercesc_3_1::XMLNetHTTPInfo const*)in > libxerces-c.a(CurlURLInputStream.o) > "_curl_easy_getinfo", referenced from: > > xercesc_3_1::CurlURLInputStream::CurlURLInputStream(xercesc_3_1::XMLURL > const&, xercesc_3_1::XMLNetHTTPInfo const*)in > libxerces-c.a(CurlURLInputStream.o) > "_curl_multi_perform", referenced from: > xercesc_3_1::CurlURLInputStream::readMore(int*) in > libxerces-c.a(CurlURLInputStream.o) > "_curl_multi_info_read", referenced from: > xercesc_3_1::CurlURLInputStream::readMore(int*) in > libxerces-c.a(CurlURLInputStream.o) > "_curl_multi_fdset", referenced from: > xercesc_3_1::CurlURLInputStream::readMore(int*) in > libxerces-c.a(CurlURLInputStream.o) > "_curl_multi_remove_handle", referenced from: > xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in > libxerces-c.a(CurlURLInputStream.o) > xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in > libxerces-c.a(CurlURLInputStream.o) > "_curl_easy_cleanup", referenced from: > xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in > libxerces-c.a(CurlURLInputStream.o) > xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in > libxerces-c.a(CurlURLInputStream.o) > "_curl_multi_cleanup", referenced from: > xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in > libxerces-c.a(CurlURLInputStream.o) > xercesc_3_1::CurlURLInputStream::~CurlURLInputStream()in > libxerces-c.a(CurlURLInputStream.o) > ld: symbol(s) not found for architecture x86_64 > > I have tried many compilations flabs to compile xercesc but I always get > his error. > > Whereas in windows I get hundreds of : "undefined reference to > ..'_imp__ZN11xercesc_3_11XXXXXXX ...." where XXX are names of functions. > I'm sorry I could not copy and paste the output because it has been run on a > virtual machine. I have tried the same in windows, compile xercesc with > different compilation flags (always under mingw msys) . > > I wish I did not have to make this app compatible to windows and mac > because it works well in Linux but well... It should be possible since I > don't have many dependencies. > > Thank you so much again. > > Regards > > Jose > > > > 2011/10/14 Boris Kolpackov > >> Hi Jose, >> >> In the future please keep your replies CC'ed to the xsd-users mailing >> list as discussed in the posting guidelines: >> >> http://www.codesynthesis.com/support/posting-guidelines.xhtml >> >> >> Jose writes: >> >> > But the problem is that the xdr.h file in MAC does not have int8 >> defined. >> >> Yes, you are correct. I tried the 'binary/xdr' example and it worked. But >> it doesn't use any 8-bit integers so it didn't pick this up. >> >> >> > I can get a work around like this : "not really the best solution since >> > technically int8 is not equal to int" >> >> No, this is not a good workaround since the resulting binary >> representation >> will be incompatible with other platforms (it will use 4 bytes while other >> platforms will expect 1 byte). A better workaround would be to use the >> xdr_char() and xdr_u_char() functions. I have re-implemented the fix and >> updated the archive. Can you try it and see if it works for you? >> >> http://www.codesynthesis.com/~boris/tmp/xsd/xsd-3.3.0-macosx-xdr.tar.bz >> >> >> > So now it builds okay although I have gotten dependency errors in the >> > linking with xercesc, I actually have the same problem when I compile it >> in >> > windows and I can not really find a solution because the xercesc >> libraries >> > that I am using have been compiled for either windows and mac with the >> flags >> > indicated in the website. Do you know if something special has to be >> done to >> > compile and/or link xercesc libraries in Windows and Mac, specially >> while >> > using it with XSD?? >> >> No, things normally work out of the box. It is hard for me to say what's >> going on without seeing the actual diagnostics (for both Mac OS X and >> Windows). >> >> Boris >> > > From boris at codesynthesis.com Mon Oct 17 02:53:15 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 17 02:53:14 2011 Subject: [xsd-users] [XSD] Mac binaries compatibility problem In-Reply-To: References: Message-ID: Hi Jose, Jose writes: > Undefined symbols for architecture x86_64: > "_curl_global_cleanup", referenced from: > xercesc_3_1::CurlNetAccessor::cleanupCurl() in > libxerces-c.a(CurlNetAccessor.o) You need to add -lcurl when linking your application because you are using static libxerces-c.a library which depends on the libcurl for network support. Alternatively, you can configure Xerces-C++ not to use curl, as you did in your followup email. > Whereas in windows I get hundreds of : "undefined reference to > ..'_imp__ZN11xercesc_3_11XXXXXXX ...." where XXX are names of functions. > I'm sorry I could not copy and paste the output because it has been run on a > virtual machine. I have tried the same in windows, compile xercesc with > different compilation flags (always under mingw msys) . Shared library support in MinGW is quite brittle so I suggest that you try to build Xerces-C++ as a static library (--disable-shared configure option). Also note that these question are not really about XSD. If you have any followup questions about any of these problems, please send them to the Xerces-C++ user mailing list (you can find the address on the Xerces-C++ project page[1]) instead of to xsd-users. [1] http://xerces.apache.org/xerces-c/ Boris From erik.sjolund at gmail.com Tue Oct 18 06:25:41 2011 From: erik.sjolund at gmail.com (=?ISO-8859-1?Q?Erik_Sj=F6lund?=) Date: Tue Oct 18 06:25:49 2011 Subject: [xsd-users] any open source projects that use Codesynthesis XSD? Message-ID: Hi, I added this page to the wiki: http://wiki.codesynthesis.com/Open_source_projects_that_use_XSD As one example I listed the open source software Percolator. It would be interesting to hear of other open source projects that use Codesynthesis XSD. Please add your examples to the wiki. cheers, Erik Sj?lund From mjklaim at gmail.com Wed Oct 19 11:47:04 2011 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Wed Oct 19 11:47:14 2011 Subject: [xsd-users] any open source projects that use Codesynthesis XSD? In-Reply-To: References: Message-ID: On Tue, Oct 18, 2011 at 12:25, Erik Sj?lund wrote: > > It would be interesting to hear of other open source projects that use > Codesynthesis XSD. Please add your examples to the wiki. > > Ok, I'm adding Art Of Sequence to the wiki :) http://dev.artofsequence.org Jo?l Lamotte From Vaughan at Roberts.name Thu Oct 20 21:31:08 2011 From: Vaughan at Roberts.name (Vaughan Roberts) Date: Thu Oct 20 21:31:21 2011 Subject: [xsd-users] parser.txx undeclared identifiers in templates when compiling with LLVM 3.0 in Xcode Message-ID: <020a01cc8f91$1bc3d2f0$534b78d0$@Roberts.name> I have had an issue when trying to compile a program which uses xsd-parser with Xcode4.3 using the LLVM 3.0 compiler. In the parser.txx file I get about 17 errors relating to undeclared identifiers. These appear to be identifiers that are defined in templates in the same file and these errors are probably occurring due to the two-phase name lookup issue discussed in: blog.llvm.org/2009/12/dreaded-two-phase-name-lookup.html The resolution is quite simple llvm requires that each name be preceded with 'this->'. E.g. _attribute_impl needs to be changed to this->_attribute_impl Apparently llvm is a bit more fussy than gcc on this issue, but once that is done the compiler is happy. Best regards, Vaughan Mob: 0412 122 362 From boris at codesynthesis.com Fri Oct 21 05:27:25 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 21 05:26:58 2011 Subject: [xsd-users] parser.txx undeclared identifiers in templates when compiling with LLVM 3.0 in Xcode In-Reply-To: <020a01cc8f91$1bc3d2f0$534b78d0$@Roberts.name> References: <020a01cc8f91$1bc3d2f0$534b78d0$@Roberts.name> Message-ID: Hi Vaughan, Vaughan Roberts writes: > The resolution is quite simple llvm requires that each name be preceded with > 'this->'. > > E.g. _attribute_impl needs to be changed to this->_attribute_impl > > Apparently llvm is a bit more fussy than gcc on this issue, but once that is > done the compiler is happy. Yes, clang follows the standard often to the point of being annoying. For the next release of XSD we are planning to make sure everything compiles with clang without any problems. Thanks for reporting this! Boris From jc.fernandez.navarro at gmail.com Mon Oct 24 12:05:22 2011 From: jc.fernandez.navarro at gmail.com (Jose) Date: Mon Oct 24 12:05:30 2011 Subject: [xsd-users] XSD Serialization problem - xml_schema:ostream not recognized in MinGW env Message-ID: Hi all, I'm trying to cross compile an app which uses XSD and I have stumbled upon an error that I don't know how to fix. I use this structure to serialize the objects onto : std::auto_ptr< xml_schema::ostream > oxdrp; It does compile perfectly under linux but it complains when I try to cross-compile it with MinGW in Fedora. "..error: 'ostream' is not a member of 'xml_schema' It does not recognize ostream in the schema even though I'm passing the correct parameters to cxx-tree : set( xdr_flags --generate-insertion XDR --generate-extraction XDR ) Any type of help would be appreciated. Thanks Regards Jose From boris at codesynthesis.com Mon Oct 24 16:02:50 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 24 16:02:25 2011 Subject: [xsd-users] XSD Serialization problem - xml_schema:ostream not recognized in MinGW env In-Reply-To: References: Message-ID: Hi Jose, Jose writes: > std::auto_ptr< xml_schema::ostream > oxdrp; > > It does compile perfectly under linux but it complains when I try to > cross-compile it with MinGW in Fedora. My first guess would be that the XDR API ( header) is not available on MinGW. For Windows it doesn't come standard and instead you need a third-party library that provides XDR support. If you want a more portable binary representation, then you may want to consider CDR (also supported out of the box by XSD). The drawback is that you will need build/install the ACE library. Boris From jc.fernandez.navarro at gmail.com Tue Oct 25 04:16:29 2011 From: jc.fernandez.navarro at gmail.com (Jose) Date: Tue Oct 25 04:16:37 2011 Subject: [xsd-users] XSD Serialization problem - xml_schema:ostream not recognized in MinGW env In-Reply-To: References: Message-ID: Hi Boris, Yep you are right, you a need third party XDR library. It is called mingw32-portablexdr. I was including the header but the problem was that when you cross compile and/or compile under windows and you want to make use of XDR you have to link this library : libportablexdr.dll.a "in my case its this one cos I use mingw" So now when I cross compile it recognizes the schema the problem is that the the xdr api that comes with MingGW is not compatible with the XDR api used by XDS. Many names of variables are different or even not declared as well as some headers of functions. I don't know if this is a MinGW issue or XSD issue. Is XSD using the the unix name sets of the XDR api in its Windows binary libraries in the file xdr-stream-extraction and so on. I can edit my xdr.h in mingw to be compatible to xsd but its not a nice solution. CDR would be more portable disregarding the ace library so I will see now how long it will take me to change the schema in my parsing code. Thanks Jose 2011/10/24 Boris Kolpackov > Hi Jose, > > Jose writes: > > > std::auto_ptr< xml_schema::ostream > oxdrp; > > > > It does compile perfectly under linux but it complains when I try to > > cross-compile it with MinGW in Fedora. > > My first guess would be that the XDR API ( header) is not > available on MinGW. For Windows it doesn't come standard and instead > you need a third-party library that provides XDR support. > > If you want a more portable binary representation, then you may want > to consider CDR (also supported out of the box by XSD). The drawback > is that you will need build/install the ACE library. > > Boris > From boris at codesynthesis.com Tue Oct 25 09:01:48 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 25 09:01:25 2011 Subject: [xsd-users] XSD Serialization problem - xml_schema:ostream not recognized in MinGW env In-Reply-To: References:

Message-ID: Hi Jose, Jose writes: > So now when I cross compile it recognizes the schema the problem is that the > the xdr api that comes with MingGW is not compatible with the XDR api used > by XDS. Many names of variables are different or even not declared as well > as some headers of functions. Unfortunately, this appears to be quite common. > I don't know if this is a MinGW issue or XSD issue. Is XSD using the the > unix name sets of the XDR api in its Windows binary libraries in the file > xdr-stream-extraction and so on. I would say it is the XDR library issue. In XSD we use the XDR API that is defined as part of Sun RPC. > I can edit my xdr.h in mingw to be compatible to xsd but its not a nice > solution. Yes, I agree. One way you can try and solve this is by coming up with a set of typedefs/functions/macros that make this xdr.h look like Sun XDR API. If you can do that, then you can use it in your application by first including , then adding your "compatibility" layer and then including the generated header. This way the generated code and the XSD runtime will "see" the compatible API. If you manage to come up with something like this (it can probably be packaged in a header), I would appreciate it if you posted it to the mailing list in case others have a similar issue. Boris