From boris at codesynthesis.com Mon Oct 3 07:06:02 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd 1.4.0 released Message-ID: <20051003110602.GB21322@karelia> Good day, We've released xsd 1.4.0. The NEWS file entries for this version are as follows: * Number of improvements and bug fixes in the diagnostics code. * libxsd has been reorganized to provide a clean split of code with regards to char/wchar_t use. It should be possible to use libxsd and the xsd-generated code on platforms that lack wchar_t support, such as mingw. cxx-tree * Work around for g++ bug# 23206. * Support for xsd:list. * Type/member name conflicts are auto-resolved. Such conflicts occur when a type and an element or attribute withing this type share the same name. * XML Schema extension, the 'refType' attribute, allows one to specify referenced type for xsd:IDREF and xsd:IDREFS data types. See examples/cxx/tree/library for details. * New option, --morph-anonymous, allows automatic morphing of anonymous types to named ones. See the man pages for details. * New option, --namespace-regex-trace, allows one to trace the namespace mapping process. See the man pages for details. * Mapping for optional elements/attributes (cardinality 0..1) has changed in a backwards-incompatible way. In the previous version you would write: Bar& bar = ... if (bar.foo.present ()) // test { Foo& foo (bar.foo ()); // get bar.foo (Foo (...)); // set bar.foo.reset (); // reset } Now you would write it like this: if (bar.foo ().present ()) // test { Foo& foo (bar.foo ().get ()); // get bar.foo (Foo (...)); // set bar.foo ().reset (); // reset } Or using the pointer notation: if (bar.foo ()) // test { Foo& foo (*bar.foo ()); // get bar.foo (Foo (...)); // set bar.foo ().reset (); // reset } cxx-parser * Support for xsd:list. * Type/member name conflicts are auto-resolved. Such conflicts occur when a type and an element or attribute withing this type share the same name. * New option, --namespace-regex-trace, allows one to trace the namespace mapping process. See the man pages for details. Precompiled binary distributions for various platforms are available from the product's web page: http://codesynthesis.com/products/xsd/ Source code for this release is available from the project's web page: http://codesynthesis.com/projects/xsd/ SHA1 checksums for the files: 67651515eb89500729100081a972e5e2bae1deda xsd-1.4.0.tar.bz2 00f96bd462b40d04fa7eb49c1c05ddbe294ef104 xsd_1.4.0-1_i386.deb 308b6aba78e00f752d0c5d385eaac3e70335138e xsd-1.4.0-1.i686.rpm 3affb5e2698df31b5b5ff852683cf697ad60f0be xsd-1.4.0-i686-linux-gnu.tar.bz2 2760bb87beb61c36f116e9197b950ef78cad6747 xsd_1.4.0-1_amd64.deb b51eda335712200931eabcd21ee7da07ea810587 xsd-1.4.0-1.x86_64.rpm 7272a9662834ae0a7bf3a4062c14d12c9bc9b370 xsd-1.4.0-x86_64-linux-gnu.tar.bz2 9310adbae40c3fa65f592e95f02f4068caa27e3c xsd-1.4.0-powerpc-macosx.tar.bz2 f8878f17a8358abe7c3444ec4d91210c2665f7f8 xsd-1.4.0-i686-windows.zip have fun, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051003/974d4655/attachment.pgp From boris at codesynthesis.com Wed Oct 5 14:57:09 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] XML Schema Authoring Guide Message-ID: <20051005185709.GA28915@karelia> Good day, We just added an XML Schema Authoring Guide which you can view at http://codesynthesis.com/projects/xsd/documentation/schema-authoring-guide.xhtml From the Introduction section of the guide: "Making it possible to cleanly map W3C XML Schema to programming languages was never a goal of the XML Schema design committee. As a result there is a number of Schema constructs, techniques, and styles that don't have appropriate counterparts in C++. This document presents a list of do's and don'ts that will help ensure your schemas, when translated by xsd, result in C++ code that is enjoyable to work with." hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051005/8e436d5f/attachment.pgp From boris at codesynthesis.com Fri Oct 7 06:16:50 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] plans for xsd 1.5.0 Message-ID: <20051007101650.GA4440@karelia> Good day, We are planning to make the following user-visible changes in xsd 1.5.0 which is to be released around Oct 19. Your feedback on the proposed changes/new features is always appreciated. * Workaround for g++-3.3 bug# 16650. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16650 * Flags for parsing functions: initialize, validate, keep_dom, free_dom. When the keep_dom flag is passed, one will be able to access underlying DOM elements/attributes from which any given instance is instantiated. * Support for xsd:anyType/xsd:anySimpleType, xsd:any/xsd:anyAttribute, and mixed content via exposing corresponding raw DOM sub-trees. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051007/644557e7/attachment.pgp From graham-xsd at simulcra.org Sun Oct 9 18:21:59 2005 From: graham-xsd at simulcra.org (Graham Bennett) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd questions Message-ID: <20051009222159.GB21143@lamity.org> Hi, I'm evaluating xsd and I have a couple of questions: It seems that the generated code parses instance documents with xerces validation enabled. Is it possible to disable this, which would remove the overhead of validation for each instance document, or is the code making assumptions that the document is always valid? Other implementations I have seen generate a 'perfect parser' for the document, which means the elements expected at each stage are hard coded in the generated code and an exception will be thrown if anything else is encountered. The second question is a side-effect of the behaviour described above. In my environment we rarely specify schema location via the schemaLocation attribute in the instance document, but instead prefer to specify it externally on the parser (e.g. Xerces setSchemaLocation). Is there a way to get xsd to make the generated code 'remember' the schema location and set it on the parser when creating instances? Alternatively is there a way to get at the xerces internals to set it manually? Thanks in advance, Graham. -- Graham Bennett From boris at codesynthesis.com Mon Oct 10 03:40:55 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd questions In-Reply-To: <20051009222159.GB21143@lamity.org> References: <20051009222159.GB21143@lamity.org> Message-ID: <20051010074055.GA12514@karelia> Graham, Graham Bennett writes: > It seems that the generated code parses instance documents with xerces > validation enabled. Is it possible to disable this, which would remove > the overhead of validation for each instance document, Not yet, but I am planning to add such a flag in the next version (due in a week or so). > or is the code making assumptions that the document is always valid? > Other implementations I have seen generate a 'perfect parser' for the > document, which means the elements expected at each stage are hard coded > in the generated code and an exception will be thrown if anything else > is encountered. xsd does generate a schema-specific parser and it does throw if an unexpected element is encountered. I wouldn't call it a "perfect parser" because there is much more to the Schema than simply which elements are expected. I also very much doubt it that there is an implementation that covers every aspect of Schema in the generated code (imagine what the footprint alone is going to be). So to summarize: * yes, xsd expects valid documents * yes, xsd has some number of checks in the generated code that do not hurt the performance or the footprint (that's the criteria we use when deciding whether the check should be there) > The second question is a side-effect of the behaviour described above. > In my environment we rarely specify schema location via the > schemaLocation attribute in the instance document, but instead prefer to > specify it externally on the parser (e.g. Xerces setSchemaLocation). Is > there a way to get xsd to make the generated code 'remember' the schema > location and set it on the parser when creating instances? No, there is no such option. But that's an interesting idea. I think it would be better to just have an additional argument to the parsing functions that allows one to specify the schema location. > Alternatively is there a way to get at the xerces internals to set > it manually? Sure. One of the parsing functions has the following signature: name (xercesc::DOMDocument const&) which allows you to set up the instance->dom stage in any way you want. For example, you can create a parser, cache the schema (via loadGrammar), and then parse multiple documents with this parser. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051010/784f2394/attachment.pgp From jboyden at geosci.usyd.edu.au Wed Oct 12 02:25:44 2005 From: jboyden at geosci.usyd.edu.au (James Boyden) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] C++/Parser errors from GML schemas Message-ID: <20051012062543.GB3461@geosci.usyd.edu.au> Hi, I'm a programmer in a free software project which is developing scientific software to model plate tectonics. Our application will use an XML-based encoding as its "native" file format, so we have been evaluating a variety of parsers. An associate forwarded to us the most recent xsd announcement from the xmlschema-dev mailing-list. The C++/Parser mapping looks very useful to us. Firstly, I would like to commend the high quality of your software! It is a pleasure to find such a useful and well-designed C++ project. I applaud your use of the Boost libraries and your choice of an STL-based interface, I am impressed by your effective use of templates, and finally I am very appreciative of the alternative (SAX-like) approach to parsing offered by the C++/Parser mapping -- as you suggest in the C++/Parser Mapping Quick Guide [1], we already have an object model, whose structure and operation is dictated by the functionality of our software, so we would prefer to use our own data-types rather than the data-types provided by a mapping. So, I have familiarised myself with the basic operation of the C++/Parser mapping from the C++/Parser Mapping Quick Guide and the "library" example found in the directory "examples/cxx/parser/library/" of the xsd source package. After that I attempted to process an older, quite simple version of our XML schema with 'xsd cxx-parser', and several errors were reported. I was wondering if you'd be able to offer any advice or assistance. The background specifics: We are creating an "application schema" of an XML grammar called GML ("Geography Markup Language") [2][3] -- our schema imports the GML schemas, and our model extends and specialises the GML model, incorporating existing GML objects where appropriate, and building new objects on top of the GML components where necessary. GML is defined by the OGC ("Open Geospatial Consortium"), so the content of the GML schemas is outside our control. The most recent GML schemas are located online at http://schemas.opengis.net/gml/3.1.1/ , but I made a local copy (and adjusted our schema to import from this local copy instead) to avoid the "is not a valid filesystem path" errors from xsd. After that, execution of xsd generated several errors about the GML schemas, including: - "expected 'list' or 'restriction' instead of 'union'" - "mixed content model is not supported" - "expected 'group', 'choice', 'sequence' or 'element' instead of 'any'" - "expected 'extension' instead of 'restriction'" I redirected stderr to a file to log the errors; I will attach the file to this email. I will also attach a gzipped tarball of the GML schemas to save you needing to download them yourself. >From the xsd-users mailing-list archives [4], I understand that xsd does not support unions, although as I have mentioned, we cannot change the GML schemas. Would you have any suggestions about how we could resolve these various problems? Many thanks, James Boyden [1] C++/Parser Mapping Quick Guide: http://codesynthesis.com/projects/xsd/documentation/cxx/parser/quick-guide/ [2] GML - the Geography Markup Language: http://opengis.net/gml/ [3] Cover Pages: "Introduction to Geography Markup Language (GML)": http://xml.coverpages.org/ni2004-03-26-a.html#introduction [4] The xsd-users Archives: "[xsd-users] Syntax supported": http://codesynthesis.com/pipermail/xsd-users/2005-September/000043.html -- James Boyden GPlates Programmer and Keeper of the Flame, School of Geosciences, University of Sydney, Australia. "I find your lack of faith disturbing." -------------- next part -------------- /homes/geo/jboyden/gml/3.1.1/base/basicTypes.xsd:29:12: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/basicTypes.xsd:51:54: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/basicTypes.xsd:72:62: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/basicTypes.xsd:93:61: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/basicTypes.xsd:100:59: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/basicTypes.xsd:121:61: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/basicTypes.xsd:142:62: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/gmlBase.xsd:140:72: error: mixed content model is not supported /homes/geo/jboyden/gml/3.1.1/base/gmlBase.xsd:154:55: error: mixed content model is not supported /homes/geo/jboyden/gml/3.1.1/base/gmlBase.xsd:246:32: error: expected 'group', 'choice', 'sequence' or 'element' instead of 'any' /homes/geo/jboyden/gml/3.1.1/base/dictionary.xsd:41:44: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:29:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:38:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:47:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:56:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:65:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:74:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:83:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:104:41: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/measures.xsd:136:14: error: expected 'list' or 'restriction' instead of 'union' /homes/geo/jboyden/gml/3.1.1/base/feature.xsd:139:48: error: expected 'extension' instead of 'restriction' /homes/geo/jboyden/gml/3.1.1/base/dynamicFeature.xsd:74:48: error: expected 'extension' instead of 'restriction' -------------- next part -------------- A non-text attachment was scrubbed... Name: gml.tar.gz Type: application/octet-stream Size: 76024 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051012/2a557a01/gml.tar.obj From boris at codesynthesis.com Wed Oct 12 03:48:24 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] C++/Parser errors from GML schemas In-Reply-To: <20051012062543.GB3461@geosci.usyd.edu.au> References: <20051012062543.GB3461@geosci.usyd.edu.au> Message-ID: <20051012074824.GA24709@karelia> James, James Boyden writes: > Firstly, I would like to commend the high quality of your software! It is > a pleasure to find such a useful and well-designed C++ project. I applaud > your use of the Boost libraries and your choice of an STL-based interface, > I am impressed by your effective use of templates, and finally I am very > appreciative of the alternative (SAX-like) approach to parsing offered by > the C++/Parser mapping -- as you suggest in the C++/Parser Mapping Quick > Guide [1], we already have an object model, whose structure and operation > is dictated by the functionality of our software, so we would prefer to > use our own data-types rather than the data-types provided by a mapping. Thank you very much for kind words. Comments like this make us try all the harder! :-) I guess we can now move to less pleasant matters ;-). I checked the schemas you sent me (also added them to the repository of schemas we use for regression testing). They use pretty much every feature there is in XML Schema some of which, as you have discovered, are not yet supported by xsd. I can divide these unsupported features into two categories: those that we plan to support soon and those that have reasonably easy workarounds. Accidently, the first category does not have easy workarounds. I will go through them one by one below: > - "expected 'list' or 'restriction' instead of 'union'" This feature is from the second category. The workaround involves creating a "binding" copy of the schema which is "wider" than the original schema. You continue using the original schema for validation (and give it to your clients, if any) and use "binding" schema for code generation. I realize that you would prefer to not modify the GML schemas but that's the only way I can think of for now. To sweeten the deal here are some positive sides: * I assume new versions of GML schemas are not published very often so there won't be too much of a maintenance headache. * There is just a handful of places where you need to modify the schemas. * At some point xsd will support all missing features so you can stop using two copies. The workaround for union is to use a "base" type which is "wide" enough to accommodate all union members. For example, the following type from basicTypes.xsd:29 Can be changed like this for the purpose of code generation: > - "mixed content model is not supported" > - "expected 'group', 'choice', 'sequence' or 'element' instead of 'any'" These will be supported in the upcoming release (due some time next week). > - "expected 'extension' instead of 'restriction'" These will be supported in 1.6.0 due end of the month. There are also cases (found in measures.xsd) like this: Which are equivalent to - substitution groups These will be supported in 1.6.0. I am not sure whether these solutions are good enough for you but that's the best we can do. While you will probably have to wait until 1.6.0 for the whole thing to be supported (except unions), there are quite a few individual schemas that don't have any unsupported features for which you can start writing parsers. Let me know if there is anything else we can do. thanks, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051012/bc5e16ea/attachment.pgp From boris at codesynthesis.com Thu Oct 13 04:19:26 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051013081926.GA32727@karelia> Hi Pradipta, Could you please send questions like this to the xsd-users mailing list rather than to me directly. This way others who may have the same problems as you will benefit from our discussions. De, Pradipta writes: > I am on Solaris 5.9, with Xerces 2.7 and Forte 5.6 (I unfortunately do > not have the rights to change the environment), but since you did not > have a binary for Solaris, I took the windows version generated the > files and took it over to my Unix box. I have attached the xsd file, > the generated hxx, cxx and the compilation errors faced. Please have a > look. Thanks in advance for your time. The other day I was checking out how much effort it will take to support Sun C++. Apparently things are not as bad as I expected. ;-) I patched libxsd for 1.4.0 which allowed me to compile the hello example with Sun C++ 5.7 Patch 117831-02. I am attaching this .tar.gz. Could you replace stock libxsd with this one and try it on your box? Also if you are serious about using xsd on Solaris we can build a binary of the compiler for you. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: libxsd-1.4.0-1.tar.gz Type: application/octet-stream Size: 32343 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051013/83b47930/libxsd-1.4.0-1.tar.obj From jboyden at geosci.usyd.edu.au Thu Oct 13 07:45:08 2005 From: jboyden at geosci.usyd.edu.au (James Boyden) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] C++/Parser errors from GML schemas In-Reply-To: <20051012074824.GA24709@karelia> References: <20051012062543.GB3461@geosci.usyd.edu.au> <20051012074824.GA24709@karelia> Message-ID: <20051013114508.GA8265@geosci.usyd.edu.au> On Wednesday, Oct 12, Boris Kolpackov wrote: > Thank you very much for kind words. Comments like this make us try all the > harder! :-) Even if you "only" keep trying as hard as you are now, we will be happy! :-) > I can divide these unsupported features into two categories: those that > we plan to support soon and those that have reasonably easy workarounds. > Accidently, the first category does not have easy workarounds. I will > go through them one by one below: > > > - "expected 'list' or 'restriction' instead of 'union'" > > This feature is from the second category. The workaround involves > creating a "binding" copy of the schema which is "wider" than the > original schema. You continue using the original schema for > validation (and give it to your clients, if any) and use "binding" > schema for code generation. I understand. > The workaround for union is to use a "base" type which is "wide" > enough to accommodate all union members. For example, the following > type from basicTypes.xsd:29 > > > > [...] > > > > Can be changed like this for the purpose of code generation: > > > > OK, I applied these changes to my local copy in the appropriate places. > > - "expected 'extension' instead of 'restriction'" > > These will be supported in 1.6.0 due end of the month. I attempted to temporarily avoid these problems in my local copy by removing, where necessary, the smallest amount of the unsupported XML. Unfortunately, there were more instances of this problem hidden in the schemas, which didn't appear until the first instances were "fixed". As I fixed these new ones, even more appeared. Eventually I decided there were too many to fix (I spent a few hours chasing them). So, I suppose we will need to wait until the 1.6.0 release before we can evaluate xsd further. > I am not sure whether these solutions are good enough for you but that's > the best we can do. While you will probably have to wait until 1.6.0 for > the whole thing to be supported (except unions), there are quite a few > individual schemas that don't have any unsupported features for which > you can start writing parsers. > > Let me know if there is anything else we can do. Thank you for your help so far; we look forward to the release of 1.6.0! Regards, James Boyden -- James Boyden GPlates Programmer and Keeper of the Flame, School of Geosciences, University of Sydney, Australia. "I find your lack of faith disturbing." From boris at codesynthesis.com Thu Oct 13 08:43:56 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] C++/Parser errors from GML schemas In-Reply-To: <20051013114508.GA8265@geosci.usyd.edu.au> References: <20051012062543.GB3461@geosci.usyd.edu.au> <20051012074824.GA24709@karelia> <20051013114508.GA8265@geosci.usyd.edu.au> Message-ID: <20051013124356.GA2023@karelia> James, James Boyden writes: > > > - "expected 'extension' instead of 'restriction'" > > > > These will be supported in 1.6.0 due end of the month. > > I attempted to temporarily avoid these problems in my local copy by > removing, where necessary, the smallest amount of the unsupported XML. > Unfortunately, there were more instances of this problem hidden in the > schemas, which didn't appear until the first instances were "fixed". As I > fixed these new ones, even more appeared. Eventually I decided there were > too many to fix (I spent a few hours chasing them). Been there, done that. > So, I suppose we will need to wait until the 1.6.0 release before we can > evaluate xsd further. For the past couple of days I was thinking about how to map inheritance by restriction to C++. I think I will be able to sneak basic support for restriction into 1.5.0 which should be out some time next week. Hopefully you will be able to make some progress then. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051013/5cac841d/attachment.pgp From jboyden at geosci.usyd.edu.au Thu Oct 13 09:12:00 2005 From: jboyden at geosci.usyd.edu.au (James Boyden) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] C++/Parser errors from GML schemas In-Reply-To: <20051013124356.GA2023@karelia> References: <20051012062543.GB3461@geosci.usyd.edu.au> <20051012074824.GA24709@karelia> <20051013114508.GA8265@geosci.usyd.edu.au> <20051013124356.GA2023@karelia> Message-ID: <20051013131200.GA23394@geosci.usyd.edu.au> On Thursday, Oct 13, Boris Kolpackov wrote: > For the past couple of days I was thinking about how to map inheritance > by restriction to C++. I think I will be able to sneak basic support for > restriction into 1.5.0 which should be out some time next week. Hopefully > you will be able to make some progress then. Thanks! I look forward to it. -- James Boyden GPlates Programmer and Keeper of the Flame, School of Geosciences, University of Sydney, Australia. "I find your lack of faith disturbing." From pde at seic.com Thu Oct 13 16:03:01 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, First of thanks for your time, here's what I did, took the files you send across 1. Generated the hxx, txx on my windows machine for parser 2. Compiled in Solaris 3. Wrote my driver, it worked like a charm 4. Generated the cxx, hxx on my windows machine for tree 5. Tried to compile the cxx in Solaris, it started bombing (Lesser errors than yesterday), attaching the error file for your reference, we are serious about using xsd on Solaris, so it would be great if you could provide a solaris based binary. Thanks & Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, October 13, 2005 4:19 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Hi Pradipta, Could you please send questions like this to the xsd-users mailing list rather than to me directly. This way others who may have the same problems as you will benefit from our discussions. De, Pradipta writes: > I am on Solaris 5.9, with Xerces 2.7 and Forte 5.6 (I unfortunately do > not have the rights to change the environment), but since you did not > have a binary for Solaris, I took the windows version generated the > files and took it over to my Unix box. I have attached the xsd file, > the generated hxx, cxx and the compilation errors faced. Please have a > look. Thanks in advance for your time. The other day I was checking out how much effort it will take to support Sun C++. Apparently things are not as bad as I expected. ;-) I patched libxsd for 1.4.0 which allowed me to compile the hello example with Sun C++ 5.7 Patch 117831-02. I am attaching this .tar.gz. Could you replace stock libxsd with this one and try it on your box? Also if you are serious about using xsd on Solaris we can build a binary of the compiler for you. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: generated_files.zip Type: application/x-zip-compressed Size: 5394 bytes Desc: generated_files.zip Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051013/67c7541e/generated_files.bin From boris at codesynthesis.com Fri Oct 14 05:19:03 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051014091903.GA8752@karelia> Pradipta, De, Pradipta writes: > 5. Tried to compile the cxx in Solaris, it started bombing > (Lesser errors than yesterday), attaching the error file for your > reference, I tried this on Sun C++ 5.7 Patch 117831-02 and it worked fine. I guess you are using an older version. What does CC -V print? I am attaching a yet another revision of libxsd that will hopefully help. Could you try it and let me know the result? > we are serious about using xsd on Solaris, so it would be great if you > could provide a solaris based binary. Ok, I will build Solaris/SPARC binary for the next release (should be out some time next week). hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: libxsd-1.4.0-2.tar.gz Type: application/octet-stream Size: 32255 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051014/ebcef93c/libxsd-1.4.0-2.tar.obj From pde at seic.com Fri Oct 14 19:30:23 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, It is now working great with the latest set of files you have given. We are using compiler version 5.6, will let you know how things progress. Why did you choose to go with struct for parser as against a class for tree? Where there any specific design considerations? Please let know when you release a version for Solaris. Thanks a lot for your time and effort in this regard. Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 14, 2005 5:19 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > 5. Tried to compile the cxx in Solaris, it started bombing > (Lesser errors than yesterday), attaching the error file for your > reference, I tried this on Sun C++ 5.7 Patch 117831-02 and it worked fine. I guess you are using an older version. What does CC -V print? I am attaching a yet another revision of libxsd that will hopefully help. Could you try it and let me know the result? > we are serious about using xsd on Solaris, so it would be great if you > could provide a solaris based binary. Ok, I will build Solaris/SPARC binary for the next release (should be out some time next week). hth, -boris From boris at codesynthesis.com Sun Oct 16 11:20:40 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051016152040.GB18869@karelia> Pradipta, De, Pradipta writes: > It is now working great with the latest set of files you have given. We > are using compiler version 5.6, will let you know how things progress. Nice to know things are working for you. > Why did you choose to go with struct for parser as against a class for > tree? Where there any specific design considerations? When the code was hand-crafted during the prototyping stage, I used struct foo: bar { instead of class foo: public bar { public: because it is shorter. I guess it doesn't matter much in the generated code. > Please let know when you release a version for Solaris. Will do. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051016/1c4f482b/attachment.pgp From boris at codesynthesis.com Mon Oct 17 06:00:55 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] C++/Parser errors from GML schemas In-Reply-To: <20051013131200.GA23394@geosci.usyd.edu.au> References: <20051012062543.GB3461@geosci.usyd.edu.au> <20051012074824.GA24709@karelia> <20051013114508.GA8265@geosci.usyd.edu.au> <20051013124356.GA2023@karelia> <20051013131200.GA23394@geosci.usyd.edu.au> Message-ID: <20051017100055.GA21814@karelia> James, I was test the in-development version of xsd against the GML schemas you sent me and found out that they are not quite valid. In this version, I decided to turn "expensive" (time and memory -wise) checks (such as unique particle attribution, etc.) on which uncovered the whole bunch of errors (see below). I checked one instance and turned out that the schema is indeed invalid. For example, here is the snippet from coordinateOperations.xsd:519: Now look at the base type definition (dictionary.xsd:35): There are two problems in this case: 1. OperationMethodBaseType should explicitly declare each element found in DefinitionType (name and description are missing). 2. We cannot add any new elements/attributes (methodName in this case) for valid OperationMethodBaseType content model should also be valid per DefinitionType. hth, -boris coverage.xsd:392:39: error: Recurse: There is not a complete functional mapping between the particles coordinateOperations.xsd:519:62: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:421:48: error: Recurse: There is not a complete functional mapping between the particles datums.xsd:27:60: error: Recurse: There is not a complete functional mapping between the particles coordinateOperations.xsd:712:70: error: Recurse: There is not a complete functional mapping between the particles coordinateOperations.xsd:28:74: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:408:37: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:283:43: error: Recurse: There is not a complete functional mapping between the particles geometryPrimitives.xsd:1294:44: error: Recurse: There is not a complete functional mapping between the particles referenceSystems.xsd:25:70: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:296:45: error: Recurse: There is not a complete functional mapping between the particles geometryPrimitives.xsd:1346:53: error: Recurse: There is not a complete functional mapping between the particles datums.xsd:383:56: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:328:47: error: Recurse: There is not a complete functional mapping between the particles geometryPrimitives.xsd:1324:52: error: Recurse: There is not a complete functional mapping between the particles datums.xsd:313:60: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:315:43: error: Recurse: There is not a complete functional mapping between the particles coordinateOperations.xsd:648:65: error: Recurse: There is not a complete functional mapping between the particles coordinateSystems.xsd:110:71: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:264:45: error: Recurse: There is not a complete functional mapping between the particles geometryPrimitives.xsd:1362:46: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:379:43: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:360:45: error: Recurse: There is not a complete functional mapping between the particles dynamicFeature.xsd:69:32: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:347:45: error: Recurse: There is not a complete functional mapping between the particles coverage.xsd:437:46: error: Recurse: There is not a complete functional mapping between the particles -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051017/0d38cf8a/attachment.pgp From jas.post at gmail.com Mon Oct 17 09:14:38 2005 From: jas.post at gmail.com (Andrey Yanukovich) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] XML validation against a schema Message-ID: <1385496258.20051017171438@gmail.com> Hi, I think schema validation is very expensive to use for every xml document processing, so i was trying to set a parser not to use a schema validation in libxsd for some time. I did the following: in file elements.txx xsd::cxx::xml::dom::auto_ptr xsd::cxx::xml::dom::dom(...) i've changed parser features from true to false in calls parser->setFeature (XMLUni::fgDOMNamespaces, true); parser->setFeature (XMLUni::fgDOMValidation, true); parser->setFeature (XMLUni::fgXercesSchemaFullChecking, true); But it caused a process break and core dump while creating a class instance from dom document. It was happened in class parser next_element () call during casting DOMNode* to DOMElement*. Could you suggest some way to switch off the shema validation or may be use preparsing schema grammar or something else in libxsd code? Kind regards, Andrey. From boris at codesynthesis.com Mon Oct 17 09:45:48 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] XML validation against a schema In-Reply-To: <1385496258.20051017171438@gmail.com> References: <1385496258.20051017171438@gmail.com> Message-ID: <20051017134548.GA26801@karelia> Andrey, Andrey Yanukovich writes: > I think schema validation is very expensive to use for every xml > document processing, You mean you did some measurements and they showed that it takes too much time -or- you simply declared so? ;-) > so i was trying to set a parser not to use a > schema validation in libxsd for some time. I did the following: > in file elements.txx > xsd::cxx::xml::dom::auto_ptr xsd::cxx::xml::dom::dom(...) > i've changed parser features from true to false in calls > parser->setFeature (XMLUni::fgDOMNamespaces, true); > parser->setFeature (XMLUni::fgDOMValidation, true); > parser->setFeature (XMLUni::fgXercesSchemaFullChecking, true); Yeah, that should turn it off. > But it caused a process break and core dump while creating a class > instance from dom document. It was happened in class parser next_element () > call during casting DOMNode* to DOMElement*. I think I know what's happening. When there is a schema, the parser can figure out which whitespaces are important and which ones are not and remove those that are not important. When you turn validation off, the parser can no longer do such whitespace cleanup so it inserts DOMText for every bunch of them (which can be somewhat expensive too, btw ;-)). The funny thing I already fixed this in libxsd/xsd/cxx/parser.hxx when I was adding support for the mixed content model. I've attached the file. > Could you suggest some way to switch off the schema validation In 1.4.0 you can hack libxsd as you did or you can use one of the parsing functions that expects DOMDocument. This way you will have to set the XML->DOM stage yourself so you can select whatever options you like. In 1.5.0 (due in a couple of days) there will be dont_validate parsing flag. Note that passing an invalid instance document to xsd-generated code when validation is turned off results in undefined behavior (read core dump). > or may be use preparsing schema grammar or something else in libxsd code? I think this is a much better idea that to switch validation completely off. If you are parsing several instance documents that use the same schema then it could be beneficial to pre-load (and pre-parse) the grammar once and then re-use this grammar every time you parse an instance document. I would think this should improve performance significantly. The only way to do it now is to set the XML->DOM stage yourself (see above) and use loadGrammar to pre-load the schemas (see Xerces-C++ docs for details). hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: parser.hxx Type: text/x-c++hdr Size: 1758 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051017/df55fa25/parser.hxx From pde at seic.com Mon Oct 17 10:44:58 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, I don't know whether I am missing something, but is there a way to do the reverse of what you are doing right now? (XML -> Class) what about (Class -> XML?), have you provided any API for the same? Please let know. Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Sunday, October 16, 2005 11:21 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > It is now working great with the latest set of files you have given. We > are using compiler version 5.6, will let you know how things progress. Nice to know things are working for you. > Why did you choose to go with struct for parser as against a class for > tree? Where there any specific design considerations? When the code was hand-crafted during the prototyping stage, I used struct foo: bar { instead of class foo: public bar { public: because it is shorter. I guess it doesn't matter much in the generated code. > Please let know when you release a version for Solaris. Will do. hth, -boris From boris at codesynthesis.com Mon Oct 17 11:42:35 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051017154235.GA28490@karelia> Pradipta, De, Pradipta writes: > I don't know whether I am missing something, but is there a way > to do the reverse of what you are doing right now? (XML -> Class) what > about (Class -> XML?), have you provided any API for the same? Sure, we call it serialization (as opposed to parsing). You can look at examples/cxx/tree/library for the code sample and at the "C++/Tree Serialization Guide" for documentation: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/serialization Also note that the serialization code is optional and you will need to specify --generate-serialization when invoking xsd. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051017/b6eb6f05/attachment.pgp From pde at seic.com Mon Oct 17 12:48:51 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, I go through the document and found that it may be very handy. But, when try to generate the code like the following way: C:\Documents and Settings\pde\Desktop\useful\codes\xsd-1.4.0-i686-windows\bin>xsd --generate-serialization xxxx_Online_Input.xsd It is thorowing me the following error: C:\Documents and Settings\pde\Desktop\useful\codes\xsd-1.4.0-i686-windows\bin>xsd --generate-serialization xxxx_Online_Input.xsd I think that is the way we ask me to generate the code. Is it the correct way to do it? Thanks and Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 17, 2005 11:43 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > I don't know whether I am missing something, but is there a way > to do the reverse of what you are doing right now? (XML -> Class) what > about (Class -> XML?), have you provided any API for the same? Sure, we call it serialization (as opposed to parsing). You can look at examples/cxx/tree/library for the code sample and at the "C++/Tree Serialization Guide" for documentation: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/serializati on Also note that the serialization code is optional and you will need to specify --generate-serialization when invoking xsd. hth, -boris From boris at codesynthesis.com Mon Oct 17 14:15:16 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051017181516.GA28736@karelia> Pradipta, De, Pradipta writes: > But, when try to generate the code like the following way: > > C:\Documents and > Settings\pde\Desktop\useful\codes\xsd-1.4.0-i686-windows\bin>xsd > --generate-serialization xxxx_Online_Input.xsd I think you forgot to specify which mapping you want. It should be something like this: xsd cxx-tree --generate-serialization xxxx_Online_Input.xsd BTW, the command line interface of the compiler is documented here: http://codesynthesis.com/projects/xsd/documentation/xsd.xhtml hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051017/e789f6f9/attachment.pgp From pde at seic.com Mon Oct 17 14:26:15 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Sorry, Boris I have found it and got the code generated..... Regards, Pradipta De TCS SEI Investments 1 Freedom Valley Drive, Oaks, PA 19456 | Office 610-676-1181 | pde@seic.com | pradipta.de@tcs.com -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 17, 2005 2:15 PM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > But, when try to generate the code like the following way: > > C:\Documents and > Settings\pde\Desktop\useful\codes\xsd-1.4.0-i686-windows\bin>xsd > --generate-serialization xxxx_Online_Input.xsd I think you forgot to specify which mapping you want. It should be something like this: xsd cxx-tree --generate-serialization xxxx_Online_Input.xsd BTW, the command line interface of the compiler is documented here: http://codesynthesis.com/projects/xsd/documentation/xsd.xhtml hth, -boris From pde at seic.com Tue Oct 18 13:44:41 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, We tried the serialization , but we are hitting into similar problems like the one we initially hit for elements.txx , the error we are getting is as follows ********************* "/home1/xxxx/pradipta/parser_1.4/libxsd-1.4.0-2/xsd/cxx/xml/dom/serializ ation.txx", line 173: Error: A constructor may not have a return type specification. "/home1/xxxx/pradipta/parser_1.4/libxsd-1.4.0-2/xsd/cxx/xml/dom/serializ ation.txx", line 173: Error: xsd::cxx::xml::dom::dom(const std::basic_string, std::allocator>&, const std::basic_string, std::allocator>&, const xsd::cxx::xml::dom::namespace_infomap&) is not a member of xsd::cxx::xml::dom. 2 Error(s) detected. *** Error code 2 make: Fatal error: Command failed for target `driver.o' ********************* Please have a look and let us know. Thanks & Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 17, 2005 2:15 PM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > But, when try to generate the code like the following way: > > C:\Documents and > Settings\pde\Desktop\useful\codes\xsd-1.4.0-i686-windows\bin>xsd > --generate-serialization xxxx_Online_Input.xsd I think you forgot to specify which mapping you want. It should be something like this: xsd cxx-tree --generate-serialization xxxx_Online_Input.xsd BTW, the command line interface of the compiler is documented here: http://codesynthesis.com/projects/xsd/documentation/xsd.xhtml hth, -boris From pde at seic.com Tue Oct 18 15:24:02 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, That problem I managed to solve. See the attached file. Please tell me whether the patch is OK or not? But now I am facing a different compilation error. See the error below: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<< /home1/xxxx/pradipta/parser_1.4/output_unparse/bin >make -f libunparse.mak echo finDNA_Online_Output ../src/finDNA_Online_Output.cxx finDNA_Online_Output.o ../src/finDNA_Online_Output.cxx finDNA_Online_Output ../src/finDNA_Online_Output.cxx finDNA_Online_Output.o ../src/finDNA_Online_Output.cxx CC -g -D_SHDEBUG_ -D_SVCDEBUG_ -c -I/home1/xxxx/pradipta/parser_1.4/output_unparse/include -I/home1/xxxx/pradipta/parser_1.4/libxsd-1.4.0-2 -I/home1/xxxx/pradipta/parser_1.4/xerces-c-solaris_28-cc_62/include -I/home1/xxxx/pradipta/parser_1.4/xerces-c-solaris_28-cc_62/include/xerc esc ../src/finDNA_Online_Output.cxx Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator xsd::cxx::tree::one_functor>() const" and "xsd::cxx::tree::fundamental_base::operator xsd::cxx::tree::one_functor>()". "../src/finDNA_Online_Output.cxx", line 593: Error: Could not find a match for xsd::cxx::xml::dom::dom(const char[10], const char[26], const xsd::cxx::xml::dom::namespace_infomap) needed in xxxx::amloutput(const xxxx::AMLOutput&, const xsd::cxx::xml::dom::namespace_infomap&). Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator signed char() const" and "xsd::cxx::tree::fundamental_base::operator signed char()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator long double() const" and "xsd::cxx::tree::fundamental_base::operator long double()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator double() const" and "xsd::cxx::tree::fundamental_base::operator double()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator float() const" and "xsd::cxx::tree::fundamental_base::operator float()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator bool() const" and "xsd::cxx::tree::fundamental_base::operator bool()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator unsigned long long() const" and "xsd::cxx::tree::fundamental_base::operator unsigned long long()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator long long() const" and "xsd::cxx::tree::fundamental_base::operator long long()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator unsigned() const" and "xsd::cxx::tree::fundamental_base::operator unsigned()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator unsigned short() const" and "xsd::cxx::tree::fundamental_base::operator unsigned short()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator short() const" and "xsd::cxx::tree::fundamental_base::operator short()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator unsigned char() const" and "xsd::cxx::tree::fundamental_base::operator unsigned char()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator signed char() const" and "xsd::cxx::tree::fundamental_base::operator signed char()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator long double() const" and "xsd::cxx::tree::fundamental_base::operator long double()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator long double() const" and "xsd::cxx::tree::fundamental_base::operator long double()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator signed char() const" and "xsd::cxx::tree::fundamental_base::operator signed char()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator double() const" and "xsd::cxx::tree::fundamental_base::operator double()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator double() const" and "xsd::cxx::tree::fundamental_base::operator double()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator signed char() const" and "xsd::cxx::tree::fundamental_base::operator signed char()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator float() const" and "xsd::cxx::tree::fundamental_base::operator float()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator float() const" and "xsd::cxx::tree::fundamental_base::operator float()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator signed char() const" and "xsd::cxx::tree::fundamental_base::operator signed char()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator bool() const" and "xsd::cxx::tree::fundamental_base::operator bool()". Error: Overloading ambiguity between "xsd::cxx::tree::fundamental_base::operator bool() const" and "xsd::cxx::tree::fundamental_base::operator bool()". Compilation aborted, too many Error messages. *** Error code 1 make: Fatal error: Command failed for target `finDNA_Online_Output.o' /home1/xxxx/pradipta/parser_1.4/output_unparse/bin > >>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<< I tried a lot to trace it out, but not able to do it. Please look into it and let me know. Thanks and Regards, Pradipta De -----Original Message----- From: De, Pradipta Sent: Tuesday, October 18, 2005 1:45 PM To: 'Boris Kolpackov' Cc: xsd-users@codesynthesis.com Subject: RE: Problem during compilation of generated files Hi Boris, We tried the serialization , but we are hitting into similar problems like the one we initially hit for elements.txx , the error we are getting is as follows ********************* "/home1/xxxx/pradipta/parser_1.4/libxsd-1.4.0-2/xsd/cxx/xml/dom/serializ ation.txx", line 173: Error: A constructor may not have a return type specification. "/home1/xxxx/pradipta/parser_1.4/libxsd-1.4.0-2/xsd/cxx/xml/dom/serializ ation.txx", line 173: Error: xsd::cxx::xml::dom::dom(const std::basic_string, std::allocator>&, const std::basic_string, std::allocator>&, const xsd::cxx::xml::dom::namespace_infomap&) is not a member of xsd::cxx::xml::dom. 2 Error(s) detected. *** Error code 2 make: Fatal error: Command failed for target `driver.o' ********************* Please have a look and let us know. Thanks & Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 17, 2005 2:15 PM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > But, when try to generate the code like the following way: > > C:\Documents and > Settings\pde\Desktop\useful\codes\xsd-1.4.0-i686-windows\bin>xsd > --generate-serialization xxxx_Online_Input.xsd I think you forgot to specify which mapping you want. It should be something like this: xsd cxx-tree --generate-serialization xxxx_Online_Input.xsd BTW, the command line interface of the compiler is documented here: http://codesynthesis.com/projects/xsd/documentation/xsd.xhtml hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: serialization.txx Type: application/octet-stream Size: 8889 bytes Desc: serialization.txx Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051018/ed92c714/serialization.obj From boris at codesynthesis.com Wed Oct 19 10:05:26 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051019140526.GA22620@karelia> Pradipta, De, Pradipta writes: > That problem I managed to solve. See the attached file. > > Please tell me whether the patch is OK or not? Yes, it's good. > But now I am facing a different compilation error. See the error below: We are in the middle of releasing 1.5.0 which will support Sun C++ 5.7. I suggest you wait for this release (should be out by tomorrow if nothing goes seriously wrong) and give it a try. There could still be problems because you are using 5.6 but at least we will be one step closer and I won't have to patch 1.4.0 and then port those changes over to 1.5.0. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051019/dadddf6d/attachment.pgp From jboyden at geosci.usyd.edu.au Wed Oct 19 11:06:44 2005 From: jboyden at geosci.usyd.edu.au (James Boyden) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] C++/Parser errors from GML schemas In-Reply-To: <20051017100055.GA21814@karelia> References: <20051012062543.GB3461@geosci.usyd.edu.au> <20051012074824.GA24709@karelia> <20051013114508.GA8265@geosci.usyd.edu.au> <20051013124356.GA2023@karelia> <20051013131200.GA23394@geosci.usyd.edu.au> <20051017100055.GA21814@karelia> Message-ID: <20051019150644.GC26987@geosci.usyd.edu.au> On Monday, Oct 17, Boris Kolpackov wrote: > I was test the in-development version of xsd against the GML schemas > you sent me and found out that they are not quite valid. In this version, > I decided to turn "expensive" (time and memory -wise) checks (such as > unique particle attribution, etc.) on which uncovered the whole bunch > of errors (see below). I checked one instance and turned out that the > schema is indeed invalid. For example, here is the snippet from > coordinateOperations.xsd:519: > > [...] > > There are two problems in this case: > > 1. OperationMethodBaseType should explicitly declare each element found > in DefinitionType (name and description are missing). > > 2. We cannot add any new elements/attributes (methodName in this case) > for valid OperationMethodBaseType content model should also be > valid per DefinitionType. Hi Boris, Thank you very much for this information. We have passed it on to some of the GML developers. I will provide an update when they have responded to us about these problems. Regards, James Boyden -- James Boyden GPlates Programmer and Keeper of the Flame, School of Geosciences, University of Sydney, Australia. "I find your lack of faith disturbing." From pde at seic.com Wed Oct 19 10:44:22 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, This sounds great.....we will try out then day after tomorrow.... Thanks & Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, October 19, 2005 10:05 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > That problem I managed to solve. See the attached file. > > Please tell me whether the patch is OK or not? Yes, it's good. > But now I am facing a different compilation error. See the error below: We are in the middle of releasing 1.5.0 which will support Sun C++ 5.7. I suggest you wait for this release (should be out by tomorrow if nothing goes seriously wrong) and give it a try. There could still be problems because you are using 5.6 but at least we will be one step closer and I won't have to patch 1.4.0 and then port those changes over to 1.5.0. hth, -boris From boris at codesynthesis.com Thu Oct 20 09:57:02 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] xsd 1.5.0 released Message-ID: <20051020135702.GB5033@karelia> Good day, We've released xsd 1.5.0. The NEWS file entries for this version are as follows: * Number of bug fixes in libxsd and the generated code. cxx-tree * Basic support for inheritance-by-restriction in complex types. * The following parsing flags have been introduced: keep_dom - keep association with underlying DOM nodes dont_validate - do not validate instance documents dont_initialize - do not initialize the Xerces-C++ runtime * "Type-less content" such as mixed content models, xsd:anyType/ xsd:anySimpleType, and xsd:any/xsd:anyAttribute is supported by exposing corresponding DOM nodes (see the keep_dom parsing flag). Note that only a subset of XML Schema xsd:any functionality is supported. The compiler will issue diagnostics for unsupported cases. See examples/cxx/tree/mixed for a code sample. cxx-parser * Support for inheritance-by-restriction in complex types. * "Type-less content" such as mixed content models, xsd:anyType/ xsd:anySimpleType, and xsd:any/xsd:anyAttribute is supported by forwarding parsing events to a set of "unexpected" hooks. Note that only a subset of XML Schema xsd:any functionality is supported. The compiler will issue diagnostics for unsupported cases. See examples/cxx/parser/mixed for a code sample. Additionally, with this release we've added a precompiled binary for Solaris/SPARC and support for Sun C++ 5.7 (Studio 10). Precompiled binary distributions for various platforms are available from the product's web page: http://codesynthesis.com/products/xsd/ Source code for this release is available from the project's web page: http://codesynthesis.com/projects/xsd/ SHA1 checksums for the files: 2c00e42752efae78b61d17e481fc79641590bb35 xsd-1.5.0.tar.bz2 a8a884f28aaa6ba966d04f46fdc9d10300f9f08d xsd_1.5.0-1_i386.deb ca9e98e8139fa373bab588cbfecb2f9e77b67a7c xsd-1.5.0-1.i686.rpm 000362a8f6628b67a4772a495a7c25ffcdbbb542 xsd-1.5.0-i686-linux-gnu.tar.bz2 5660a9c1be89aafdec093c69bb24c81dec4f6296 xsd_1.5.0-1_amd64.deb 87950886d62699c662d1f7260732c3a45d859f92 xsd-1.5.0-1.x86_64.rpm d7f85ea52ae93967b982b5f5a34c68e7727622c4 xsd-1.5.0-x86_64-linux-gnu.tar.bz2 aa00323e0583854ab893c5638c900b3ebb48e102 xsd-1.5.0-powerpc-macosx.tar.bz2 0c089538d4ed6286f19fcd99801c0b7e6584e23f xsd-1.5.0-sparc-solaris.tar.bz2 12659e1bdbf7f0827e62679f63d824a9d2cb6298 xsd-1.5.0-i686-windows.zip have fun, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051020/bb3f40ff/attachment.pgp From pde at seic.com Thu Oct 20 15:54:33 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, Thanks a lot for your time. We downloaded the xsd version 1.5 from the site and successfully able to generate the code for tree implementation in Solaris. But, unfortunately when we tried to compile those codes along with the driver code, we again face some problem that I am not able to trace. The error is as follows: /home1/xxxx/pradipta/parser_1.4/tree_code/bin >make -f libtree.mak echo xxxx_Online_Input ../src/xxxx_Online_Input.cxx xxxx_Online_Input.o ../src/xxxx_Online_Input.cxx xxxx_Online_Input ../src/xxxx_Online_Input.cxx xxxx_Online_Input.o ../src/xxxx_Online_Input.cxx CC -g -D_SHDEBUG_ -D_SVCDEBUG_ -c -I/home1/xxxx/pradipta/parser_1.4/tree_code/include -I/home1/xxxx/pradipta/parser_1.4/xsd-1.5.0-sparc-solaris/libxsd -I/home1/xxxx/pradipta/parser_1.4/xerces-c-solaris_28-cc_62/include -I/home1/xxxx/pradipta/parser_1.4/xerces-c-solaris_28-cc_62/include/xerc esc ../src/xxxx_Online_Input.cxx "/home1/xxxx/pradipta/parser_1.4/xsd-1.5.0-sparc-solaris/libxsd/xsd/cxx/ tree/elements.hxx", line 497: Error: xsd::cxx::tree::type::dom_info is not accessible from static xsd::cxx::tree::type::dom_info_factory::create(const xsd::cxx::xml::dom::element&, xsd::cxx::tree::flags). "/home1/xxxx/pradipta/parser_1.4/xsd-1.5.0-sparc-solaris/libxsd/xsd/cxx/ tree/elements.hxx", line 499: Error: xsd::cxx::tree::type::dom_info is not accessible from static xsd::cxx::tree::type::dom_info_factory::create(const xsd::cxx::xml::dom::element&, xsd::cxx::tree::flags). "/home1/xxxx/pradipta/parser_1.4/xsd-1.5.0-sparc-solaris/libxsd/xsd/cxx/ tree/elements.hxx", line 500: Error: xsd::cxx::tree::type::dom_element_info is not accessible from static xsd::cxx::tree::type::dom_info_factory::create(const xsd::cxx::xml::dom::element&, xsd::cxx::tree::flags). 3 Error(s) detected. *** Error code 3 make: Fatal error: Command failed for target `xxxx_Online_Input.o' Previously, we are able to compile with the patch you sent earlier. It will be great if you can help me out from that problem. Thanks & Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, October 19, 2005 10:05 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > That problem I managed to solve. See the attached file. > > Please tell me whether the patch is OK or not? Yes, it's good. > But now I am facing a different compilation error. See the error below: We are in the middle of releasing 1.5.0 which will support Sun C++ 5.7. I suggest you wait for this release (should be out by tomorrow if nothing goes seriously wrong) and give it a try. There could still be problems because you are using 5.6 but at least we will be one step closer and I won't have to patch 1.4.0 and then port those changes over to 1.5.0. hth, -boris From boris at codesynthesis.com Fri Oct 21 02:52:48 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051021065248.GA8400@karelia> Pradipta, De, Pradipta writes: > Thanks a lot for your time. We downloaded the xsd version 1.5 from the > site and successfully able to generate the code for tree implementation > in Solaris. Cool. I guess it's a lot better than generating on Windows and copying to Solaris. ;-) > But, unfortunately when we tried to compile those codes along with the > driver code, we again face some problem that I am not able to trace. The > error is as follows: I am attaching new libxsd/xsd/cxx/tree/elements.hxx. Can you replace the old one with this and give it a try? hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: elements.hxx.gz Type: application/octet-stream Size: 6843 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051021/180fe53f/elements.hxx.obj From pde at seic.com Fri Oct 21 08:54:07 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, No doubt about that.....Now we have total application in Solaris.....that is really great..... With the new hxx file, everything gets compiled and working very fine...... I am really appreciating your effort, time and help....... I will start to fit the application with my other application....Lets see what happen... We will be in touch..... Thanks and Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 21, 2005 2:53 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > Thanks a lot for your time. We downloaded the xsd version 1.5 from the > site and successfully able to generate the code for tree implementation > in Solaris. Cool. I guess it's a lot better than generating on Windows and copying to Solaris. ;-) > But, unfortunately when we tried to compile those codes along with the > driver code, we again face some problem that I am not able to trace. The > error is as follows: I am attaching new libxsd/xsd/cxx/tree/elements.hxx. Can you replace the old one with this and give it a try? hth, -boris From pde at seic.com Fri Oct 21 09:07:56 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, I go through the code of element.hxx and I found the patch you put is the following: // For Sun C++ 5.6. // struct dom_info_factory; friend struct type::dom_info_factory; But, dom_info_factory is part of class type and dom_info and dom_info_element are also part of same class, so why we require to put friend there. The error was coming for dom_info and dom_info_element in case of create (of element). But, for another create (of attribute) it was working fine. Although, both dom_element_info and dom_attribute_info were in the same scope. I will appreciate if you can put some light on those things. Thanks and Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 21, 2005 2:53 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > Thanks a lot for your time. We downloaded the xsd version 1.5 from the > site and successfully able to generate the code for tree implementation > in Solaris. Cool. I guess it's a lot better than generating on Windows and copying to Solaris. ;-) > But, unfortunately when we tried to compile those codes along with the > driver code, we again face some problem that I am not able to trace. The > error is as follows: I am attaching new libxsd/xsd/cxx/tree/elements.hxx. Can you replace the old one with this and give it a try? hth, -boris From boris at codesynthesis.com Fri Oct 21 10:50:40 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051021145040.GA18249@karelia> Pradipta, De, Pradipta writes: > I go through the code of element.hxx and I found the patch you put is > the following: > > // For Sun C++ 5.6. > // > struct dom_info_factory; > friend struct type::dom_info_factory; > > But, dom_info_factory is part of class type and dom_info and > dom_info_element are also part of same class, so why we require to put > friend there. I think it's because Sun C++ 5.6 does not allow nested classes to access private members of outer class. In 5.7 they changed this, see http://developers.sun.com/prodtech/cc/documentation/ss10_docs/mr/READMEs/c++.html#new fourth bullet. > The error was coming for dom_info and dom_info_element in case of > create (of element). But, for another create (of attribute) it was > working fine. Although, both dom_element_info and dom_attribute_info > were in the same scope. I think the compiler just stopped compilation at the first function. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051021/87b32576/attachment.pgp From pde at seic.com Fri Oct 21 11:31:30 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, That is great..... The link that you have sent is really very helpful..... I already started to implement xsd application in my existing system...... I will let you know when I get a good result..... ;->) Thanks and Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 21, 2005 10:51 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > I go through the code of element.hxx and I found the patch you put is > the following: > > // For Sun C++ 5.6. > // > struct dom_info_factory; > friend struct type::dom_info_factory; > > But, dom_info_factory is part of class type and dom_info and > dom_info_element are also part of same class, so why we require to put > friend there. I think it's because Sun C++ 5.6 does not allow nested classes to access private members of outer class. In 5.7 they changed this, see http://developers.sun.com/prodtech/cc/documentation/ss10_docs/mr/READMEs /c++.html#new fourth bullet. > The error was coming for dom_info and dom_info_element in case of > create (of element). But, for another create (of attribute) it was > working fine. Although, both dom_element_info and dom_attribute_info > were in the same scope. I think the compiler just stopped compilation at the first function. hth, -boris From mgusarov at swsoft.com Sat Oct 22 00:35:23 2005 From: mgusarov at swsoft.com (Mikhail Gusarov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] invalid generated code on complex choice/sequence Message-ID: <87mzl2rwxg.fsf@origin.plesk.ru> The attached (perfectly valid) schema makes xsd to generate invalid tree code. I know I may easily rewrite such a schema, but such a corner cases should be handled anyway. -- Mikhail Gusarov ICQ UIN: 111575219 JID: dottedmag@jabber.dottedmag.net -------------- next part -------------- A non-text attachment was scrubbed... Name: blah.xsd Type: application/octet-stream Size: 481 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051022/5ed4f059/blah.obj From boris at codesynthesis.com Sun Oct 23 05:33:19 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] C++/Parser errors from GML schemas In-Reply-To: <20051017100055.GA21814@karelia> References: <20051012062543.GB3461@geosci.usyd.edu.au> <20051012074824.GA24709@karelia> <20051013114508.GA8265@geosci.usyd.edu.au> <20051013124356.GA2023@karelia> <20051013131200.GA23394@geosci.usyd.edu.au> <20051017100055.GA21814@karelia> Message-ID: <20051023093319.GA24509@karelia> James, Boris Kolpackov writes: > > > > > > > > > > > > > Now look at the base type definition (dictionary.xsd:35): > > > > > > > > > > > > > > > There are two problems in this case: > > 1. OperationMethodBaseType should explicitly declare each element found > in DefinitionType (name and description are missing). Just one correction: it is ok to omit description in OperationMethodBaseType since it is minOccurs="0". hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051023/63e1f760/attachment.pgp From boris at codesynthesis.com Sun Oct 23 05:35:17 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] invalid generated code on complex choice/sequence In-Reply-To: <87mzl2rwxg.fsf@origin.plesk.ru> References: <87mzl2rwxg.fsf@origin.plesk.ru> Message-ID: <20051023093517.GB24509@karelia> Mikhail, Mikhail Gusarov writes: > The attached (perfectly valid) schema makes xsd to generate invalid > tree code. I know I may easily rewrite such a schema, but such a > corner cases should be handled anyway. Yes, you are right. I will try to come up with a fix for the next release. Thanks for reporting this! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051023/fc2b4065/attachment.pgp From pde at seic.com Mon Oct 24 09:49:50 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Hi Boris, I am able to integrate the xsd tree codes library to great extent with my application. But, in case of serialization I am getting core..... What I have done, I just parse the XML and without any modification unparsing the same. The driver code is like that: // file : xsd/examples/cxx/tree/library/driver.cxx // author : Boris Kolpackov // copyright : not copyrighted - public domain #include // std::auto_ptr #include #include "xxx_output.hxx" using std::cerr; using std::endl; int main (int argc, char* argv[]) { if (argc != 2) { cerr << "usage: " << argv[0] << " library.xml" << endl; return 1; } using namespace xxxx; // Read in the file. // std::auto_ptr l (amloutput (argv[1])); // Now we are going to modify in-memory representation and serialize it // back to XML. // xml_schema::namespace_infomap map; map["lib"].name = "/home1/xxxx/pradipta/parser_1.4/output_unparse"; map["lib"].schema = "xxxx_Online_Output.xsd"; // Write it out. // amloutput (std::cout, *l, map); return 0; } ======================================================================== ==== The stack trace of the core is as follows: where -h current thread: t@1 [1] _lwp_kill(0x0, 0x6, 0x21b10, 0xff2d0a14, 0x0, 0x0), at 0xff31f82c [2] raise(0x6, 0x0, 0xffbff0f0, 0xc9f60, 0xc2da4, 0x35c), at 0xff2d0a1c [3] abort(0xc5c00, 0xc5c00, 0x98698, 0xc9f60, 0xc2da4, 0x98320), at 0xff2b6cd8 [4] __Cimpl::ex_terminate(0x0, 0x0, 0xc5f40, 0x5e3b0, 0xc5f40, 0x1), at 0x980b4 [5] _ex_throw_body(0xc5f40, 0x0, 0x0, 0x1, 0x2a584, 0xc5f40), at 0x98940 =>[6] xsd::cxx::xml::dom::dom(el = CLASS, ns = CLASS, map = STRUCT), line 193 in "serialization.txx" [7] xsd::cxx::xml::dom::dom(root_element = 0x9c63c "amloutput", root_element_namespace = 0x9c646 "http://www.tcs.com/xxxx", map = STRUCT), line 96 in "serialization.hxx" [8] xxxx::amloutput(s = CLASS, m = STRUCT), line 292 in "xxx_output.cxx" [9] xxxx::amloutput(o = CLASS, s = CLASS, m = STRUCT, e = CLASS), line 345 in "xxx_output.cxx" [10] main(argc = 2, argv = 0xffbff764), line 105 in "xxx_driver.cpp" ======================================================================== ==== The xsd is as follows: Start of watchlist output data ======================================================================== ==== The XML is as follows: String 0 String String String ======================================================================== ==== I think that information will help you.... If possible please look into that..... Thanks and Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, October 21, 2005 10:51 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > I go through the code of element.hxx and I found the patch you put is > the following: > > // For Sun C++ 5.6. > // > struct dom_info_factory; > friend struct type::dom_info_factory; > > But, dom_info_factory is part of class type and dom_info and > dom_info_element are also part of same class, so why we require to put > friend there. I think it's because Sun C++ 5.6 does not allow nested classes to access private members of outer class. In 5.7 they changed this, see http://developers.sun.com/prodtech/cc/documentation/ss10_docs/mr/READMEs /c++.html#new fourth bullet. > The error was coming for dom_info and dom_info_element in case of > create (of element). But, for another create (of attribute) it was > working fine. Although, both dom_element_info and dom_attribute_info > were in the same scope. I think the compiler just stopped compilation at the first function. hth, -boris From boris at codesynthesis.com Mon Oct 24 09:57:25 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: Problem during compilation of generated files In-Reply-To: References: Message-ID: <20051024135725.GA3546@karelia> Pradipta, De, Pradipta writes: > map["lib"].name = "/home1/xxxx/pradipta/parser_1.4/output_unparse"; This should be a namespace name which, from your schema above, seems to be "http://www.tcs.com/xxxx". xsd-generated code throws xml_schema::mapping exception which, since you didn't handle it, leads in abort(). I suggest that you wrap your code with the following try/catch statements: try { // Your code goes here. } catch (xml_schema::exception const& ex) { cerr << ex.what () << endl; } This will give you an idea what's going. You can see the list of exceptions that the xsd-generated code throws in libxsd/xsd/cxx/tree/exceptions.hxx. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051024/1aaaeeb8/attachment.pgp From pde at seic.com Mon Oct 24 10:32:21 2005 From: pde at seic.com (De, Pradipta) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] RE: Problem during compilation of generated files Message-ID: Thanks a lot Boris.....that is working perfectly..... Great........ Regards, Pradipta De -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, October 24, 2005 9:57 AM To: De, Pradipta Cc: xsd-users@codesynthesis.com Subject: Re: Problem during compilation of generated files Pradipta, De, Pradipta writes: > map["lib"].name = "/home1/xxxx/pradipta/parser_1.4/output_unparse"; This should be a namespace name which, from your schema above, seems to be "http://www.vvv.com/xxxx". xsd-generated code throws xml_schema::mapping exception which, since you didn't handle it, leads in abort(). I suggest that you wrap your code with the following try/catch statements: try { // Your code goes here. } catch (xml_schema::exception const& ex) { cerr << ex.what () << endl; } This will give you an idea what's going. You can see the list of exceptions that the xsd-generated code throws in libxsd/xsd/cxx/tree/exceptions.hxx. hth, -boris From boris at codesynthesis.com Wed Oct 26 04:49:52 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] plans for xsd 1.6.0 Message-ID: <20051026084952.GA28003@karelia> Good day, We are planning to make the following user-visible changes in xsd 1.6.0 which is to be released around Nov 13. Your feedback on the proposed changes/new features is always appreciated. * Support for xsi:type and substitution groups. * Properties argument to parsing functions which will allow to programmatically specify schemas for instance document validation. * Extra checks in parsing code which will prevent construction of inconsistent in-memory representation from invalid instance documents. Should be useful when validation is disabled. * Workaround for g++-3.3 bug# 16650. This change didn't make it into 1.5.0. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16650 hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051026/67c6a257/attachment.pgp From frederic.heem at telsey.it Wed Oct 26 13:11:50 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] ccxml.xsd In-Reply-To: <200510261600.j9QG0Eov023126@codesynthesis.com> References: <200510261600.j9QG0Eov023126@codesynthesis.com> Message-ID: <200510261911.51019.frederic.heem@telsey.it> Hi boris, I would like to make a basic ccxml interpreter in C++, its W3C shema file is ccxml.xsd. The first problem is that the one import keyword has a schemaLocation attribute value of "http://www.w3.org/2001/xml.xsd", xsd doesn't support remote import. It would be nice to have a command line option to map a remote file to a local one. Anyway, this is not an important problem, I've changed the attribute value to xml.xsd and downloaded this file. The second problem is an error occurs while parsing xml.xsd: xml.xsd:108:40: error: expected 'list' or 'restriction' instead of 'union' As I don't care about the attribute lang, I've modified the attribute lang to not use union keyword and add the type xs:string as a type: Attempting to install the relevant ISO 2- and 3-letter codes as the enumerated possible values is probably never going to be a realistic possibility. See RFC 3066 at http://www.ietf.org/rfc/rfc3066.txt and the IANA registry at http://www.iana.org/assignments/lang-tag-apps.htm for further information. The union allows for the 'un-declaration' of xml:lang with the empty string. xsd 1.5 segfaults, here is the backtrace: #0 0x081be966 in XSDFrontend::(anonymous namespace)::Resolver::traverse_group () at basic_string.tcc:243 243 basic_string.tcc: No such file or directory. in basic_string.tcc (gdb) bt #0 0x081be966 in XSDFrontend::(anonymous namespace)::Resolver::traverse_group () at basic_string.tcc:243 #1 0x081bee4c in XSDFrontend::(anonymous namespace)::Resolver::traverse () at basic_string.tcc:243 #2 0x08090593 in FrontendElements::Traversal::DispatcherBase::dispatch_ () at basic_string.tcc:243 #3 0x08091403 in FrontendElements::Traversal::DispatcherBase::dispatch_ () at basic_string.tcc:243 #4 0x080bedf6 in XSDFrontend::Traversal::ScopeTemplate::names () at basic_string.tcc:243 #5 0x081beeec in XSDFrontend::(anonymous namespace)::Resolver::traverse () at basic_string.tcc:243 #6 0x08090593 in FrontendElements::Traversal::DispatcherBase::dispatch_ () at basic_string.tcc:243 #7 0x08091403 in FrontendElements::Traversal::DispatcherBase::dispatch_ () at basic_string.tcc:243 #8 0x0808c408 in XSDFrontend::Traversal::ScopeTemplate::names () at basic_string.h:218 #9 0x0808bf96 in XSDFrontend::Traversal::Namespace::traverse () #10 0x08090593 in FrontendElements::Traversal::DispatcherBase::dispatch_ () at basic_string.tcc:243 #11 0x08091403 in FrontendElements::Traversal::DispatcherBase::dispatch_ () at basic_string.tcc:243 #12 0x0809aaf8 in XSDFrontend::Traversal::ScopeTemplate::names () at basic_string.tcc:243 #13 0x0809a809 in XSDFrontend::Traversal::Schema::traverse () at basic_string.tcc:243 #14 0x08090593 in FrontendElements::Traversal::DispatcherBase::dispatch_ () at basic_string.tcc:243 #15 0x081a3144 in XSDFrontend::Parser::Impl::parse () at basic_string.tcc:243 #16 0x081a336d in XSDFrontend::Parser::parse () at basic_string.tcc:243 #17 0x08061054 in main () I hope it helps. of On Wednesday 26 October 2005 18:00, xsd-users-request@codesynthesis.com wrote: > Send xsd-users mailing list submissions to > xsd-users@codesynthesis.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://codesynthesis.com/mailman/listinfo/xsd-users > or, via email, send a message with subject or body 'help' to > xsd-users-request@codesynthesis.com > > You can reach the person managing the list at > xsd-users-owner@codesynthesis.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of xsd-users digest..." > > > Today's Topics: > > 1. plans for xsd 1.6.0 (Boris Kolpackov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Oct 2005 10:49:52 +0200 > From: Boris Kolpackov > Subject: [xsd-users] plans for xsd 1.6.0 > To: xsd-users@codesynthesis.com > Message-ID: <20051026084952.GA28003@karelia> > Content-Type: text/plain; charset="us-ascii" > > Good day, > > We are planning to make the following user-visible changes in xsd 1.6.0 > which is to be released around Nov 13. Your feedback on the proposed > changes/new features is always appreciated. > > > * Support for xsi:type and substitution groups. > > > * Properties argument to parsing functions which will allow to > programmatically specify schemas for instance document validation. > > > * Extra checks in parsing code which will prevent construction > of inconsistent in-memory representation from invalid instance > documents. Should be useful when validation is disabled. > > > * Workaround for g++-3.3 bug# 16650. This change didn't make it > into 1.5.0. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16650 > > > hth, > -boris > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 652 bytes > Desc: Digital signature > Url : > http://codesynthesis.com/pipermail/xsd-users/attachments/20051026/67c6a257/ >attachment-0001.pgp > > ------------------------------ > > _______________________________________________ > xsd-users mailing list > xsd-users@codesynthesis.com > http://codesynthesis.com/mailman/listinfo/xsd-users > > > End of xsd-users Digest, Vol 4, Issue 22 > **************************************** -- ***** ? ? ----- ? ? ***** ? ? ----- ? ? ***** ? ? Frederic Heem Software Designer R&D - Telsey SpA Telecommunications Viale Industria, 1 31055 Quinto di Treviso (TV) ITALY Tel. direct phone: (+39) 0422 377819 Tel. (+39) 0422 377711 Fax. (+39) 0422 470920 website ==> www.telsey.it PRIVACY AND CONFIDENTIALITY NOTICE This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: ccxml.xsd Type: application/xml Size: 17603 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051026/398788fc/ccxml.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: ccxml-localTargetNamespace.xsd Type: application/xml Size: 17580 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051026/398788fc/ccxml-localTargetNamespace.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: xml.xsd Type: application/xml Size: 5849 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051026/398788fc/xml.xml From boris at codesynthesis.com Thu Oct 27 06:32:12 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] ccxml.xsd In-Reply-To: <200510261911.51019.frederic.heem@telsey.it> References: <200510261600.j9QG0Eov023126@codesynthesis.com> <200510261911.51019.frederic.heem@telsey.it> Message-ID: <20051027103212.GA14127@karelia> Frederic, frederic heem writes: > The first problem is that the one import keyword has a schemaLocation > attribute value of "http://www.w3.org/2001/xml.xsd", xsd doesn't support > remote import. It would be nice to have a command line option to map a > remote file to a local one. I guess we can support something like this one day. > The second problem is an error occurs while parsing xml.xsd: > xml.xsd:108:40: error: expected 'list' or 'restriction' instead > of 'union' Right, unions are not yet supported. > xsd 1.5 segfaults, here is the backtrace: I fixed this bug. Would you like a pre-release? If so, let me know which platform/package and whether it is ok to send via email. Thanks for reporting bugs! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051027/7adb4a35/attachment.pgp From frederic.heem at telsey.it Thu Oct 27 12:55:49 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] anonymous types Message-ID: <200510271855.49883.frederic.heem@telsey.it> Hi Boris, In the Call Control Xml, anonymous types are used a lot and this bloats the code unless the command line option --morph-anonymous is used. Would it be possible to perform automatic morphing by appending Type to the class name ? ccxml.xsd contains about 30 anonymous type and the command line would be quite long. would become be equivalent to How do other xsd compiler manage this problem ? -- ***** ? ? ----- ? ? ***** ? ? ----- ? ? ***** ? ? Frederic Heem Software Designer R&D - Telsey SpA Telecommunications Viale Industria, 1 31055 Quinto di Treviso (TV) ITALY Tel. direct phone: (+39) 0422 377819 Tel. (+39) 0422 377711 Fax. (+39) 0422 470920 website ==> www.telsey.it PRIVACY AND CONFIDENTIALITY NOTICE This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. From boris at codesynthesis.com Thu Oct 27 13:59:32 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] anonymous types In-Reply-To: <200510271855.49883.frederic.heem@telsey.it> References: <200510271855.49883.frederic.heem@telsey.it> Message-ID: <20051027175932.GA18997@karelia> Frederic, frederic heem writes: > Would it be possible to perform automatic morphing by appending Type to > the class name ? Sure, you can use --anonymous-regex which is described in the man pages and online: http://codesynthesis.com/projects/xsd/documentation/xsd.xhtml The command line that does what you want would look like this: xsd cxx-tree --morph-anonymous --anonymous-regex '%.* .* (.+/)*(.+)%$2Type%' Also, you may want the transformation to be 'accept' -> 'AcceptType' then you can use xsd cxx-tree --morph-anonymous --anonymous-regex '%.* .* (.+/)*(.+)%\u$2Type%' > How do other xsd compiler manage this problem ? I honestly don't know. I think most of them always do something similar to anonymous type morphing and decide on the name for you. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051027/27b1e796/attachment.pgp From frederic.heem at telsey.it Fri Oct 28 03:22:38 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] anonymous types In-Reply-To: <20051027175932.GA18997@karelia> References: <200510271855.49883.frederic.heem@telsey.it> <20051027175932.GA18997@karelia> Message-ID: <200510280922.38559.frederic.heem@telsey.it> Hi boris, Great, it works ! Moreover, file size (hxx and cxx) has decreased the from 1 Mb to 200Kb. It would be nice to add this question/response to the FAQ. Everyone is not an expert in regular expression. On Thursday 27 October 2005 19:59, Boris Kolpackov wrote: > xsd cxx-tree --morph-anonymous --anonymous-regex '%.* .* > (.+/)*(.+)%\u$2Type%' -- ***** ? ? ----- ? ? ***** ? ? ----- ? ? ***** ? ? Frederic Heem Software Designer R&D - Telsey SpA Telecommunications Viale Industria, 1 31055 Quinto di Treviso (TV) ITALY Tel. direct phone: (+39) 0422 377819 Tel. (+39) 0422 377711 Fax. (+39) 0422 470920 website ==> www.telsey.it PRIVACY AND CONFIDENTIALITY NOTICE This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. From boris at codesynthesis.com Fri Oct 28 03:21:06 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] anonymous types In-Reply-To: <200510280922.38559.frederic.heem@telsey.it> References: <200510271855.49883.frederic.heem@telsey.it> <20051027175932.GA18997@karelia> <200510280922.38559.frederic.heem@telsey.it> Message-ID: <20051028072106.GA20660@karelia> Frederic, frederic heem writes: > It would be nice to add this question/response to the FAQ. Everyone is > not an expert in regular expression. Good idea. I will start a FAQ after 1.6.0 is out. thanks, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051028/23ed9c12/attachment.pgp From jboyden at geosci.usyd.edu.au Fri Oct 28 04:00:39 2005 From: jboyden at geosci.usyd.edu.au (James Boyden) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] xsd 1.5.0 released In-Reply-To: <20051020135702.GB5033@karelia> References: <20051020135702.GB5033@karelia> Message-ID: <20051028080039.GA17967@geosci.usyd.edu.au> On Thursday, Oct 20, Boris Kolpackov wrote: > We've released xsd 1.5.0. The NEWS file entries for this version > are as follows: > > [...] > cxx-parser > > * Support for inheritance-by-restriction in complex types. > > * "Type-less content" such as mixed content models, xsd:anyType/ > xsd:anySimpleType, and xsd:any/xsd:anyAttribute is supported > by forwarding parsing events to a set of "unexpected" hooks. > Note that only a subset of XML Schema xsd:any functionality is > supported. The compiler will issue diagnostics for unsupported > cases. See examples/cxx/parser/mixed for a code sample. Hi Boris, I only just got around to looking at xsd 1.5.0. When I ran xsd cxx-parser, to see how 1.5.0 works with the GML schemas [1], I received multiple errors of the form: .../gml/3.1.1/base/coverage.xsd:392:39: error: Recurse: There is not a complete functional mapping between the particles (complete stderr-output attached to this email) Can you explain what this error means, and what (if anything) I can do to get around it? Thanks again, James Boyden [1] For the archives -- the original thread about xsd and the GML schemas: http://codesynthesis.com/pipermail/xsd-users/2005-October/000059.html -- James Boyden GPlates Programmer and Keeper of the Flame, School of Geosciences, University of Sydney, Australia. "I find your lack of faith disturbing." -------------- next part -------------- /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:392:39: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coordinateOperations.xsd:519:62: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:421:48: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/datums.xsd:27:60: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coordinateOperations.xsd:712:70: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coordinateOperations.xsd:28:74: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:408:37: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:283:43: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/geometryPrimitives.xsd:1294:44: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/referenceSystems.xsd:25:70: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:296:45: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/geometryPrimitives.xsd:1346:53: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/datums.xsd:383:56: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:328:47: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/geometryPrimitives.xsd:1324:52: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/datums.xsd:313:60: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:315:43: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coordinateOperations.xsd:648:65: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coordinateSystems.xsd:110:71: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:264:45: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/geometryPrimitives.xsd:1362:46: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:379:43: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:360:45: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/dynamicFeature.xsd:69:32: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:347:45: error: Recurse: There is not a complete functional mapping between the particles /homes/geo/jboyden/gml/3.1.1/base/coverage.xsd:437:46: error: Recurse: There is not a complete functional mapping between the particles From boris at codesynthesis.com Fri Oct 28 04:21:08 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] xsd 1.5.0 released In-Reply-To: <20051028080039.GA17967@geosci.usyd.edu.au> References: <20051020135702.GB5033@karelia> <20051028080039.GA17967@geosci.usyd.edu.au> Message-ID: <20051028082108.GA21377@karelia> James, James Boyden writes: > I only just got around to looking at xsd 1.5.0. When I ran xsd cxx-parser, > to see how 1.5.0 works with the GML schemas [1], I received multiple errors > of the form: > .../gml/3.1.1/base/coverage.xsd:392:39: error: Recurse: There is not a complete functional mapping between the particles > > Can you explain what this error means, and what (if anything) I can do > to get around it? That's the same errors that I told you about in this email: http://codesynthesis.com/pipermail/xsd-users/2005-October/000069.html I think the right way to get rid of them is to fix the schemas. One needs to know the semantics of the types involved, but generally there are two ways to fix this: 1. Get rid of "new" elements/attribute so the restriction is valid. 2. Change "restriction" to "extension". This may result in additional errors if the type involved is, in turn, used in another restriction. The following example illustrates this case: Here, if you change restriction to extension in Derived, Dependent* hierarchy will blow. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051028/29f28e8f/attachment.pgp From boris at codesynthesis.com Fri Oct 28 04:25:26 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] xsd 1.5.0 released In-Reply-To: <20051028082108.GA21377@karelia> References: <20051020135702.GB5033@karelia> <20051028080039.GA17967@geosci.usyd.edu.au> <20051028082108.GA21377@karelia> Message-ID: <20051028082526.GB21377@karelia> Boris Kolpackov writes: > > > > > This, of course, should be -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051028/2f5f7363/attachment.pgp From frederic.heem at telsey.it Fri Oct 28 06:45:53 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] exception declaration Message-ID: <200510281245.54038.frederic.heem@telsey.it> Hi, At the moement, the following code is used to parse an xml file into c++ object: std::string fileConf("pippo.xml"); try { m_pLidConf = (LidConf (fileConf)); } catch (...){ PTRACE(1,"HT MAN\tInitialiseLid configuration not valid"); return FALSE; } The try catch statement catch any exceptions (catch (...)), is it possible to get in the generated header file the kind of exception thrown ? In java the throws keyword is compulsory in the function prototype but I don't think it is in C++. -- ***** ? ? ----- ? ? ***** ? ? ----- ? ? ***** ? ? Frederic Heem Software Designer R&D - Telsey SpA Telecommunications Viale Industria, 1 31055 Quinto di Treviso (TV) ITALY Tel. direct phone: (+39) 0422 377819 Tel. (+39) 0422 377711 Fax. (+39) 0422 470920 website ==> www.telsey.it PRIVACY AND CONFIDENTIALITY NOTICE This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. From boris at codesynthesis.com Fri Oct 28 07:11:57 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] exception declaration In-Reply-To: <200510281245.54038.frederic.heem@telsey.it> References: <200510281245.54038.frederic.heem@telsey.it> Message-ID: <20051028111157.GA23615@karelia> Frederic, frederic heem writes: > At the moement, the following code is used to parse an xml file into c++ > object: > std::string fileConf("pippo.xml"); > try { > m_pLidConf = (LidConf (fileConf)); > } catch (...){ > PTRACE(1,"HT MAN\tInitialiseLid configuration not valid"); > return FALSE; > } > > The try catch statement catch any exceptions (catch (...)), is it possible > to get in the generated header file the kind of exception thrown ? In java > the throws keyword is compulsory in the function prototype but I don't > think it is in C++. I am not quite sure what you mean here. Do you want to catch specific exceptions? If so they are defined in libxsd/xsd/cxx/tree/exceptions.hxx (can be found in /usr/include/xsd/cxx/tree/exceptions.hxx if installed) and also aliased (typedef'ed) in the generated header files (look for 'namespace xml_schema'). All exceptions thrown by C++/Tree mapping are derived from xml_schema::exception so if you want to catch any exception thrown by xsd-generated code, you can write something like this: try { m_pLidConf = (LidConf (fileConf)); } catch (xml_schema::exception const& ex) { PTRACE(1, "HT MAN\tInitialiseLid configuration not valid: %s", ex.what ()); } hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051028/ed83124e/attachment.pgp From boris at codesynthesis.com Sat Oct 29 09:42:34 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] Re: lid_test, no regression test In-Reply-To: <200510281825.32466.frederic.heem@telsey.it> References: <200510281825.32466.frederic.heem@telsey.it> Message-ID: <20051029134234.GA26904@karelia> Frederic, I've CC'ed the mailing list to allow others to benefit from this information. frederic heem writes: > Another problem has been found, the attibute value of lidLine are > incorrect, they are all equal to 1. Compare the content of the > lid_conf.xml anf the output of the program to verify. In your definition of LidLine type, both attributes are optional: This means that when you call LidLine::port or LidLine::name you get a container, not the object itself. So when you wrote: cout << "port number = " << lidLineIt->port() << endl; cout << "port name = " << lidLineIt->name() << endl; You were actually trying to print the container, not the object itself. The container for optional elements/attributes (cardinality 0..1) happened to have implicit conversion to bool (so that it can be used inside if () statements, etc.). Therefore what you are printing above is the true/false value which indicated whether the port/name has been specified. Try to change it to something like this: if (lidLineIt->port()) cout << "port number = " << *lidLineIt->port() << endl; if (lidLineIt->name()) cout << "port name = " << *lidLineIt->name() << endl; Alternatively, you can make the attributes mandatory: In the next version of xsd I will overload operator<< for the optional container so that it will print the object if it is set and something like "" if not. Hopefully it will be less confusing. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051029/5cd8a7ca/attachment.pgp From jboyden at geosci.usyd.edu.au Sun Oct 30 06:03:06 2005 From: jboyden at geosci.usyd.edu.au (James Boyden) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] xsd 1.5.0 released In-Reply-To: <20051028082108.GA21377@karelia> References: <20051020135702.GB5033@karelia> <20051028080039.GA17967@geosci.usyd.edu.au> <20051028082108.GA21377@karelia> Message-ID: <20051030110306.GA26936@geosci.usyd.edu.au> On Friday, Oct 28, Boris Kolpackov wrote: > That's the same errors that I told you about in this email: > > http://codesynthesis.com/pipermail/xsd-users/2005-October/000069.html Ah, thanks. I must have not noticed the attachment (containing the exact same errors, even in the same order!) when I read that email last time. > I think the right way to get rid of them is to fix the schemas. One > needs to know the semantics of the types involved, but generally there > are two ways to fix this: > > 1. Get rid of "new" elements/attribute so the restriction is valid. > > 2. Change "restriction" to "extension". This may result in additional > errors if the type involved is, in turn, used in another restriction. > The following example illustrates this case: Since xsd must know which elements/attributes are invalid (since it is performing the checks), would it be possible for xsd to provide more verbose, descriptive errors which specify the invalid elements/attributes by name? Then it would be much more straight-forward to fix the problems directly. -- James Boyden GPlates Programmer and Keeper of the Flame, School of Geosciences, University of Sydney, Australia. "I find your lack of faith disturbing." From boris at codesynthesis.com Mon Oct 31 01:28:56 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] xsd 1.5.0 released In-Reply-To: <20051030110306.GA26936@geosci.usyd.edu.au> References: <20051020135702.GB5033@karelia> <20051028080039.GA17967@geosci.usyd.edu.au> <20051028082108.GA21377@karelia> <20051030110306.GA26936@geosci.usyd.edu.au> Message-ID: <20051031062856.GA31509@karelia> James, James Boyden writes: > Since xsd must know which elements/attributes are invalid (since it is > performing the checks), would it be possible for xsd to provide more > verbose, descriptive errors which specify the invalid elements/attributes > by name? At the moment xsd uses Xerces-C++ to perform schema validation. So most diagnostics messages come from Xerces, not xsd. I agree that this particular message is not very descriptive. I will check if I can replace it with something more meaningful. Unfortunately, I don't think I will be able to show which elements/attributes caused the error. Unless we implement our own diagnostics, that is ;-). hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051031/12de4ae4/attachment.pgp From frederic.heem at telsey.it Mon Oct 31 04:21:11 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] memory not deallocated ? Message-ID: <200510311021.11967.frederic.heem@telsey.it> Hi boris, lid_conf.xsd and driver.cxx has been changed, only the attribute name is optional. When program is executed under the control of valgrind, it shows that some memory hasn't been deallocated. I reckon this memory is allocated once for the whole life of the program, so it may be NOT a memory leak. However, I do prefer having a program which deallocate everything so that "real" memory leak can be detected quicker. [heefre@heefre lid_conf]$ valgrind --tool=memcheck --leak-check=full driver lid_conf.xml ==12600== Memcheck, a memory error detector. ==12600== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==12600== Using LibVEX rev 1367, a library for dynamic binary translation. ==12600== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==12600== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==12600== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==12600== For more details, rerun with: -v ==12600== card name = voicetronix, cardNumber = 0 port number = 0 port name = line1 port number = 1 port name = line2 card name = dialogic, cardNumber = 1 port number = 3 port name = line3 port number = 4 port name = line4 ==12600== ==12600== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 32 from 4) ==12600== malloc/free: in use at exit: 2388 bytes in 63 blocks. ==12600== malloc/free: 1840 allocs, 1777 frees, 607290 bytes allocated. ==12600== For counts of detected errors, rerun with: -v ==12600== searching for pointers to 63 not-freed blocks. ==12600== checked 342308 bytes. ==12600== ==12600== 1620 bytes in 31 blocks are possibly lost in loss record 3 of 3 ==12600== at 0x1B900C18: operator new(unsigned) (vg_replace_malloc.c:164) ==12600== by 0x1BCE6851: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.3) ==12600== by 0x1BCE8CD4: (within /usr/lib/libstdc++.so.6.0.3) ==12600== by 0x1BCE8DE1: std::string::string(char const*, std::allocator const&) (in /usr/lib/libstdc++.so.6.0.3) ==12600== by 0x8060532: xsd::cxx::tree::type_factory_initializer<0l, char, lid::LidLine>::type_factory_initializer(char const*) (type-factory-map.hxx:124) ==12600== by 0x80519CE: __static_initialization_and_destruction_0(int, int) (lid_conf.cxx:149) ==12600== by 0x8051A48: _GLOBAL__I__ZN3lid7LidLineC2ERKj (lid_conf.cxx:452) ==12600== by 0x80646D0: (within /home/heefre/software/cti/cxx/tree/lid_conf/driver) ==12600== by 0x804A544: (within /home/heefre/software/cti/cxx/tree/lid_conf/driver) ==12600== by 0x8064639: __libc_csu_init (in /home/heefre/software/cti/cxx/tree/lid_conf/driver) ==12600== by 0x1BD71DD0: __libc_start_main (in /lib/tls/libc-2.3.5.so) ==12600== by 0x804AAA8: (within /home/heefre/software/cti/cxx/tree/lid_conf/driver) ==12600== ==12600== LEAK SUMMARY: ==12600== definitely lost: 0 bytes in 0 blocks. ==12600== possibly lost: 1620 bytes in 31 blocks. ==12600== still reachable: 768 bytes in 32 blocks. ==12600== suppressed: 0 bytes in 0 blocks. ==12600== Reachable blocks (those to which a pointer was found) are not shown. ==12600== To see them, rerun with: --show-reachable=yes -- ***** ? ? ----- ? ? ***** ? ? ----- ? ? ***** ? ? Frederic Heem Software Designer R&D - Telsey SpA Telecommunications Viale Industria, 1 31055 Quinto di Treviso (TV) ITALY Tel. direct phone: (+39) 0422 377819 Tel. (+39) 0422 377711 Fax. (+39) 0422 470920 website ==> www.telsey.it PRIVACY AND CONFIDENTIALITY NOTICE This email and any attachments are confidential and are intended for the addressee only. If you have received this message by mistake, please contact us immediately and then delete the message from your system. You must not copy, distribute, disclose or act upon the contents of this email. From boris at codesynthesis.com Mon Oct 31 04:27:30 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:41 2009 Subject: [xsd-users] memory not deallocated ? In-Reply-To: <200510311021.11967.frederic.heem@telsey.it> References: <200510311021.11967.frederic.heem@telsey.it> Message-ID: <20051031092730.GA2727@karelia> frederic heem writes: > When program is executed under the control of valgrind, it shows that some > memory hasn't been deallocated. I reckon this memory is allocated once for > the whole life of the program, so it may be NOT a memory leak. However, I > do prefer having a program which deallocate everything so that "real" > memory leak can be detected quicker. What you see is a type factory map which is created during static object initialization and is there for the life-time of the program. I guess you are right and it is better to destroy it if only to keep memory checkers at bay. I will fix this for the release. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20051031/026db528/attachment.pgp