From smartpratik at gmail.com Mon Jul 2 07:33:27 2007 From: smartpratik at gmail.com (pratik verma) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Fwd: problem while compiling the class generated by codesynthesis XSD2.2.3 In-Reply-To: References: <20070625151209.GD25720@karelia> <20070626112927.GC29591@karelia> <20070626154126.GG29591@karelia> Message-ID: hello, First of all thanks alot for your precious suggestion. I have done some manuplation and now they are not giving any error. I have created a dci.cxx(just to extract to top most element didl and item) to compile them and to extract elements just analogus to driver.cxx in Hello.xsd example. But the fact is that i m giving schema dmp2did-2006-02l.xsd and 2vedioclips.xml file to extract the element but I am not able to ectract it. So please suggest me how should I create driver.cxx for my project which could extract elements from 2videoclips.xml. I have attached both the dci.cxx and 2 vedioclips .xml in it. Eagerly waiting for your reply Yours Truly Pratik Verma On 6/27/07, pratik verma < smartpratik@gmail.com> wrote: > > > > ---------- Forwarded message ---------- > From: Boris Kolpackov < boris@codesynthesis.com> > Date: Jun 26, 2007 9:11 PM > Subject: Re: problem while compiling the class generated by codesynthesis > XSD2.2.3 > To: pratik verma < smartpratik@gmail.com> > Cc: xsd-users@codesynthesis.com > > Hi Pratik, > > [I've CC'ed xsd-users to my reply in case someone else is/will be > wrestling > with these schemas ( http://www.dmpf.org/schemas/index.html). > ] > > I've tried to compile these schemas with just-released 3.0.0.b2. > Compiling the code generated with this version also results in an > error. The problem is in the cyclic importing of the schemas. For > example, dmp2rdm-2006-02.xsd imports dmp2ipmpinfo.xsd and > dmp2ipmpinfo.xsd imports dmp2rdm-2006-02.xsd. XSD can generate > compilable code for such a situation but only if there is no > inheritance between types in the separate files. Unfortunately, > there is such inheritance in your case. The only way to work > around this problem is to break the cyclic dependency by factoring > out a subset of one of the files into a separate schema and including > that "base" into the other file. In other word, right now you have: > > "a.xsd" <==> "b.xsd" > > After the refactoring you will have: > > "a-base.xsd" > ^ ^ > | | > | | > "a.xsd" --> " b.xsd " > > The idea is to move to "a-base.xsd" declarations which a necessary > for "b.xsd". > > > In the future we are planning to add an option to XSD to "merge" > such cyclic schemas into a single "blob" and generate the code > into a single file. > > hth, > -boris > -------------- next part -------------- A non-text attachment was scrubbed... Name: dci.cxx Type: text/x-c++src Size: 1315 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070702/2c1f38ad/dci.cxx -------------- next part -------------- A non-text attachment was scrubbed... Name: 2videoclips.xml Type: text/xml Size: 27669 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070702/2c1f38ad/2videoclips.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: dmp2didl-2006-02.xsd Type: application/octet-stream Size: 4460 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070702/2c1f38ad/dmp2didl-2006-02.obj From boris at codesynthesis.com Mon Jul 2 10:38:04 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Re: Fwd: problem while compiling the class generated by codesynthesis XSD2.2.3 In-Reply-To: References: <20070625151209.GD25720@karelia> <20070626112927.GC29591@karelia> <20070626154126.GG29591@karelia> Message-ID: <20070702143804.GE14994@karelia> Hi Pratik, pratik verma writes: > First of all thanks alot for your precious suggestion. I have done > some manuplation and now they are not giving any error. Great! > I have created a dci.cxx(just to extract to top most element didl > and item) to compile them and to extract elements just analogus to > driver.cxx in Hello.xsd example. But the fact is that i m giving > schema dmp2did-2006-02l.xsd and 2vedioclips.xml file to extract > the element but I am not able to ectract it. > > struct DIDL_parser: chillout::dmp2didl::DIDLType string, // DIDLInfo > string> // Item > [...] > > // Construct the parser. > // > xml_schema::string string_p; > DIDL_parser DIDL_p; > > DIDL_p.DIDLInfo_parser (string_p); > DIDL_p.Item_parser (string_p); The above code snippet shows that you are trying to parse the DIDLInfo and Item elements using the xml_schema::string parser. This won't work: both elements are of complex types, with nested content, etc. You will need to create parsers for each of them in order to extract the data. I suggest that you upgrade to 3.0.0.b2. In this version we have implemented a new design and a number of improvements for the C++/Parser mapping. In particular, you may be interested in: 1. The new Getting Started Guide, which is located in the documentation/cxx/parser/guide/ directory of the XSD distributions. You may want to read though it to get a better understanding of the C++/Parser mapping. 2. The automatic parser implementation and test driver generation. With this feature you can generate a sample implementation that prints the content of your XML file. You can then use it as a basis and a guide for your own implementation. You can get 3.0.0.b2 from the XSD download page: http://www.codesynthesis.com/products/xsd/download.xhtml hth, -boris From Ryan.Prather at afspc.af.mil Thu Jul 5 10:03:32 2007 From: Ryan.Prather at afspc.af.mil (Prather, Ryan C SSgt DMSG/WMTS) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] 3.0 release Message-ID: Does 3.0 have a release date? I need an XSD 3.0 version for Sun and soon. SSgt Ryan Prather DMSG/WMTS, Peterson AFB, CO Comm: 719-556- DSN: 834-2474 E-mail: Ryan.Prather@peterson.af.mil From boris at codesynthesis.com Thu Jul 5 10:28:14 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] 3.0 release In-Reply-To: References: Message-ID: <20070705142814.GE3830@karelia> Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Does 3.0 have a release date? I need an XSD 3.0 version for Sun and > soon. The 3.0.0 version will be released in 2-3 weeks. It will be very close to 3.0.0.b2. I can build you a 3.0.0.b2 binary for Solaris in the meantime. Do you need SPARC or x86? hth, -boris From Ryan.Prather at afspc.af.mil Thu Jul 5 10:47:53 2007 From: Ryan.Prather at afspc.af.mil (Prather, Ryan C SSgt DMSG/WMTS) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] 3.0 release In-Reply-To: <20070705142814.GE3830@karelia> References: <20070705142814.GE3830@karelia> Message-ID: Boris, That is great. We have a mid-Aug delivery date, but if you would build the Solaris binaries that would be great. The most time I can get the better. Right now I need SPARC. Thanks Again. Ryan -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, July 05, 2007 8:28 AM To: Prather, Ryan C SSgt DMSG/WMTS Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] 3.0 release Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Does 3.0 have a release date? I need an XSD 3.0 version for Sun and > soon. The 3.0.0 version will be released in 2-3 weeks. It will be very close to 3.0.0.b2. I can build you a 3.0.0.b2 binary for Solaris in the meantime. Do you need SPARC or x86? hth, -boris From boris at codesynthesis.com Thu Jul 5 17:17:36 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] 3.0 release In-Reply-To: References: <20070705142814.GE3830@karelia> Message-ID: <20070705211736.GD6180@karelia> Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Boris, > That is great. We have a mid-Aug delivery date, but if you would build > the Solaris binaries that would be great. The most time I can get the > better. Right now I need SPARC. Thanks Again. Ok, the binary is ready and can be downloaded from http://www.codesynthesis.com/products/xsd/download.xhtml I've tested it with Sun CC 5.7 (Studio 10) and 5.8 (Studio 11) -- everything works except the wildcard example for the C++/Tree mapping. We will look into this before the final release. hth, -boris From tyrecius13 at yahoo.com Sat Jul 7 21:07:04 2007 From: tyrecius13 at yahoo.com (Jon D) Date: Sun Oct 11 15:33:57 2009 Subject: Fwd: Re: [xsd-users] Lines numbers after parsing Message-ID: <649952.58778.qm@web54601.mail.re2.yahoo.com> I accidentally didn't reply to the list. Below is my email: --- Jon D wrote: > Date: Sat, 7 Jul 2007 18:05:14 -0700 (PDT) > From: Jon D > Subject: Re: [xsd-users] Lines numbers after parsing > To: Boris Kolpackov > > > --- Boris Kolpackov wrote: > > > The most natural way to access this information if by using the > > DOM association. This feature allows you to keep the DOM tree of > > your XML document around. You can call the _node () function on > > a C++/Tree node and get the corresponding DOM node. From there > > you can get the actual element/attribute name (those are not kept > > in the C++/Tree nodes) as well as possibly reconstruct the XML > > fragment to show to the user. > > I was able to do this easily by following the example on your faq. > > > Line and column numbers pose a bit of a problem since Xerces-C++ > DOM > > tree does not store them (for practical reasons). This, however, > > is relatively easy to overcome by customizing the XercesDOMParser > > and storing the line/column information as user data. One example > > of this approach is available in the Xerces-C++ mailing list > > archives: > > > > http://marc.info/?l=xerces-c-users&m=115531248220918&w=2 > > This turned out to be pretty easy too. I simplified it and thought > that > I was ready for prime time. That is when things got very difficult. > :) > > There were two possible ways of doing the association between nodes > and > line numbers. The first is to use the setUserData/getUserData > facility > and the second mentioned in that email in an offhand way was to > create > a mapping from node addresses to line numbers. > > This works great in a pure-Xerces environment. But when transforming > it > into xsd using the name(DOMDocument), everything falls apart. The > transformation calls cloneNode() which interacts badly with both the > above options. > > It completely removes the ability to map node addresses. But it seems > that cloneNode() causes odd problems with the user data as well. > Sometimes (when it is called on the whole DOMDocument), cloneNode() > will silently not clone user data or call the DOMUserDataHandler. > Sometimes (when it is called on a DOMElement), it will do both. The > name(DOMDocument) call runs it on the DOMDocument which means that > user > data is lost. > > I've investigated this to the limits of my ability, looking at the > source code and trying to find a workaround. But to no avail. I've > even > tried updating to the latest SVN version of Xerces-c, but that > doesn't > play well with xsd in the least. > > If you have the desire and capability to pursue this further, I can > provide some minimal demonstration code. I think that the most likely > problem is that at one point (circa 2001), cloneNode() just ignored > user data completely > (https://issues.apache.org/jira/browse/XERCESC-48). Perhaps when they > added userDataHandlers into the library, notifications were > inconsistently added. > > Ideally, the solution would be either a patch on Xerces-c fixing the > bug or a patch on xsd allowing a tree to be created without cloning > the > DOM nodes. > > > hth, > > Thanks for your help so far. It seems incredible to me that I have to > go through such herculean effort just to get error-reporting working. > > > > > > ____________________________________________________________________________________ > Get the free Yahoo! toolbar and rest assured with the added security > of spyware protection. > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php > ____________________________________________________________________________________ Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting From boris at codesynthesis.com Sun Jul 8 04:05:03 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: Fwd: Re: [xsd-users] Lines numbers after parsing In-Reply-To: <649952.58778.qm@web54601.mail.re2.yahoo.com> References: <649952.58778.qm@web54601.mail.re2.yahoo.com> Message-ID: <20070708080503.GA14517@karelia> Hi Jon, Jon D writes: > If you have the desire and capability to pursue this further, I can > provide some minimal demonstration code. I think that the most likely > problem is that at one point (circa 2001), cloneNode() just ignored > user data completely > (https://issues.apache.org/jira/browse/XERCESC-48). Perhaps when they > added userDataHandlers into the library, notifications were > inconsistently added. I would definitely like this bug reported and fixed in Xerces-C++. I checked and it appears the DOMUserDataHandler interface is supposed to support cloning. Are you saying if you clone the whole tree (from DOMDocument) then the corresponding clone events are not triggered on DOMUserDataHandler? What about the current SVN version? > Ideally, the solution would be either a patch on Xerces-c fixing the > bug or a patch on xsd allowing a tree to be created without cloning > the DOM nodes. Actually the upcoming version (3.0.0) will support re-using DOM trees without cloning. For that a new flag, xml_schema::flags::own_dom, was added. You can already get this functionality in the latest 3.0.0.b2. For more information on this flag see Chapter 3, "Parsing" in the C++/Tree Mapping User Manual that comes with the 3.0.0.b2 release. The final 3.0.0 should be released in 2-3 weeks. hth, -boris From tyrecius13 at yahoo.com Sun Jul 8 05:28:27 2007 From: tyrecius13 at yahoo.com (Jon D) Date: Sun Oct 11 15:33:57 2009 Subject: Fwd: Re: [xsd-users] Lines numbers after parsing In-Reply-To: <20070708080503.GA14517@karelia> Message-ID: <684281.75925.qm@web54607.mail.re2.yahoo.com> --- Boris Kolpackov wrote: > I would definitely like this bug reported and fixed in Xerces-C++. > I checked and it appears the DOMUserDataHandler interface is supposed > to support cloning. Are you saying if you clone the whole tree (from > DOMDocument) then the corresponding clone events are not triggered > on DOMUserDataHandler? What about the current SVN version? Below is my current minimal example which consistently reproduces the bug on my system. Note that I have just been using the simple hello.xml and hello.xsd files from your examples as data: ---Begin minimal.cc--- // minimal.cpp #include #include #include #include #include #include #include #include using std::cerr; using std::endl; using std::auto_ptr; using namespace xercesc; namespace xml = xsd::cxx::xml; static XMLCh * customKey = L"CustomKey"; class CustomDataHandler : public DOMUserDataHandler { public: virtual void handle(DOMOperationType operation, const XMLCh *const /*key*/, void * /*data*/, const DOMNode * /*src*/, const DOMNode * /*dst*/) { cerr << "dataHandler called" << endl; } }; static CustomDataHandler dataHandler; class CustomDOMParser : public XercesDOMParser { virtual void startElement(const XMLElementDecl &elemDecl, const unsigned int uriId, const XMLCh *const prefixName, const RefVectorOf & attrList, const unsigned int attrCount, const bool isEmpty, const bool isRoot) { XercesDOMParser::startElement(elemDecl, uriId, prefixName, attrList, attrCount, isEmpty, isRoot); getCurrentNode()->setUserData(customKey, (void*)5, &dataHandler); } }; int main() { try { XMLPlatformUtils::Initialize(); auto_ptr parser(new CustomDOMParser()); parser->parse("hello.xml"); xml::dom::auto_ptr original(parser->adoptDocument()); cerr << "--- Before clone document" << endl; xml::dom::auto_ptr clonedDocument(original->cloneNode(true)); cerr << "--- After clone document" << endl << endl; cerr << "--- Before clone element" << endl; xml::dom::auto_ptr clonedElement (original->getDocumentElement()->cloneNode(true)); cerr << "--- After clone element" << endl << endl; } catch (...) { cerr << "Unknown Exception" << endl; } XMLPlatformUtils::Terminate(); return 0; } ---End minimal.cc--- The result I get is: --- Before clone document --- After clone document --- Before clone element dataHandler called dataHandler called dataHandler called dataHandler called dataHandler called --- After clone element dataHandler called dataHandler called dataHandler called dataHandler called dataHandler called Which implies that the dataHandler is not being called when cloning the document as a whole. I've spot tested other parts of the cloned document (using things like getLocalName()) and they seem to be ok. I've only tested it under Windows XP using VC++ 7.1. I will try to reproduce it under linux and the latest SVN after I remove the last little bits of xsd (your nifty auto_ptrs). If I can still reproduce it I'll submit it as a bug. This behaviour seems very odd to me as well. Let me know whether you can reproduce it and if I am doing anything obviously incorrect here. > Actually the upcoming version (3.0.0) will support re-using DOM trees > without cloning. For that a new flag, xml_schema::flags::own_dom, was > added. You can already get this functionality in the latest 3.0.0.b2. > For more information on this flag see Chapter 3, "Parsing" in the > C++/Tree Mapping User Manual that comes with the 3.0.0.b2 release. > The final 3.0.0 should be released in 2-3 weeks. That will be a handy workaround until the core bug gets fixed. Thanks. -D ____________________________________________________________________________________ Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 From Ryan.Prather at afspc.af.mil Tue Jul 10 14:44:16 2007 From: Ryan.Prather at afspc.af.mil (Prather, Ryan C SSgt DMSG/WMTS) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Xerces Solaris issue Message-ID: I am having an issue when I am trying to compile my code on the Solaris. It works find on Windows, but I am getting a whole bunch of "static member ... must be defined in the program". They are all either data members or objects of some type. The errors all say that they are coming from the test driver file that XSD genereated. I made sure to include all the directories that Xerces and XSD use (bin, lib, libxsd, and include). I downloaded the latest version of Xerces. Any ideas? Ryan From uri at hyperroll.com Wed Jul 11 00:50:58 2007 From: uri at hyperroll.com (Uri Karagila) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] counting attribute Message-ID: <783879783B65E44995520FEF376C45380C4FFC@ilexch1.int.hyperroll.com> Hey, Lets assume I have an xsd complex type element/object which own multiple attributes (some are `optional=true` and other are not). My questions are: 1. What would be the best way to count the number of "present" attributes of a random object? 2. is there a structured way to "go over" existing attributes of random object? Regards Uri From boris at codesynthesis.com Wed Jul 11 11:28:24 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Xerces Solaris issue In-Reply-To: References: Message-ID: <20070711152824.GC3191@karelia> Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > I am having an issue when I am trying to compile my code on the Solaris. > It works find on Windows, but I am getting a whole bunch of "static > member ... must be defined in the program". They are all either data > members or objects of some type. The errors all say that they are > coming from the test driver file that XSD genereated. I made sure to > include all the directories that Xerces and XSD use (bin, lib, libxsd, > and include). I downloaded the latest version of Xerces. Any ideas? I assume the undefined symbols are from the Xerces-C++ library. Provided that you are linking your application with the library (i.e., you have something like -lxerces-c in the command line) then the most likely cause of this is linking to the Xerces-C++ library that was built with a different compiler (i.e., Sun CC if you are using g++ or vice versa). hth, -boris From boris at codesynthesis.com Wed Jul 11 12:03:06 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] counting attribute In-Reply-To: <783879783B65E44995520FEF376C45380C4FFC@ilexch1.int.hyperroll.com> References: <783879783B65E44995520FEF376C45380C4FFC@ilexch1.int.hyperroll.com> Message-ID: <20070711160306.GD3191@karelia> Hi Uri, Uri Karagila writes: > Lets assume I have an xsd complex type element/object which own multiple > attributes (some are `optional=true` and other are not). > > My questions are: > > 1. What would be the best way to count the number of "present" > attributes of a random object? The best way would be to keep the DOM tree associated with the object model and then, when you need to count the attributes, call _node() to obtain the pointer to DOMNode that corresponds to this tree node and count the present attributes. > 2. is there a structured way to "go over" existing attributes of > random object? Yes, using the Xerces-C++ DOM interface. Note that you can also "get back" from a DOM node to the corresponding tree node by obtaining and casting the user data pointer with the xml_schema::tree_node_key key. For more information on DOM association, see the mixed example in the examples/cxx/tree/ directory and read Section 3.2, "Flags and Properties" in the manual. hth, -boris From boris at codesynthesis.com Wed Jul 11 12:48:36 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: Fwd: Re: [xsd-users] Lines numbers after parsing In-Reply-To: <684281.75925.qm@web54607.mail.re2.yahoo.com> References: <20070708080503.GA14517@karelia> <684281.75925.qm@web54607.mail.re2.yahoo.com> Message-ID: <20070711164836.GA3724@karelia> Hi Jon, Jon D writes: > I've only tested it under Windows XP using VC++ 7.1. I will try to > reproduce it under linux and the latest SVN after I remove the last > little bits of xsd (your nifty auto_ptrs). If I can still reproduce it > I'll submit it as a bug. Thanks for the test case. I tried it on the SVN head and the bug is still there. Because I had to modify your test case (some function signatures have changed for 3.0.0), I also submitted the bug report: https://issues.apache.org/jira/browse/XERCESC-1722 > That will be a handy workaround until the core bug gets fixed. It is also more efficient since there is no copying involved. hth, -boris From matt.burnham.ctr at mhpcc.hpc.mil Thu Jul 12 14:50:09 2007 From: matt.burnham.ctr at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Limiting field sizes when serializing to DOM documents Message-ID: <469677E1.3040706@mhpcc.hpc.mil> Boris, I have the following schema (only the relevant parts shown): I create an in-memory tree (my_event) and then serialize it to a DOM document to output XML: std::ostringstream buff; xml_schema::namespace_infomap nsm; xercesc::XMLPlatformUtils::Initialize(); // serialize the event into a DOM document xsd::cxx::xml::dom::auto_ptr event_doc( event_(my_event, nsm) ); // write the resulting DOM document to XML xercesc::DOMImplementation* impl( xercesc::DOMImplementationRegistry::getDOMImplementation(xsd::cxx::xml::string("LS").c_str()) ); std::auto_ptr writer( impl->createDOMWriter() ); xsd::cxx::xml::dom::ostream_format_target ft( buff ); writer->writeNode( &ft, *event_doc ); xercesc::XMLPlatformUtils::Terminate(); std::string xml_str = buff.str(); And I get the following: Is there some way the enforce the restriction when serializing to a DOM document? Thanks, Matt From boris at codesynthesis.com Thu Jul 12 17:44:14 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Limiting field sizes when serializing to DOM documents In-Reply-To: <469677E1.3040706@mhpcc.hpc.mil> References: <469677E1.3040706@mhpcc.hpc.mil> Message-ID: <20070712214414.GB3563@karelia> Hi Matt, Matt Burnham writes: > And I get the following: > > > > > > Is there some way the enforce the > restriction when serializing to a DOM document? I think you misunderstand the semantics of the minInclusive facet. When used on the decimal type, it forces the value to be greater or equal to that specified and not the precision of the value. I assume you want to get something like version="2.0" in your XML instance. The XSD runtime uses the standard ostream insertion operator for long double (that is what xsd:decimal is mapped to by default in 2.x.y series). While the result depends on the particular implementation of the C++ runtime, I am surprised you get this number of trailing zeros for 2.0, assuming, of course, the actual value is 2.0, and not something like 2.0000000000000000000000001. Can you confirm that you indeed serialize 2.0? Also which version of XSD are you using? hth, -boris From matt.burnham.ctr at mhpcc.hpc.mil Thu Jul 12 18:35:06 2007 From: matt.burnham.ctr at mhpcc.hpc.mil (Matt Burnham) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Limiting field sizes when serializing to DOM documents In-Reply-To: <20070712214414.GB3563@karelia> References: <469677E1.3040706@mhpcc.hpc.mil> <20070712214414.GB3563@karelia> Message-ID: <4696AC9A.5040402@mhpcc.hpc.mil> Boris, Boris Kolpackov wrote: > I assume you want to get something like version="2.0" in your XML > Correct. > instance. The XSD runtime uses the standard ostream insertion > operator for long double (that is what xsd:decimal is mapped to by > default in 2.x.y series). While the result depends on the particular > implementation of the C++ runtime, I am surprised you get this number > of trailing zeros for 2.0, assuming, of course, the actual value is > 2.0, and not something like 2.0000000000000000000000001. Can you > confirm that you indeed serialize 2.0? Also which version of XSD are > you using? > We're using version 2.2.0 on VS 2003 (VC 7.1). Most of the other attributes are also xsd:decimal and all of them have 24 decimal places (mostly trailing zero's). I have a "version" variable (I've tried double, float, and int) that I use when creating my cxx-tree objects, then I serialize it. From Johan.denBoer at NS.NL Fri Jul 13 04:07:00 2007 From: Johan.denBoer at NS.NL (Boer den, Johan J (NSC)) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Document parsing failed Message-ID: Hi, I am having the following problem. We generate C++ classes from our xsd schemas. Later we want to do this action string xmlmessage = ................ // our xml message containg the xsd stringstream ifs; ifs << xmlmessage; auto_ptr pcsAnswer(PCS_CALCULATE_PRICES_ANSWER_(ifs)); We got an std::exception with : instance document parsing failed. What am I doing wrong Johan Dutch railways ------------------------------------------------------------------------------------------ Deze e-mail, inclusief eventuele bijlage(n), is uitsluitend bestemd voor gebruik door de geadresseerde(n). Indien u dit bericht abusievelijk heeft ontvangen, mag de informatie daarvan niet worden gebruikt of openbaar gemaakt, noch aan derden worden verstrekt. Wij verzoeken u om in dat geval direct contact op te nemen met de afzender en de e-mail te vernietigen. This e-mail, including any appendix or appendices, is intended solely for use by the addressee(s). If you have received this message in error, the information it contains may not be used or disclosed, nor may it be revealed to third parties. In that case, please contact the sender immediately and destroy the e-mail. From boris at codesynthesis.com Fri Jul 13 04:13:51 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Document parsing failed In-Reply-To: References: Message-ID: <20070713081351.GC3563@karelia> Hi Johan, Boer den, Johan J (NSC) writes: > I am having the following problem. We generate C++ classes from our xsd > schemas. Later we want to do this action > > string xmlmessage = ................ // our xml message containg the > xsd > > stringstream ifs; > ifs << xmlmessage; > > auto_ptr > pcsAnswer(PCS_CALCULATE_PRICES_ANSWER_(ifs)); > > We got an std::exception with : instance document parsing failed. This is most likely related to the failure to validate the XML document because the schema could not be found for it. Please see: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#2 Also you may want to catch and print the exception being thrown to get more information: try { // parsing code goes here } catch (const xml_schema::exception& e) { cerr << e << endl; } hth, -boris From rlischner at proteus-technologies.com Fri Jul 13 09:07:53 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Document parsing failed References: <20070713081351.GC3563@karelia> Message-ID: > try > { > // parsing code goes here > } > catch (const xml_schema::exception& e) > { > cerr << e << endl; > } I just want to say that this way of displaying information about exceptions is strange, and a stumbling block for teaching our programmers how to use Code Synthesis. It's a minor annoyance, and once a programmer learns how to catch Code Synthesis exceptions, the lesson usually sticks, but it's a lesson that I have to teach over and over and over because it's so unusual. Why can't what() return the full information, as is the convention? If I want to wrap an xml_schema::exception in another exception to throw, I need to create a temporary string stream just to extract the exception message. -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Fri Jul 13 09:34:20 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Limiting field sizes when serializing to DOM documents In-Reply-To: <4696AC9A.5040402@mhpcc.hpc.mil> References: <469677E1.3040706@mhpcc.hpc.mil> <20070712214414.GB3563@karelia> <4696AC9A.5040402@mhpcc.hpc.mil> Message-ID: <20070713133420.GD3244@karelia> Hi Matt, Matt Burnham writes: > Most of the other attributes are also xsd:decimal and all of them have > 24 decimal places (mostly trailing zero's). I did some digging and it appear that this is how the combination of std::fixed and setprecision() works. We have to use std::fixed because xsd:decimal cannot be in scientific notation. For the upcoming 3.0.0 release we are going to try to address this issue. If you would like, I can create a patch against 3.0.0.b2 for you. Another way to "fix" this, without upgrading XSD, is to change xsd:decimal to xsd:double or xsd:float. With those types you shouldn't get any trailing zeros. hth, -boris From boris at codesynthesis.com Fri Jul 13 09:52:06 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Document parsing failed In-Reply-To: References: <20070713081351.GC3563@karelia> Message-ID: <20070713135206.GE3244@karelia> Hi Ray, Ray Lischner writes: > Why can't what() return the full information, as is the convention? For several reasons. First, what() is "hard coded" to return char* while XSD exceptions can use char or wchar_t depending on the character type selected during schema compilation. Also, since what() returns "const char*", the string buffer that holds the text has to be allocated in the exception itself. Because what() is no-throw, it can be tricky to populate that buffer within what() itself so the text has to be pre-formatted when exception is created which can be quite wasteful. Then there are conceptual reasons. Many people believe that what() should return a string that is always the same for this type of exception so that it is more like a key which can be used to look-up other information (e.g., a language- specific error description, etc.). The fact that it returns const char* and not std::string as well as the no-throw exception specification all suggest this semantics. We could have provided another function in our exception hierarchy that returns the description as a string. We decided against that method since most of the time the next operation on that string will be to print it and the whole string creating would be a waste. Instead we decided to provide a way to print the exception directly to std::ostream. Note also that you can always catch a concrete exception (e.g., xml_schema::parsing) which includes all the information you see when you print the exception but in a structured way that is more convenient for programmatic access. hth, -boris From Ryan.Prather at afspc.af.mil Mon Jul 16 11:31:17 2007 From: Ryan.Prather at afspc.af.mil (Prather, Ryan C SSgt DMSG/WMTS) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] File Closing Message-ID: In the implementation that we are using xsd we have created a class that we can call multiple parsers in a threaded approach so I have a two-fold question. Is xsd/xerces thread-safe? 2. We are getting an error "Type XMLPlatformException, message: Could not close the file", does xsd use a static or dynamic file handle to reading the files? When and where is the file closed? Would there be a way that I can call the file closer to close the file within say the post of the root tag? Thanks. Ryan From boris at codesynthesis.com Mon Jul 16 12:10:15 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] File Closing In-Reply-To: References: Message-ID: <20070716161015.GB4399@karelia> Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Is xsd/xerces thread-safe? Yes but you need to make sure the Xerces-C++ runtime if initialized and terminated only once. The easies way to do this is to initialize/terminate Xerces-C++ from main() when there aren't any threads yet/anymore: #include int main () { xercesc::XMLPlatformUtils::Initialize (); { // Start threads and parse here. } xercesc::XMLPlatformUtils::Terminate (); } Because you initialize the runtime yourself you should also pass the xml_schema::flags::dont_initialize flag to the parse() function: xml_schema::document doc_p (...); doc_p.parse ("test.xml", xml_schema::flags::dont_initialize); > 2. We are getting an error "Type XMLPlatformException, message: Could > not close the file", does xsd use a static or dynamic file handle to > reading the files? When and where is the file closed? In this case the file opening and closing is performed by Xerces-C++ and there appears to be a bug that is fixed for the next version of Xerces-C++: https://issues.apache.org/jira/browse/XERCESC-1658 This problem only occurs on Solaris, right? > Would there be a way that I can call the file closer to close the > file within say the post of the root tag? If you don't use XML Schema validation in Xerces-C++ then you can handle file opening/closing yourself and pass an std::istream to the parse() function instead of a file name: #include std::ifstream ifs ("test.xml"); if (!ifs.open ()) { // could not open } ... doc_p.parse (ifs, "test.xml", xml_schema::flags::dont_initialize); ... ifs.close (); If you do use XML Schema validation, then this method may not work because Xerces-C++ will still be opening the schema files. For this situation I can extract the fix from Xerces-C++ SVN and send it to you. hth, -boris From Michael.Caruso at itt.com Mon Jul 16 15:02:57 2007 From: Michael.Caruso at itt.com (Caruso, Michael - AES) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] (no subject) Message-ID: <7DB20341F654384C8541A8E2FF63CCD702694097@01HRNMX09-1.aes.de.ittind.com> Is there a way to get more descriptive exceptions from the parser? Right now If I purposely invalidate the XML I only receive a generic exception as such: "instance document parsing failed" Xerces usually provides more detailed exceptions, I understand that xsd also supports xpat but in this case xerces is being used. Thanks, Mike ***************************************************************** This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail. ******************************************************************* From boris at codesynthesis.com Mon Jul 16 15:23:23 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] (no subject) In-Reply-To: <7DB20341F654384C8541A8E2FF63CCD702694097@01HRNMX09-1.aes.de.ittind.com> References: <7DB20341F654384C8541A8E2FF63CCD702694097@01HRNMX09-1.aes.de.ittind.com> Message-ID: <20070716192323.GA7501@karelia> Hi Michael, Caruso, Michael - AES writes: > Is there a way to get more descriptive exceptions from the parser? > Right now If I purposely invalidate the XML I only receive a generic > exception as such: > > "instance document parsing failed" Yes, the easiest way is to just print the exception to cerr: try { // parsing } catch (const xml_schema::exception& e) { cerr << e << endl; } For more information about error handling in the C++/Tree mapping see Section 2.2: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.2 and 3.3: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#3.3 in the C++/Tree Mapping Manual (let me know if you are using C++/Parser). The exception that is thrown during parsing when the document is invalid is xml_schema::parsing (Section 3.3.1). hth, -boris From sbalasub at qualcomm.com Tue Jul 17 05:08:16 2007 From: sbalasub at qualcomm.com (Balasubramanyam, Shivakumar) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Questions on few features. Message-ID: Folks, I have been pretty happy with the tool so far and really like the generated code. I was able to perform XML-C++-XML back for few schema files. I have few questions on some of the features. 1. -extern-xmlschema. I have xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="./xml.xsd"/> which generates a #include "xml.hxx" but also generates the Namespace xml_schema and all the fundamental XML types. To avoid this I added -extern-xmlschema="xml.xsd' which also generates #include "xml.hxx". This is not a problem but I just want to make sure if am using the right options. 2. What is the need for -root-element options? What are the cost of having of -root-element-all versus just one that you *really* want? 3. I have not seen the implementation of the serialization. Does the ostream serialization depend on XERCES? I mean can we disable XERCES dependency but still generate XML documents for logging purposes. I know -generate-otream generates can be used but the format is not structured. 4. This is more to solve above point in a more generic way. Has there been any thoughts on decoupling the C++ objects that represent the XSD datatypes separate from feature supports like serialization or XML parsing etc. Thanks, Shiva From boris at codesynthesis.com Tue Jul 17 10:05:11 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Questions on few features. In-Reply-To: References: Message-ID: <20070717140511.GB9943@karelia> Hi Shivakumar, Balasubramanyam, Shivakumar writes: > 1. -extern-xmlschema. > > I have xs:import namespace="http://www.w3.org/XML/1998/namespace" > schemaLocation="./xml.xsd"/> which generates a #include "xml.hxx" but > also generates the > > Namespace xml_schema and all the fundamental XML types. > > To avoid this I added -extern-xmlschema="xml.xsd' which also generates > #include "xml.hxx". > > This is not a problem but I just want to make sure if am using the right > options. I am not sure what you are trying to achieve. xml.xsd is not a replacement for the XML Schema build-in types that are generated in the xml_schema namespace. The --extern-xml-schema option allows you to factor the xml_schema namespace into a separate file and include it in other generated files instead of generating the xml_schema namespace in every file. To achieve this you will first do: $ xsd cxx-tree --generate-xml-schema xml-schema.xsd This will generate xml-schema.hxx which contains the xml_schema namespace. The xml-schema.xsd name is a fake file name which does not have to exist. It is only used to derive the name of the header file (xml-schema.hxx). Then you would compile your schemas like so: $ xsd cxx-tree --extern-xml-schema xml-schema.xsd my-schema1.xsd $ xsd cxx-tree --extern-xml-schema xml-schema.xsd my-schema2.xsd $ xsd cxx-tree --extern-xml-schema xml-schema.xsd xml.xsd This will result in xml-schema.hxx being included in generated my-schema1.hxx, my-schema2.hxx, and xml.hxx. Again, the xml-schema.xsd name that is passed to the --extern-xml-schema option is a fake file name that is used to derive the header name to include. > 2. What is the need for -root-element options? It allows you to specify the real root element(s) for your vocabulary. Many schemas define a large number of global elements that are not valid document roots. By default XSD generates a set of parsing and serialization functions for each global element. By specifying the root element(s) you make XSD generate those functions only for that element. > What are the cost of having of -root-element-all versus just one > that you *really* want? You will get a potentially large (if you have many global elements) chunk of code that is not necessary, slows down compilation, and bloats your object code. > 3. I have not seen the implementation of the serialization. Does > the ostream serialization depend on XERCES? Serialization to XML depends on Xerces-C++. > I mean can we disable XERCES dependency but still generate XML > documents for logging purposes. No, this is not possible with the C++/Tree mapping. > 4. This is more to solve above point in a more generic way. Has > there been any thoughts on decoupling the C++ objects that represent the > XSD datatypes separate from feature supports like serialization or XML > parsing etc. There is a way not to generate pretty much every aspect of the code that may not be needed. For example you can use the --suppress-parsing option to get rid of the XML parsing code. In fact if you pass --suppress-parsing and don't pass --generate-serialization, you will end up with just the object model that can neither read nor write XML. However, I am not sure how useful this feature is to you. If I understood you correctly, you still want to create XML documents but without using Xerces-C++. It seems to me that what you really want is a way to plug a different XML serializer instead of Xerces-C++ (BTW, which one would you prefer?). This is not possible with the C++/Tree mapping but we are working on another mapping similar to C++/Tree that will allow changing the underlying XML parser/serializer. hth, -boris From sbalasub at qualcomm.com Tue Jul 17 12:35:14 2007 From: sbalasub at qualcomm.com (Balasubramanyam, Shivakumar) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Questions on few features. References: <20070717140511.GB9943@karelia> Message-ID: Thanks for detailed respons. I have removed text I agreed with and have no more questions. My other comments are inline. ________________________________ > 4. This is more to solve above point in a more generic way. Has > there been any thoughts on decoupling the C++ objects that represent the > XSD datatypes separate from feature supports like serialization or XML > parsing etc. There is a way not to generate pretty much every aspect of the code that may not be needed. For example you can use the --suppress-parsing option to get rid of the XML parsing code. In fact if you pass --suppress-parsing and don't pass --generate-serialization, you will end up with just the object model that can neither read nor write XML. However, I am not sure how useful this feature is to you. If I understood you correctly, you still want to create XML documents but without using Xerces-C++. It seems to me that what you really want is a way to plug a different XML serializer instead of Xerces-C++ (BTW, which one would you prefer?). This is not possible with the C++/Tree mapping but we are working on another mapping similar to C++/Tree that will allow changing the underlying XML parser/serializer. [Shiva] I am using the xerces parser and have no issues at present. It seems like you guys are already headed towards other serializers. I was thinking plugging in a binary serializer. Like Boost, the serializers could be XML, binary or simple text logging. But XSD has the important function to generate the mapping and structure. Why should XSD depend on xerces for logging in XML? If I have a binary protocol that I would like to use schemas to define, then I could use XSD to generate code for binary serializing and deserializing but log the messages in XML for easy debugging. Thanks, Shiba hth, -boris From boris at codesynthesis.com Wed Jul 18 05:08:06 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Questions on few features. In-Reply-To: References: <20070717140511.GB9943@karelia> Message-ID: <20070718090806.GD15082@karelia> Hi Shivakumar, Balasubramanyam, Shivakumar writes: > [Shiva] I am using the xerces parser and have no issues at present. > It seems like you guys are already headed towards other serializers. > I was thinking plugging in a binary serializer. Like Boost, the > serializers could be XML, binary or simple text logging. Well, this is already supported. You can serialize to XML (using Xerces-C++), to a binary data representation such as XDR or CDR (for which you will need a library that performs low-level binary serialization, such as ACE CDR streams, see the 'binary' example) or to simple "unstructured" text by generating the std::ostream insertion operators with the --generate-ostream option. > But XSD has the important function to generate the mapping and > structure. Why should XSD depend on xerces for logging in XML? Because XSD does not do low-level XML serialization itself (things like character encoding, escaping of special symbols, indentation, etc.). Instead it depends on existing facilities in Xerces-C++. Plus it is much more flexible since you can serialize the data to DOM instead of XML and then do some extra processing like calculating a digital signature, etc. hth, -boris From drjat320 at gmail.com Wed Jul 18 11:24:57 2007 From: drjat320 at gmail.com (d rj) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] including xsd libs in Visual Studio 2005 Message-ID: <288e77f30707180824w3336811cy462db1b8db648c72@mail.gmail.com> Hello- i just started using xsd w/ vs2005. most things seem to work fine however when i add the xsd "include" directory to the list of included libraries. upon adding the xsd library reference vs2005 seems to freeze indefinitely while attempting to update its intellisense dictionary (or other items) with the newly included libs. just wondering if any one else has encountered this or has a possible work around. any insight would be appreciated. regards. From boris at codesynthesis.com Wed Jul 18 12:21:29 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] including xsd libs in Visual Studio 2005 In-Reply-To: <288e77f30707180824w3336811cy462db1b8db648c72@mail.gmail.com> References: <288e77f30707180824w3336811cy462db1b8db648c72@mail.gmail.com> Message-ID: <20070718162129.GB15878@karelia> Hi, d rj writes: > i just started using xsd w/ vs2005. most things seem to work fine however > when i add the xsd "include" directory to the list of included libraries. > upon adding the xsd library reference vs2005 seems to freeze indefinitely > while attempting to update its intellisense dictionary (or other items) with > the newly included libs. Hm, I use default installation of VS 2005 and have never experienced anything like this. Just to be clear, you are adding the libxsd directory as an include directory in "Tools"/"Options"/"Projects"/"VC++ Directories" Is that correct? Also which version of XSD are you using? Have you applied SP1 for VS 2005? (Note that if you haven't then I am not suggesting that you should since it is quite buggy). thanks, -boris From boris at codesynthesis.com Wed Jul 18 13:10:33 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] including xsd libs in Visual Studio 2005 In-Reply-To: <288e77f30707180946v767c9db1k84dfe570cb071e5f@mail.gmail.com> References: <288e77f30707180824w3336811cy462db1b8db648c72@mail.gmail.com> <20070718162129.GB15878@karelia> <288e77f30707180946v767c9db1k84dfe570cb071e5f@mail.gmail.com> Message-ID: <20070718171033.GC15878@karelia> Hi, In the future please keep your replies CC'ed to the xsd-users mailing list. This way a) other developers who may have experienced a similar problem can provide you with a solution b) questions and answers will be archived and available to others with similar problems. d rj writes: > correct. > I attempted adding the include dir via the Tools/Options confiig dialog (as > you noted) as well as via the project properties' "Additional Include > Directories". both produced the same results. > i am using a recently downloaded xsd-2.3. > no vs2005 sp1 has been installed. > thanks for the response. Hm, this is really strange. I don't really think it is an intellisense problem since it only collects information for files in the project and not just any directory with headers. VS 2005 is used quite extensively with XSD and you are the first person reporting this problem. It seems that it is an issue with your particular installation. Does anything like this happen when you add some other directory, say Xerces-C++ include/? Also is the libxsd directory on a network file system of any sort? The only other thing that I can think of is to try the 3.0.0.b2 and see if you have the same problem. Or you could try to narrow the problem down by gradually removing headers from libxsd. hth, -boris From dstockdi at csc.com Wed Jul 18 13:29:48 2007 From: dstockdi at csc.com (David J Stockdill) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] including xsd libs in Visual Studio 2005 In-Reply-To: <20070718171033.GC15878@karelia> Message-ID: Boris, I'm having the same problem. I have not come up with a solution other than turning off intellisense & deleting the .ncb file. I had not associated it with xsd/xerces before now but it only occurs in the project that uses xsd. It doesn't happen consistently. When it does, it uses virtually all of the CPU time. Dave -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Boris Kolpackov To Sent by: d rj xsd-users-bounces cc @codesynthesis.co xsd-users@codesynthesis.com m Subject Re: [xsd-users] including xsd libs in Visual Studio 2005 07/18/2007 01:10 PM Hi, In the future please keep your replies CC'ed to the xsd-users mailing list. This way a) other developers who may have experienced a similar problem can provide you with a solution b) questions and answers will be archived and available to others with similar problems. d rj writes: > correct. > I attempted adding the include dir via the Tools/Options confiig dialog (as > you noted) as well as via the project properties' "Additional Include > Directories". both produced the same results. > i am using a recently downloaded xsd-2.3. > no vs2005 sp1 has been installed. > thanks for the response. Hm, this is really strange. I don't really think it is an intellisense problem since it only collects information for files in the project and not just any directory with headers. VS 2005 is used quite extensively with XSD and you are the first person reporting this problem. It seems that it is an issue with your particular installation. Does anything like this happen when you add some other directory, say Xerces-C++ include/? Also is the libxsd directory on a network file system of any sort? The only other thing that I can think of is to try the 3.0.0.b2 and see if you have the same problem. Or you could try to narrow the problem down by gradually removing headers from libxsd. hth, -boris From sergey at hyperroll.com Thu Jul 19 07:35:33 2007 From: sergey at hyperroll.com (Sergey Tatarenko) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] RE: 3. including xsd libs in Visual Studio 2005 (d rj) In-Reply-To: <200707181600.l6IG08sc011308@codesynthesis.com> References: <200707181600.l6IG08sc011308@codesynthesis.com> Message-ID: <783879783B65E44995520FEF376C45380C5197@ilexch1.int.hyperroll.com> >Hello- > >i just started using xsd w/ vs2005. most things seem to work fine however when i add the xsd "include" directory to the list of included libraries. >upon adding the xsd library reference vs2005 seems to freeze indefinitely while attempting to update its intellisense dictionary (or other items) with the newly included libs. > >just wondering if any one else has encountered this or has a possible work around. any insight would be appreciated. > >regards. I encounter pretty the same behaviour of VS2005. I have VS2005 with VAssistX integrated. Avn't found any workaround Regards. From boris at codesynthesis.com Thu Jul 19 10:49:24 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] including xsd libs in Visual Studio 2005 In-Reply-To: References: <20070718171033.GC15878@karelia> Message-ID: <20070719144924.GA23428@karelia> Hi David, David J Stockdill writes: > I'm having the same problem. I have not come up with a solution other than > turning off intellisense & deleting the .ncb file. I had not associated it > with xsd/xerces before now but it only occurs in the project that uses xsd. > It doesn't happen consistently. When it does, it uses virtually all of the > CPU time. Thanks for the additional information. Does this freezing happens when you add include directories or randomly while you are working with projects that use XSD? thanks, -boris From boris at codesynthesis.com Thu Jul 19 10:59:35 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] including xsd libs in Visual Studio 2005 In-Reply-To: <20070718171033.GC15878@karelia> References: <288e77f30707180824w3336811cy462db1b8db648c72@mail.gmail.com> <20070718162129.GB15878@karelia> <288e77f30707180946v767c9db1k84dfe570cb071e5f@mail.gmail.com> <20070718171033.GC15878@karelia> Message-ID: <20070719145935.GB23428@karelia> Hi, I am trying to reproduce your problem, so far unsuccessfully. Here is what I tried: 1. Install xsd-2.3.1 (from xsd-2.3.msi) 2. Create a hello-world console project in VS 2005. Compile it. Verify Intellisense is working (get auto-completion, etc.). 3. Add the XSD include directory in "Additional Include Directories" for the project. No freezing, Intellisense is still working. 4. Add the XSD include directory in Tools->Options->Project & Solutions-> VC++ Directories (while solution is open). No freezing, Intellisense is still working. Do you see what I am doing differently? Also I wonder what happens if you add the directory in Tools->Options while there isn't any solution open? My Help->About shows Version 8.0.50727.42 (RTM.050727-4200). Do you use the same version? Thanks for your help. -boris From drjat320 at gmail.com Fri Jul 20 11:22:23 2007 From: drjat320 at gmail.com (d rj) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] including xsd libs in Visual Studio 2005 In-Reply-To: <20070719145935.GB23428@karelia> References: <288e77f30707180824w3336811cy462db1b8db648c72@mail.gmail.com> <20070718162129.GB15878@karelia> <288e77f30707180946v767c9db1k84dfe570cb071e5f@mail.gmail.com> <20070718171033.GC15878@karelia> <20070719145935.GB23428@karelia> Message-ID: <288e77f30707200822p51b66b07lee53dcba44eb1f15@mail.gmail.com> your steps and vs version are identical to mine. this seems to be an issue when adding xsd to my existing solution. I.e. creating a simple project and adding xsd to it seems to work with out issue for me. thanks. -david On 7/19/07, Boris Kolpackov wrote: > > Hi, > > I am trying to reproduce your problem, so far unsuccessfully. Here > is what I tried: > > 1. Install xsd-2.3.1 (from xsd-2.3.msi) > > 2. Create a hello-world console project in VS 2005. Compile it. Verify > Intellisense is working (get auto-completion, etc.). > > 3. Add the XSD include directory in "Additional Include Directories" > for the project. No freezing, Intellisense is still working. > > 4. Add the XSD include directory in Tools->Options->Project & Solutions-> > VC++ Directories (while solution is open). No freezing, Intellisense > is still working. > > Do you see what I am doing differently? Also I wonder what happens > if you add the directory in Tools->Options while there isn't any > solution open? > > My Help->About shows Version 8.0.50727.42 (RTM.050727-4200). Do you > use the same version? > > > Thanks for your help. > > -boris > From ope-devel at gmx.de Sat Jul 21 13:33:42 2007 From: ope-devel at gmx.de (ope) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema Message-ID: <46A24376.90408@gmx.de> Hi, I build a tree parser for the metalink schema at http://www.metalinker.org/schema/3.0/metalink.xsd by: xsd cxx-tree \ --namespace-map http://www.metalinker.org/=metalink \ --generate-ostream \ --hxx-suffix .hpp \ --cxx-suffix .cpp metalink.xsd and use it in that manner: ---8<--- header ---8<--- class metalink_parser { private: typedef std::vector metalink_files_t; .... private: metalink_files_t m_metalink_files; std::auto_ptr m_metalink; }; ---8<--- header ---8<--- ---8<--- source ---8<--- // a simple test with the first entry const std::string metalink_file = m_metalink_files.front(); try { // take ownership m_metalink = metalink::metalink(metalink_file); metalink::filesType::file::const_iterator first(m_metalink->files().file().begin()); metalink::filesType::file::const_iterator last(m_metalink->files().file().begin()); for (; first != last; ++first) { cout << *first; } } catch (const xml_schema::exception& e) { cerr << e << endl; } ---8<--- source ---8<--- and get a lot of errors: metalink.xsd:2:216 error: Unknown element 'xs:schema' metalink.xsd:2:216 error: Attribute 'version' is not declared for element 'xs:schema' metalink.xsd:2:216 error: Attribute 'xmlns' is not declared for element 'xs:schema' metalink.xsd:2:216 error: Attribute '{http://www.w3.org/2000/xmlns/}xs' is not declared for element 'xs:schema' metalink.xsd:2:216 error: Attribute 'targetNamespace' is not declared for element 'xs:schema' metalink.xsd:2:216 error: Attribute 'elementFormDefault' is not declared for element 'xs:schema' metalink.xsd:2:216 error: Attribute 'attributeFormDefault' is not declared for element 'xs:schema' metalink.xsd:3:54 error: Unknown element 'xs:element' metalink.xsd:3:54 error: Attribute 'name' is not declared for element 'xs:element' metalink.xsd:3:54 error: Attribute 'type' is not declared for element 'xs:element' metalink.xsd:4:38 error: Unknown element 'xs:complexType' metalink.xsd:4:38 error: Attribute 'name' is not declared for element 'xs:complexType' metalink.xsd:5:22 error: Unknown element 'xs:sequence' metalink.xsd:6:76 error: Unknown element 'xs:element' metalink.xsd:6:76 error: Attribute 'name' is not declared for element 'xs:element' metalink.xsd:6:76 error: Attribute 'type' is not declared for element 'xs:element' metalink.xsd:6:76 error: Attribute 'maxOccurs' is not declared for element 'xs:element' metalink.xsd:9:41 error: Unknown element 'xs:complexType' metalink.xsd:9:41 error: Attribute 'name' is not declared for element 'xs:complexType' ... What's gone wrong here? Anyway, how can I rename the anonymous types with useful names other than counted version1 (or hash1 by use of xsd 3.0.0b2)? Thanks Olaf From boris at codesynthesis.com Sun Jul 22 02:57:18 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <46A24376.90408@gmx.de> References: <46A24376.90408@gmx.de> Message-ID: <20070722065718.GA31233@karelia> Hi Olaf, ope writes: > I build a tree parser for the metalink schema at > http://www.metalinker.org/schema/3.0/metalink.xsd by: > > [...] > > and get a lot of errors: > > > metalink.xsd:2:216 error: Unknown element 'xs:schema' Are you getting these errors when running XSD or your application? If it is your application then it is not clear why you are parsing the schema itself (metalink.xsd). I would expect you to try it on some XML document of the metalink vocabulary. > Anyway, how can I rename the anonymous types with useful names other > than counted version1 (or hash1 by use of xsd 3.0.0b2)? Use the --anonymous-regex option. For details see the XSD Compiler Command Line Manual: http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml and FAQ 1.1: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#1.1 hth, -boris From tmaenner at aehr.com Fri Jul 20 20:56:25 2007 From: tmaenner at aehr.com (Thomas Maenner) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Compressing XML file on the fly Message-ID: <200707201756.25953.tmaenner@aehr.com> Hi Guys, is there a way to write the XML data in memory compressed into a file? Rather than write the file and then compress / bzip2 it? Thanks for any suggestions / ideas Tom -- Thomas Maenner E-Mail: mailto:tmaenner@aehr.com From boris at codesynthesis.com Sun Jul 22 03:26:43 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Compressing XML file on the fly In-Reply-To: <200707201756.25953.tmaenner@aehr.com> References: <200707201756.25953.tmaenner@aehr.com> Message-ID: <20070722072643.GB31233@karelia> Hi Thomas, Thomas Maenner writes: > is there a way to write the XML data in memory compressed into a file? > Rather than write the file and then compress / bzip2 it? One way would be to use the serialization function that writes to std::ostream together with a compressing stream from the Boost Iostreams library: http://www.boost.org/libs/iostreams/doc/index.html Alternatively you could customize the ofstream/basic_filebuf to compress the data before writing it to a file (e.g., by overriding the overflow() function). hth, -boris From ope-devel at gmx.de Sun Jul 22 07:59:57 2007 From: ope-devel at gmx.de (ope) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <20070722065718.GA31233@karelia> References: <46A24376.90408@gmx.de> <20070722065718.GA31233@karelia> Message-ID: <46A346BD.50103@gmx.de> >> I build a tree parser for the metalink schema at >> http://www.metalinker.org/schema/3.0/metalink.xsd by: >> >> [...] >> >> and get a lot of errors: >> >> >> metalink.xsd:2:216 error: Unknown element 'xs:schema' > > Are you getting these errors when running XSD or your application? > If it is your application then it is not clear why you are parsing > the schema itself (metalink.xsd). I would expect you to try it on > some XML document of the metalink vocabulary. I'm using my application, e.g. $ ./bin/app -f /var/tmp/curl.metalink Metalink Files are: /var/tmp/curl.metalink /var/tmp/curl.metalink:3:60 error: Unknown element 'metalink' /var/tmp/curl.metalink:3:60 error: Attribute 'version' is not declared for element 'metalink' /var/tmp/curl.metalink:3:60 error: Attribute 'generator' is not declared for element 'metalink' /var/tmp/curl.metalink:3:60 error: Attribute 'xmlns' is not declared for element 'metalink' /var/tmp/curl.metalink:3:60 error: Attribute 'type' is not declared for element 'metalink' /var/tmp/curl.metalink:3:60 error: Attribute 'refreshdate' is not declared for element 'metalink' /var/tmp/curl.metalink:4:12 error: Unknown element 'publisher' /var/tmp/curl.metalink:5:7 error: Unknown element 'name' /var/tmp/curl.metalink:6:6 error: Unknown element 'url' /var/tmp/curl.metalink:8:14 error: Unknown element 'description' /var/tmp/curl.metalink:9:8 error: Unknown element 'files' /var/tmp/curl.metalink:9:40 error: Unknown element 'file' /var/tmp/curl.metalink:9:40 error: Attribute 'name' is not declared for element 'file' /var/tmp/curl.metalink:10:10 error: Unknown element 'version' [...] $ cat /var/tmp/curl.metalink curl http://curl.haxx.se/ curl Generic source tar, gzip 7.16.4 2127522 b8f272cfe98fd5570447469e2faea844 9c0c64061e41fa49f2a3fb1cb5334303d49f425b -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGk+mGeOEcayedXJERAlePAJ9eR6VlBzdZHvzquiRQu70GSIwZdQCeIFA4 J+7PsoXJwIZvrMSS6/lih0o= =qYpL -----END PGP SIGNATURE----- ftp://ftp.planetmirror.com/pub/curl/curl-7.16.4.tar.gz http://gd.tuwien.ac.at/utils/archivers/curl/curl-7.16.4.tar.gz [...] Creating of xsd's header and source using the options mentioned before doesn't result in any errors. >> Anyway, how can I rename the anonymous types with useful names other >> than counted version1 (or hash1 by use of xsd 3.0.0b2)? > > Use the --anonymous-regex option. For details see the XSD Compiler > Command Line Manual: > > http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml > > and FAQ 1.1: > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#1.1 I will try it. Thanks, Olaf From boris at codesynthesis.com Sun Jul 22 08:39:47 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <46A346BD.50103@gmx.de> References: <46A24376.90408@gmx.de> <20070722065718.GA31233@karelia> <46A346BD.50103@gmx.de> Message-ID: <20070722123947.GD31233@karelia> Hi Olaf, ope writes: > I'm using my application, e.g. > > $ ./bin/app -f /var/tmp/curl.metalink > Metalink Files are: /var/tmp/curl.metalink > /var/tmp/curl.metalink:3:60 error: Unknown element 'metalink' > /var/tmp/curl.metalink:3:60 error: Attribute 'version' is not declared > for element 'metalink' > > [...] > > $ cat /var/tmp/curl.metalink > > xmlns="http://www.metalinker.org/" > type="dynamic" refreshdate="Sun, 22 Jul 2007 11:30:07 GMT"> You get these errors because XML Schema validation is enabled by default and the parser cannot find the schema since none is specified in the instance or elsewhere. You have three options: 1. Disable validation. 2. Add schemaLocation attributes to your XML documents. 3. Programmatically specify the schema location. These options are discussed in more detail in Section 2, "Validaion and Parsing" of the FAQ: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#2 hth, -boris From uri at hyperroll.com Sun Jul 22 10:10:04 2007 From: uri at hyperroll.com (Uri Karagila) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] include one xml file in another Message-ID: <783879783B65E44995520FEF376C453815897D@ilexch1.int.hyperroll.com> Hi, Is there a way (supported by code-synthesis) to include one xml file in another? Regards Uri From boris at codesynthesis.com Sun Jul 22 11:06:03 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] include one xml file in another In-Reply-To: <783879783B65E44995520FEF376C453815897D@ilexch1.int.hyperroll.com> References: <783879783B65E44995520FEF376C453815897D@ilexch1.int.hyperroll.com> Message-ID: <20070722150603.GE31233@karelia> Hi Uri, Uri Karagila writes: > Is there a way (supported by code-synthesis) to include one xml file in > another? XSD does not directly support XML document partitioning and inclusion. There are, however, many ways you can achieve this yourself. One way would be to resolve all references at the DOM level and feed the assembled DOMDocument to one of the generated parsing functions. Alternatively you can use type customization to resolve fragments during parsing (in a way similar to the custom/wildcard example). hth, -boris From ope-devel at gmx.de Mon Jul 23 15:00:38 2007 From: ope-devel at gmx.de (ope) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <20070722123947.GD31233@karelia> References: <46A24376.90408@gmx.de> <20070722065718.GA31233@karelia> <46A346BD.50103@gmx.de> <20070722123947.GD31233@karelia> Message-ID: <46A4FAD6.9080702@gmx.de> Hi Boris, > You get these errors because XML Schema validation is enabled by > default and the parser cannot find the schema since none is > specified in the instance or elsewhere. You have three options: > > 1. Disable validation. > > 2. Add schemaLocation attributes to your XML documents. > > 3. Programmatically specify the schema location. > > These options are discussed in more detail in Section 2, "Validaion > and Parsing" of the FAQ: > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#2 I did try the 3rd Option without success. ---8<--- class metalink_parser { private: typedef std::vector metalink_files_t; public: metalink_parser(); metalink_parser(const std::string& file); public: void append(const std::string& file); void load(); private: metalink_files_t m_metalink_files; std::auto_ptr m_metalink; xml_schema::properties m_metalink_props; }; ---8<--- metalink_parser::metalink_parser() { m_metalink_props.schema_location ( "http://www.metalinker.org/", "file:///home/ope/Projects/cpp/test/schema/metalink.xsd"); m_metalink_props.no_namespace_schema_location ( "file:///home/ope/Projects/cpp/test/schema/metalink.xsd"); } metalink_parser::metalink_parser(const std::string& file){ m_metalink_files.push_back(file); } void metalink_parser::append(const std::string& file) { m_metalink_files.push_back(file); } void metalink_parser::load() { assert(m_metalink.get() == 0); // TODO: a lot of checks const std::string metalink_file = m_metalink_files.front(); try { // take ownership //m_metalink = metalink::metalink(metalink_file, xml_schema::flags::dont_validate); m_metalink = metalink::metalink(metalink_file, 0, m_metalink_props); metalink::filesType::file::const_iterator first(m_metalink->files().file().begin()); metalink::filesType::file::const_iterator last(m_metalink->files().file().begin()); for (; first != last; ++first) { cout << *first; } } catch (const xml_schema::exception& e) { cerr << e << endl; } } --->8--- If I disable validation (1st Option) no output is performed. As you may see, these are my first steps in Xerces and XSD. Thanks Olaf From Ryan.Prather at afspc.af.mil Mon Jul 23 13:02:15 2007 From: Ryan.Prather at afspc.af.mil (Prather, Ryan C SSgt DMSG/WMTS) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] File Closing In-Reply-To: <20070716161015.GB4399@karelia> References: <20070716161015.GB4399@karelia> Message-ID: Ok, Boris, that seemed to work great. Like you were mentioning we are getting a validation error now. "Test.xml:1:1 Invalid Document Structure" I think that fix that you offered would fix it. Thanks. Ryan -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, July 16, 2007 10:10 AM To: Prather, Ryan C SSgt DMSG/WMTS Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] File Closing Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Is xsd/xerces thread-safe? Yes but you need to make sure the Xerces-C++ runtime if initialized and terminated only once. The easies way to do this is to initialize/terminate Xerces-C++ from main() when there aren't any threads yet/anymore: #include int main () { xercesc::XMLPlatformUtils::Initialize (); { // Start threads and parse here. } xercesc::XMLPlatformUtils::Terminate (); } Because you initialize the runtime yourself you should also pass the xml_schema::flags::dont_initialize flag to the parse() function: xml_schema::document doc_p (...); doc_p.parse ("test.xml", xml_schema::flags::dont_initialize); > 2. We are getting an error "Type XMLPlatformException, message: Could > not close the file", does xsd use a static or dynamic file handle to > reading the files? When and where is the file closed? In this case the file opening and closing is performed by Xerces-C++ and there appears to be a bug that is fixed for the next version of Xerces-C++: https://issues.apache.org/jira/browse/XERCESC-1658 This problem only occurs on Solaris, right? > Would there be a way that I can call the file closer to close the file > within say the post of the root tag? If you don't use XML Schema validation in Xerces-C++ then you can handle file opening/closing yourself and pass an std::istream to the parse() function instead of a file name: #include std::ifstream ifs ("test.xml"); if (!ifs.open ()) { // could not open } ... doc_p.parse (ifs, "test.xml", xml_schema::flags::dont_initialize); ... ifs.close (); If you do use XML Schema validation, then this method may not work because Xerces-C++ will still be opening the schema files. For this situation I can extract the fix from Xerces-C++ SVN and send it to you. hth, -boris From boris at codesynthesis.com Mon Jul 23 16:46:18 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] File Closing In-Reply-To: References: <20070716161015.GB4399@karelia> Message-ID: <20070723204618.GA4445@karelia> Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Ok, Boris, that seemed to work great. Like you were mentioning we are > getting a validation error now. > > "Test.xml:1:1 Invalid Document Structure" Hm, this does not look like a schema validation error but rather like the result of XML well-formedness checking. Does this only happen on Solaris? > I think that fix that you offered would fix it. I guess it is worth a try. The patch is available here: http://www.codesynthesis.com/~boris/tmp/xerces-c-2.7.0-1658.patch Let me know if this still does not work. -boris From boris at codesynthesis.com Mon Jul 23 16:54:57 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <46A4FAD6.9080702@gmx.de> References: <46A24376.90408@gmx.de> <20070722065718.GA31233@karelia> <46A346BD.50103@gmx.de> <20070722123947.GD31233@karelia> <46A4FAD6.9080702@gmx.de> Message-ID: <20070723205457.GB4445@karelia> Hi Olaf, ope writes: > I did try the 3rd Option without success. What exactly happens? Do you still get validation errors? > metalink_parser::metalink_parser() { > m_metalink_props.schema_location ( > "http://www.metalinker.org/", > "file:///home/ope/Projects/cpp/test/schema/metalink.xsd"); > > m_metalink_props.no_namespace_schema_location ( > "file:///home/ope/Projects/cpp/test/schema/metalink.xsd"); > } The no_namespace_schema_location call is not necessary since your schema has a namespace. > metalink_parser::metalink_parser(const std::string& file){ > m_metalink_files.push_back(file); > } This c-tor does not initialize m_metalink_props. If you are using this c-tor to create a metalink_parser object then this would explain why things still do not work. > If I disable validation (1st Option) no output is performed. You mean there is no errors or you don't get the output that you expected? If none of the above help, could you send a complete test driver, including code that instantiates metalink_parser, so that I can take a look. hth, -boris From boris at codesynthesis.com Tue Jul 24 02:39:09 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] File Closing In-Reply-To: References: <20070716161015.GB4399@karelia> <20070723204618.GA4445@karelia> Message-ID: <20070724063909.GA5849@karelia> Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Right now yes, Solaris is our primary development environment because we > know that is the platform we are deploying too. Initally I thought that > it was a syntax error as well, but I looked and didn't see anything that > was wrong. I haven't changed the .xml or schema files recently and they > were working fine. We made the changes that you suggested to allow > threading and that is what changed the error from "Type > XMLPlatformException, message: Could not close the file" to the "Invalid > document structure." Have you changed anything else in the way you call parsing functions besides calling Initialize/Terminate and passing the dont_initialize flag? Maybe you used ifstream instead of just passing the file name, as I suggested in one of my previous emails? > Do I need to make any changes to the .hpp files in addition to the .cpp > files? No, the changes are only to BinFileOuputStream.cpp and BinFileInputStream.cpp. I extracted this changes from the Xerces-C++ SVN repository, revision 450540, as suggested in the bug report. hth, -boris From Ryan.Prather at afspc.af.mil Mon Jul 23 17:04:20 2007 From: Ryan.Prather at afspc.af.mil (Prather, Ryan C SSgt DMSG/WMTS) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] File Closing In-Reply-To: <20070723204618.GA4445@karelia> References: <20070716161015.GB4399@karelia> <20070723204618.GA4445@karelia> Message-ID: Right now yes, Solaris is our primary development environment because we know that is the platform we are deploying too. Initally I thought that it was a syntax error as well, but I looked and didn't see anything that was wrong. I haven't changed the .xml or schema files recently and they were working fine. We made the changes that you suggested to allow threading and that is what changed the error from "Type XMLPlatformException, message: Could not close the file" to the "Invalid document structure." Do I need to make any changes to the .hpp files in addition to the .cpp files? Thanks. -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, July 23, 2007 2:46 PM To: Prather, Ryan C SSgt DMSG/WMTS Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] File Closing Hi Ryan, Prather, Ryan C SSgt DMSG/WMTS writes: > Ok, Boris, that seemed to work great. Like you were mentioning we are > getting a validation error now. > > "Test.xml:1:1 Invalid Document Structure" Hm, this does not look like a schema validation error but rather like the result of XML well-formedness checking. Does this only happen on Solaris? > I think that fix that you offered would fix it. I guess it is worth a try. The patch is available here: http://www.codesynthesis.com/~boris/tmp/xerces-c-2.7.0-1658.patch Let me know if this still does not work. -boris From ope-devel at gmx.de Tue Jul 24 12:41:24 2007 From: ope-devel at gmx.de (ope) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <20070723205457.GB4445@karelia> References: <46A24376.90408@gmx.de> <20070722065718.GA31233@karelia> <46A346BD.50103@gmx.de> <20070722123947.GD31233@karelia> <46A4FAD6.9080702@gmx.de> <20070723205457.GB4445@karelia> Message-ID: <46A62BB4.4080404@gmx.de> >> metalink_parser::metalink_parser(const std::string& file){ >> m_metalink_files.push_back(file); >> } > > This c-tor does not initialize m_metalink_props. If you are > using this c-tor to create a metalink_parser object then > this would explain why things still do not work. Oh dear, you are so right. shame ... >> If I disable validation (1st Option) no output is performed. > > You mean there is no errors or you don't get the output that > you expected? I get no output. > If none of the above help, could you send a complete test driver, > including code that instantiates metalink_parser, so that I can > take a look. Well, here we are. $ g++ -DDRIVER -I. metalink_parser.cpp metalink.cpp -o metalink -lxerces-c $ ./metalink ./curl.metalink load ./curl.metalink That's all. I would expect "curl-7.16.4.tar.gz" Thanks, Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: curl.metalink Type: text/xml Size: 5447 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070724/9e3c1f92/curl.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: metalink.cpp Type: text/x-c++src Size: 141453 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070724/9e3c1f92/metalink.cpp -------------- next part -------------- A non-text attachment was scrubbed... Name: metalink.hpp Type: text/x-c++hdr Size: 74946 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070724/9e3c1f92/metalink.hpp -------------- next part -------------- A non-text attachment was scrubbed... Name: metalink.xsd Type: text/xml Size: 11335 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070724/9e3c1f92/metalink.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: metalink_parser.hpp Type: text/x-c++hdr Size: 971 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070724/9e3c1f92/metalink_parser.hpp -------------- next part -------------- A non-text attachment was scrubbed... Name: metalink_parser.cpp Type: text/x-c++src Size: 2097 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070724/9e3c1f92/metalink_parser.cpp From boris at codesynthesis.com Tue Jul 24 13:29:10 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <46A62BB4.4080404@gmx.de> References: <46A24376.90408@gmx.de> <20070722065718.GA31233@karelia> <46A346BD.50103@gmx.de> <20070722123947.GD31233@karelia> <46A4FAD6.9080702@gmx.de> <20070723205457.GB4445@karelia> <46A62BB4.4080404@gmx.de> Message-ID: <20070724172910.GB7254@karelia> Hi Olaf, In the future please do not send the generated code if you are also sending the schema. ope writes: > metalink::filesType::file::const_iterator first(m_metalink->files().file().begin()); > metalink::filesType::file::const_iterator last(m_metalink->files().file().begin()); I think the second call should be to end(). After this fix I see a lot of data in stdout. hth, -boris From ope-devel at gmx.de Tue Jul 24 14:13:00 2007 From: ope-devel at gmx.de (ope) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Problems with generated schema In-Reply-To: <20070724172910.GB7254@karelia> References: <46A24376.90408@gmx.de> <20070722065718.GA31233@karelia> <46A346BD.50103@gmx.de> <20070722123947.GD31233@karelia> <46A4FAD6.9080702@gmx.de> <20070723205457.GB4445@karelia> <46A62BB4.4080404@gmx.de> <20070724172910.GB7254@karelia> Message-ID: <46A6412C.8000707@gmx.de> > In the future please do not send the generated code if you are > also sending the schema. OK >> metalink::filesType::file::const_iterator first(m_metalink->files().file().begin()); >> metalink::filesType::file::const_iterator last(m_metalink->files().file().begin()); > > I think the second call should be to end(). After this fix I see a lot of > data in stdout. Oh dear, only stupid failures, Sorry. Thanks Olaf From jamesfrullo at gmail.com Tue Jul 24 17:16:44 2007 From: jamesfrullo at gmail.com (James Frullo) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Bug in ACE CDR deserialization Message-ID: <9bda00db0707241416s4490051ate80d0ab711fcf656@mail.gmail.com> I just downloaded the latest stable release of xsd (2.3.1), and I tried compiling and running the "binary" sample under the examples/cxx/tree/binary directory. I built ACE by linking to the Multi-threaded Debug DLL version of the CRT, but I built the sample using the plain Multi-threaded Debug version. This brought out a non-obvious bug in the implementation of the following function: inline istream& operator>> (istream& s, std::basic_string& x) This function has the following implementation: ACE_CDR::Char* r; if (!s.impl ().read_string (r)) throw ace_cdr_stream_extraction (); auto_array ar (r); x = r; return s; The problem with this is that calling read_string() gives you memory allocated by ACE. But auto_array is going to deallocate that memory by calling delete[]. Since ACE is compiled and linked separately, it is incorrect to assume that this will work. In fact, it does not work. It crashes because using the build configurations I mentioned above. The correct code would be something like: ACE_CDR::Char* r; if (!s.impl ().read_string (r)) throw ace_cdr_stream_extraction (); try {x = r} catch(...){ACE::strdelete(r);throw;} ACE::strdelete(r); return s; Of course, this is ugly. A nicer way would be to have an ace_auto_str() class (or whatever). ~James From boris at codesynthesis.com Wed Jul 25 06:26:55 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Bug in ACE CDR deserialization In-Reply-To: <9bda00db0707241416s4490051ate80d0ab711fcf656@mail.gmail.com> References: <9bda00db0707241416s4490051ate80d0ab711fcf656@mail.gmail.com> Message-ID: <20070725102655.GC7705@karelia> Hi James, James Frullo writes: > I built ACE by linking to the Multi-threaded Debug DLL version > of the CRT, but I built the sample using the plain Multi-threaded Debug > version. This brought out a non-obvious bug in the implementation of the > following function: > inline istream& operator>> (istream& s, > std::basic_string& x) This is really a bug in the Windows DLL model, not in the above function. I don't think it will be fixed any type soon, though ;-). > The problem with this is that calling read_string() gives you memory > allocated by ACE. But auto_array is going to deallocate that memory by > calling delete[]. Since ACE is compiled and linked separately, it is > incorrect to assume that this will work. In fact, it does not work. It > crashes because using the build configurations I mentioned above. The > correct code would be something like: > > ACE_CDR::Char* r; > > if (!s.impl ().read_string (r)) > throw ace_cdr_stream_extraction (); > > try {x = r} catch(...){ACE::strdelete(r);throw;} > ACE::strdelete(r); > > return s; > > Of course, this is ugly. A nicer way would be to have an ace_auto_str() > class (or whatever). It is not just ugly, it simply won't work because there is no strdelete or anything similar that I am aware of. ACE CDR code uses new[] to allocate the memory and delete[] to free it. There is no wrapper to call "ACE's version of delete[]". The only way to make it work (aside from linking your application with the DLL version of the runtime) is to handle string serialization ourselves which would require copying quite a bit of implementation details from ACE to the above function. This is a bad idea in itself because that code can change in the future. Furthermore, the code that handles wchar_t serialization (that would need to be copied as well) is really messy and has various branches for different versions of GIOP. I really don't think it is a good idea to drag it into XSD. I will think some more about other possible ways to fix this. If you have any ideas, let me know. And thanks for reporting this! -boris From jamesfrullo at gmail.com Wed Jul 25 10:39:20 2007 From: jamesfrullo at gmail.com (James Frullo) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Bug in ACE CDR deserialization In-Reply-To: <20070725102655.GC7705@karelia> References: <9bda00db0707241416s4490051ate80d0ab711fcf656@mail.gmail.com> <20070725102655.GC7705@karelia> Message-ID: <9bda00db0707250739y4a6c5948g1fa602768b4bd86f@mail.gmail.com> Hi Boris. Actually, the function ACE::strdelete() does exist; it's not something I just made up. In C++ Network Programming, Volume 2, Schmidt explains the need for it. You can find that explanation here: http://www.mamiyami.com/document/cpp_network_prog_volume2/0201795256_ch05lev1sec2.html Look for "Sidebar 29: Portable Heap Operations with ACE". Calling ACE::strdelete() in line like that is certainly ugly. That's why I suggested adding a special auto ptr class for ACE strings, like this: template struct auto_ACE_str { auto_ACE_str(X a[]) : a_(a) {} ~auto_ACE_str() {ACE::strdelete(a_);} private: X *a_; }; This still isn't as elegant as the current implementation, but it has the advantage of working portably. By the way, this is a great feature to be able to do binary serialization. This makes the tool much more useful. ~James On 7/25/07, Boris Kolpackov wrote: > > Hi James, > > James Frullo writes: > > > I built ACE by linking to the Multi-threaded Debug DLL version > > of the CRT, but I built the sample using the plain Multi-threaded Debug > > version. This brought out a non-obvious bug in the implementation of > the > > following function: > > inline istream& operator>> (istream& s, > > std::basic_string& x) > > This is really a bug in the Windows DLL model, not in the above > function. I don't think it will be fixed any type soon, though ;-). > > > > The problem with this is that calling read_string() gives you memory > > allocated by ACE. But auto_array is going to deallocate that memory by > > calling delete[]. Since ACE is compiled and linked separately, it is > > incorrect to assume that this will work. In fact, it does not work. It > > crashes because using the build configurations I mentioned above. The > > correct code would be something like: > > > > ACE_CDR::Char* r; > > > > if (!s.impl ().read_string (r)) > > throw ace_cdr_stream_extraction (); > > > > try {x = r} catch(...){ACE::strdelete(r);throw;} > > ACE::strdelete(r); > > > > return s; > > > > Of course, this is ugly. A nicer way would be to have an ace_auto_str() > > class (or whatever). > > It is not just ugly, it simply won't work because there is no strdelete > or anything similar that I am aware of. ACE CDR code uses new[] to > allocate the memory and delete[] to free it. There is no wrapper to > call "ACE's version of delete[]". The only way to make it work (aside > from linking your application with the DLL version of the runtime) is > to handle string serialization ourselves which would require copying > quite a bit of implementation details from ACE to the above function. > This is a bad idea in itself because that code can change in the future. > Furthermore, the code that handles wchar_t serialization (that would > need to be copied as well) is really messy and has various branches > for different versions of GIOP. I really don't think it is a good idea > to drag it into XSD. > > I will think some more about other possible ways to fix this. If you > have any ideas, let me know. And thanks for reporting this! > > > -boris > From boris at codesynthesis.com Wed Jul 25 11:22:29 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] Bug in ACE CDR deserialization In-Reply-To: <9bda00db0707250739y4a6c5948g1fa602768b4bd86f@mail.gmail.com> References: <9bda00db0707241416s4490051ate80d0ab711fcf656@mail.gmail.com> <20070725102655.GC7705@karelia> <9bda00db0707250739y4a6c5948g1fa602768b4bd86f@mail.gmail.com> Message-ID: <20070725152229.GA9551@karelia> Hi James, James Frullo writes: > Hi Boris. Actually, the function ACE::strdelete() does exist; it's not > something I just made up. I stand corrected. It is strange I couldn't find it in the ACE source code earlier today. > Calling ACE::strdelete() in line like that is certainly ugly. That's why I > suggested adding a special auto ptr class for ACE strings, like this: Actually, this is not necessary: auto_array allows you to provide a custom deallocator object. I've made the necessary changes in ace-cdr-stream-extraction.hxx. The relevant part is attached at the end of this email. Pleas let me know if it does not fix your problem. > By the way, this is a great feature to be able to do binary serialization. > This makes the tool much more useful. Thanks, I am glad you find it useful. BTW, we have implemented support for serializing to XDR for the next release. The also works with 2.3.1. Let me know if you would like to try it. thanks, -boris // Extraction of std::basic_string. // namespace bits { template struct ace_str_deallocator { void deallocate (C* s) { ACE::strdelete (s); } }; } inline istream& operator>> (istream& s, std::basic_string& x) { typedef bits::ace_str_deallocator deallocator; deallocator d; char* r; if (!s.impl ().read_string (r)) throw ace_cdr_stream_extraction (); auto_array ar (r, d); x = r; return s; } inline istream& operator>> (istream& s, std::basic_string& x) { typedef bits::ace_str_deallocator deallocator; deallocator d; wchar_t* r; if (!s.impl ().read_wstring (r)) throw ace_cdr_stream_extraction (); auto_array ar (r, d); x = r; return s; } From Michael.Caruso at itt.com Thu Jul 26 09:46:19 2007 From: Michael.Caruso at itt.com (Caruso, Michael - AES) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] XML Writing Message-ID: <7DB20341F654384C8541A8E2FF63CCD702783330@01HRNMX09-1.aes.de.ittind.com> Hi, Is there a method for parsing in XML data using the cxx-tree mode and then modifying some values and writing it out? Or any method for output at all in XSD? Thanks, Mike ***************************************************************** This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail. ******************************************************************* From boris at codesynthesis.com Thu Jul 26 10:19:04 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:57 2009 Subject: [xsd-users] XML Writing In-Reply-To: <7DB20341F654384C8541A8E2FF63CCD702783330@01HRNMX09-1.aes.de.ittind.com> References: <7DB20341F654384C8541A8E2FF63CCD702783330@01HRNMX09-1.aes.de.ittind.com> Message-ID: <20070726141904.GA4045@karelia> Hi Michael, > Is there a method for parsing in XML data using the cxx-tree mode and > then modifying some values and writing it out? Or any method for output > at all in XSD? Sure, please see the library example in the examples/cxx/tree/ directory as well as Chapter 4, "Serialization" in the C++/Tree Mapping User Manual: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#4 BTW, it is also possible to parse/serialize the data from/to formats other than XML, e.g., text (useful for debugging), as well as binary formats such as CDR and XDR. hth, -boris