From boris at codesynthesis.com Fri Sep 2 10:04:59 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd 1.2.0 released Message-ID: <20050902140459.GB5640@karelia> Good day, We've released xsd 1.2.0. The NEWS file entries for this version are as follows: cxx-parser * New backend that generates the C++/Parser mapping. 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: ead5e578a011fc1f5ec5489370b097abf2778f9b xsd-1.2.0.tar.bz2 52862db2d73a7925545ed0bafd60124dc9129f31 xsd_1.2.0-1_i386.deb 2a969807739219aefa3bb15d4e1c500600980d42 xsd-1.2.0-1.i686.rpm 5e810da3b625f0a854b2eecfc359ab9ecd693c05 xsd-1.2.0-i686-linux-gnu.tar.bz2 f751bca5f5f1096b2887d9448ab8d9da12541338 xsd_1.2.0-1_amd64.deb 7877a0581c3015d0dc743af8fe9033f76c925c9c xsd-1.2.0-1.x86_64.rpm d3abf195bcf5673031274fa924bb40d84ec641dd xsd-1.2.0-x86_64-linux-gnu.tar.bz2 db81bf22a8074f578c5c95c42f199ff9e3261a1f xsd-1.2.0-powerpc-macosx.tar.bz2 66f2cf2804355e77409c87b9a26b808161fad0dd xsd-1.2.0-i686-windows.zip have fun, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050902/5397d367/attachment.pgp From frederic.heem at telsey.it Mon Sep 5 09:54:30 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] include problem Message-ID: <200509051554.30854.frederic.heem@telsey.it> Hi, A problem has been found in the xsd compiler (version 1.2.0 on fc3), basically, h323_types contains all type used by h323_conf.xsd. I need to separate in 2 files because jaxb is also used to generate java object. It works fine when everthing is in one files. Please find attached the 2 xsd files and the gdb backtrace. Anyway, I appreciate a lot this software, because I don't need to bother writing my own sax or dom handler. Let me know if you need more info. Regards, Frederic Heem #0 0x0010d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) bt #0 0x0010d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0014e7d5 in raise () from /lib/tls/libc.so.6 #2 0x00150149 in abort () from /lib/tls/libc.so.6 #3 0x083b8f31 in __gnu_cxx::__verbose_terminate_handler () at ../../../../src/gcc-3.4.4/libstdc++-v3/libsupc++/vterminate.cc:96 #4 0x083b6225 in __cxxabiv1::__terminate (handler=0x83b8e30 <__gnu_cxx::__verbose_terminate_handler()>) at ../../../../src/gcc-3.4.4/libstdc++-v3/libsupc++/eh_terminate.cc:43 #5 0x083b6262 in std::terminate () at ../../../../src/gcc-3.4.4/libstdc++-v3/libsupc++/eh_terminate.cc:53 #6 0x083b63e2 in __cxa_throw (obj=0x8791788, tinfo=0x0, dest=0) at ../../../../src/gcc-3.4.4/libstdc++-v3/libsupc++/eh_throw.cc:80 #7 0x083b53a5 in __cxa_bad_cast () at typeinfo:138 #8 0x081a1508 in XSDFrontend::(anonymous namespace)::resolve () at basic_string.tcc:243 #9 0x081aaf91 in XSDFrontend::Parser::Impl::set_type () at basic_string.tcc:243 #10 0x081957fc in XSDFrontend::Parser::Impl::element () at basic_string.tcc:243 #11 0x0819cf4a in XSDFrontend::Parser::Impl::schema () at basic_string.tcc:243 #12 0x0819eec1 in XSDFrontend::Parser::Impl::parse () at basic_string.tcc:243 #13 0x0819fe02 in XSDFrontend::Parser::parse () at basic_string.tcc:243 #14 0x08060fc1 in main () -------------- next part -------------- A non-text attachment was scrubbed... Name: h323_types.xsd Type: application/xml Size: 2230 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050905/a3291486/h323_types.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: h323_conf.xsd Type: application/xml Size: 2337 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050905/a3291486/h323_conf.xml From boris at codesynthesis.com Mon Sep 5 10:40:43 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] include problem In-Reply-To: <200509051554.30854.frederic.heem@telsey.it> References: <200509051554.30854.frederic.heem@telsey.it> Message-ID: <20050905144043.GA3272@karelia> Frederic, frederic heem writes: > A problem has been found in the xsd compiler (version 1.2.0 on fc3), > basically, h323_types contains all type used by h323_conf.xsd. > I need to separate in 2 files because jaxb is also used to generate java > object. It works fine when everthing is in one files. I tracked down and fixed this bug. If you don't want to wait for the next release, I can send you the binary (just let me know which platforms and if it is ok to send it via email). 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/20050905/ac9d65ed/attachment.pgp From boris at codesynthesis.com Wed Sep 7 05:24:20 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] tools generating classes from schema Message-ID: <20050907092420.GB10267@karelia> Good day, There was a post on the xmlschema-dev@w3.org mailing list where its author provided a list of features and asked for feedback on how well various data binding tools support those features. I provided the information for xsd which some people on this list may find interesting. The archive of the thread is available at http://lists.w3.org/Archives/Public/xmlschema-dev/2005Sep/0002.html My reply is quoted below. -boris ----- Forwarded message from Boris Kolpackov ----- From: Boris Kolpackov Subject: Re: tools generating classes from schema Date: Wed, 7 Sep 2005 11:09:10 +0200 To: Paul Kiel Cc: xmlschema-dev@w3.org, wsinterop@lists.hr-xml.org [Apologies if this is the second copy you received.] Paul, Here is the information about xsd, an XML Schema to C++ translator. You can find out more about this tool at http://codesynthesis.com/products/xsd/ Paul Kiel writes: > The key constructs that cause problems when creating classes are: > > 1) xsd:union. - This is the least supported feature of our schemas. We > had already been considering removing these as bad design anyway, so > this may add some force to that effort. This is not supported. > 2) xsd:pattern - This is supported by some tools and not others. This is supported. > 3) having an element and a type with the same name. There are two cases to consider. The first is when a global element and a global type have the same name, e.g., This case is supported. The other case is when a type and an element inside this type have the same name: This case is not supported. > (also a problem even if casing is different, as in a "MyType" element and > a "mytype" attribute) There is no such problem in xsd. > 4) recursive content models This is supported. > Other oddities that only cause problems in some tools: > > 5) extension of complexTypes - XSDObjectGen in particular has a problem > with this, which seems odd as this is a major design feature of xml schema. Works as expected. > 6) simpleContent extension using a xsd base type Works as expected. > 7) reserved keyword element names (such as "Value") All identifiers are properly escaped. Note that besides keywords, you may also want to check for characters that are illegal in identifiers in most programming languages but legal in XML Schema (e.g., '-'). > 8) too many anonymous types can lead to some class name collisions when > classes are generated There is no such problem in xsd since all anonymous types are mapped to nested types (i.e., we don't "flatten" the object model). For example, this XML Schema definition ... will result in the following C++ class definitions: class hello { class name { ... }; ... }; > 9) enumerations in elements (enumerations in attributes worked fine. > wierd but true for a tool to remain nameless) Works as expected. Also note that we map XML Schema enumerations to C++ enums. > Here are features we don't even use, so we can't comment on (but suspect > there may be possible problems): > > A) substitutionGroups Not yet supported. We however plan to support this along with other instance polymorphism mechanisms (e.g., xsi:type). > B) redefine Not supported. Note that this is one of the "questionable" features of XML Schema (along with unions, as you pointed out) that don't map cleanly to the target programming language. > C) abstract types Somewhat supported. Right now we simply ignore this attribute since it is more of a validation feature. I guess we could make the generated d-tor pure virtual to make the type non-instantiable. > D) nillable Can be supported should there be any interest. > E) complexType restriction Not supported. There is no natural mapping of this feature to the object model of the target programming language. In particular, if we map restriction to inheritance then we break the substitutability principle (the derived-by-restriction type is-not-a base type). Probably the best approach would be to generate a completely unrelated type. > F) list types Can be supported should there be any interest. You may also want to check the "planned feature list": http://codesynthesis.com/projects/xsd/documentation/future.xhtml hth, -boris ----- End forwarded message ----- -------------- 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/20050907/7e29d86f/attachment.pgp From mgusarov at sw-soft.com Thu Sep 8 02:22:58 2005 From: mgusarov at sw-soft.com (Mikhail Gusarov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xs:annotation trouble Message-ID: <877jdsrscd.fsf@origin.plesk.ru> Hello, xsd (1.2.0, linux-x86) SIGSEGVs on the following schema: -- Mikhail Gusarov ICQ UIN: 111575219 JID: dottedmag@jabber.fanstvo.com From boris at codesynthesis.com Thu Sep 8 03:18:21 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xs:annotation trouble In-Reply-To: <877jdsrscd.fsf@origin.plesk.ru> References: <877jdsrscd.fsf@origin.plesk.ru> Message-ID: <20050908071821.GA15400@karelia> Mikhail, Mikhail Gusarov writes: > xsd (1.2.0, linux-x86) SIGSEGVs on the following schema: > > > > > > > Confirmed and fixed. I am not planning to release a new version until the end of the next week. Do you want me to send a fixed binary for the time being? If so then let me know which platform/package and if it is ok to send by email. 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/20050908/94ba774e/attachment.pgp From boris at codesynthesis.com Fri Sep 9 05:09:31 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] key/keyref, anonymous types in C++/Parser mapping In-Reply-To: <4320685F.9040608@mesiog.obspm.fr> References: <431EE96E.1010809@mesiog.obspm.fr> <20050907141815.GA11985@karelia> <4320685F.9040608@mesiog.obspm.fr> Message-ID: <20050909090931.GA24844@karelia> Frederic, badia writes: > > You mean the xsd:key/xsd:keyref constructs of XML Schema? > > > yes This is not yet supported by xsd. However we are interested in how you use it and what kind of mapping would you expect from xsd. Are you interested in validation only? Would you like information about xsd:key/xsd:keyref associations appear in the mapping, similar to what is provided for ID/IDREF? > We just had a quick look to xsd so far; what looks really convenient is > that it's event oriented instead of dom-like if I understood well. There are actually two mappings: C++/Tree and C++/Parser. C++/Tree is a "conventional" binding for XML Schema which is, as you pointed out, is DOM-like. C++/Parser is an event oriented, SAX-like mapping. It is your choice which one two use for any particular type of application. > One problem that we encountered is that we had to move out the complex > types from the element definitions in our schemas, apparently xsd > complains if the type is defined inside the element, or didn't you have > this problem ? You are right, C++/Parser doesn't support anonymous types yet (though C++/Tree does). We plan to support this by the next release (due end of the next week or so). Though note that explicitly naming your types is always cleaner. > If we keep contact, I will probably ask you some other funny questions > about xsd ... No problem. Just one request: could you please send it to the xsd-users@codesynthesis.com mailing list instead of to me directly; this way other can benefit from our discussions. 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/20050909/61ddf8fa/attachment.pgp From boris at codesynthesis.com Fri Sep 9 06:26:11 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] key/keyref, anonymous types in C++/Parser mapping In-Reply-To: <20050909090931.GA24844@karelia> References: <431EE96E.1010809@mesiog.obspm.fr> <20050907141815.GA11985@karelia> <4320685F.9040608@mesiog.obspm.fr> <20050909090931.GA24844@karelia> Message-ID: <20050909102611.GA25794@karelia> Boris Kolpackov writes: > > > You mean the xsd:key/xsd:keyref constructs of XML Schema? > > > > > yes > > This is not yet supported by xsd. Well, I guess saying that it is not supported is completely accurate. Validation part of xsd:key/xsd:unique/xsd:keyref is supported but there is no mapping between these constructs and the target programming language. 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/20050909/7163e64f/attachment.pgp From vera.mickael at free.fr Mon Sep 12 07:58:41 2005 From: vera.mickael at free.fr (Vera Mickael) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Question about ID/IDREF Message-ID: <43256D71.7090508@free.fr> Hi, I use JAXB I may use the same kind of tool in C++. I have a problem with JAXB, I'd like to know if I would have the same problem with xsd. Each time I use ID and IDREF, the method in the generated model for the attribute that uses IDREF returns a java.lang.Object. This makes the generated model very difficult to use. Does xsd generate the same (a method that returns void *) ? Or is there a way to specify the type of the element referenced by IDREF, by annotations for example ? Micka?l From vera.mickael at free.fr Mon Sep 12 08:16:33 2005 From: vera.mickael at free.fr (Vera Mickael) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Schema and inheritance Message-ID: <432571A1.2050004@free.fr> Hi, I have another question about schema and inheritance : I have problems with the code generated by JAXB when we use inheritance in our schemas. Tell me if I'm wrong but I think inheritance is not really supported by schema. Suppose I define an element type A and another one B that extends A and another one C that extends A. In my schema if I define another element type X that contains A, I can't use B or C in an XML file instead of A in an element of type X. So we use another element type that is a choice between B and C, and wherever we want B or C in the schema we use the choice. The generated code is very ugly, we obtain something close to a union in C langage. How does xsd handle this problem ? I want to describe a model with two or more classes that extend a class, what is important to me is the quality of the generated code, polymorphism in this case. Micka?l From boris at codesynthesis.com Mon Sep 12 08:38:00 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Question about ID/IDREF In-Reply-To: <43256D71.7090508@free.fr> References: <43256D71.7090508@free.fr> Message-ID: <20050912123800.GB3154@karelia> Mickael, Vera Mickael writes: > Each time I use ID and IDREF, the method in the generated > model for the attribute that uses IDREF returns a > java.lang.Object. This makes the generated model very > difficult to use. Ok, you mean you have to manually cast it to a concrete type. > Does xsd generate the same (a method that returns void *) ? At the moment, xsd generates a member function that returns a pointer to a type that all generated types inherit from (similar to java.lang.Object). You have to cast this pointer to a concrete one. > Or is there a way to specify the type of the element > referenced by IDREF, by annotations for example ? Not at the moment but we have plans to do so. The idea is to have an attribute that you can use to specify the "real type" of IDREF, e.g.: ... ... Then you will be able to write something like this: author a = ... cerr << a.recommends ()->title () << endl; Would you be interested in something like 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/20050912/897c3835/attachment.pgp From boris at codesynthesis.com Mon Sep 12 09:35:34 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Schema and inheritance In-Reply-To: <432571A1.2050004@free.fr> References: <432571A1.2050004@free.fr> Message-ID: <20050912133534.GC3154@karelia> Mickael, Vera Mickael writes: > Tell me if I'm wrong but I think inheritance is not really > supported by schema. Suppose I define an element type A and > another one B that extends A and another one C that extends > A. In my schema if I define another element type X that > contains A, I can't use B or C in an XML file instead of A > in an element of type X. There are two ways to do this in XML Schema: xsi:type or substitution groups. xsi:type is the simplest of the two but it requires you to explicitly specify the type of the element in the instance document. Suppose we have the following schema: In the instance document we can have something like this: Boris Kolpackov Boris Kolpackov Substitution groups are much more elaborate (on the schema level). In this case you use different element names to convey the type information. Here is an example schema (assuming definitions of Person and Superman from above): In the instance document we can have something like this: Boris Kolpackov Boris Kolpackov > So we use another element type that is a choice between B > and C, and wherever we want B or C in the schema we use the > choice. The generated code is very ugly, we obtain something > close to a union in C langage. > For the following schema the code that uses xsd-generated mapping would look like this: PersonOrSuperman ps = ... if (ps.person.present ()) { Person p = ps.person (); } else { Superman s = ps.superman (); } Not very pretty, I agree. > How does xsd handle this problem ? I want to describe a > model with two or more classes that extend a class, what is > important to me is the quality of the generated code, > polymorphism in this case. > Those are actually very interesting questions. As you can see from above, XML Schema does have provisions for instance (data) polymorphism. The question that you probably would like to ask is how we can take advantage of this in a language mapping (binding). The problem is that the data polymorphism is quite useless without the behavior polymorphism which can take advantage of this extra data. Here is what I mean. Suppose, for the schema above, we have the following mapping: struct Person { string name () const; }; struct Superman: Person { bool can_fly () const; }; struct BusinessCard { Person& person (); }; Here BusinessCard::person can return a reference to either a Person or a Superman. The question is how is this useful to us? Since there is no behavior associated with Person or Superman (they are both "pure data" types), there is no real use to this feature. There is no way to get hold of the can_fly() other than explicit casting which is not any better than the choice approach you described above. I am still thinking about this but at the moment I can't see how XML Schema provisions for polymorphism can be useful in the language mapping. 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/20050912/dfbe600e/attachment.pgp From vera.mickael at free.fr Mon Sep 12 09:55:13 2005 From: vera.mickael at free.fr (Vera Mickael) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Question about ID/IDREF In-Reply-To: <20050912123800.GB3154@karelia> References: <43256D71.7090508@free.fr> <20050912123800.GB3154@karelia> Message-ID: <432588C1.4050306@free.fr> Boris Kolpackov a ?crit : > Mickael, > > Vera Mickael writes: > > >>Each time I use ID and IDREF, the method in the generated >>model for the attribute that uses IDREF returns a >>java.lang.Object. This makes the generated model very >>difficult to use. > > > Ok, you mean you have to manually cast it to a concrete type. > > > >>Does xsd generate the same (a method that returns void *) ? > > > At the moment, xsd generates a member function that returns > a pointer to a type that all generated types inherit from > (similar to java.lang.Object). You have to cast this pointer > to a concrete one. > > >>Or is there a way to specify the type of the element >>referenced by IDREF, by annotations for example ? > > > Not at the moment but we have plans to do so. The idea is > to have an attribute that you can use to specify the "real > type" of IDREF, e.g.: > > > > ... > > type="xsd:IDREF" > ref-type="lib:book"/> > > > > > > > > ... > > > > > > > > Then you will be able to write something like this: > > author a = ... > > cerr << a.recommends ()->title () << endl; > > > Would you be interested in something like this? > > -boris > Your solution with ref-type attribute is better than using annotations :-) Yes I would be interested in such a feature, I'm kind on statically typed programmation and JAXB really lacks about this. It makes it really difficult to change the schema. It would be a feature usefull for everybody. This question raises another one. I'd like to use xsd as a simple serialization tool, my point of view is model centric : I know the model I want (thus the C++ code I need) then I write the corresponding XML schema. How would you write a schema for a collection of IDREF without using an intermediate element ? If I use your exemple, I'd like to have a method like this : std::vector & author::recommends(); My only idea is to create a element bookRef with an attribute referencing a book and use this element bookRef in a sequence in the element author. I guess that I would have the following code that isn't as elegant as the previous : std::vector & author::recommends(); Thanks for your answer, Micka?l From boris at codesynthesis.com Mon Sep 12 10:51:50 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Question about ID/IDREF In-Reply-To: <432588C1.4050306@free.fr> References: <43256D71.7090508@free.fr> <20050912123800.GB3154@karelia> <432588C1.4050306@free.fr> Message-ID: <20050912145150.GA3732@karelia> Mickael, Vera Mickael writes: > Your solution with ref-type attribute is better than using > annotations :-) > > Yes I would be interested in such a feature, I'm kind on > statically typed programmation and JAXB really lacks about > this. It makes it really difficult to change the schema. It > would be a feature usefull for everybody. Ok, I will let you know when I have something for you to try. This will most likely happen some time next week. > I'd like to use xsd as a simple serialization tool, my point > of view is model centric : I know the model I want (thus the > C++ code I need) then I write the corresponding XML schema. > > How would you write a schema for a collection of IDREF > without using an intermediate element ? If I use your > exemple, I'd like to have a method like this : > > std::vector & > author::recommends(); How about using IDREFS built-in type? It is a space-separated list of IDREF. It is mapped exactly to vector. I will implement ref-type attribute for both IDREF and IDREFS. 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/20050912/343126c0/attachment.pgp From vera.mickael at free.fr Mon Sep 12 11:31:20 2005 From: vera.mickael at free.fr (Vera Mickael) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Schema and inheritance In-Reply-To: <20050912133534.GC3154@karelia> References: <432571A1.2050004@free.fr> <20050912133534.GC3154@karelia> Message-ID: <43259F48.3070402@free.fr> Boris Kolpackov a ?crit : > Mickael, > > Vera Mickael writes: > > >>Tell me if I'm wrong but I think inheritance is not really >>supported by schema. Suppose I define an element type A and >>another one B that extends A and another one C that extends >>A. In my schema if I define another element type X that >>contains A, I can't use B or C in an XML file instead of A >>in an element of type X. > > > There are two ways to do this in XML Schema: xsi:type or > substitution groups. > > xsi:type is the simplest of the two but it requires you to explicitly > specify the type of the element in the instance document. Suppose > we have the following schema: > > > > > > > > > > > > > > > > > > In the instance document we can have something like this: > > > Boris Kolpackov > > > > Boris Kolpackov > > > > Substitution groups are much more elaborate (on the schema level). > In this case you use different element names to convey the type > information. Here is an example schema (assuming definitions of > Person and Superman from above): > > > > > > > > > > > > In the instance document we can have something like this: > > > > Boris Kolpackov > > > > > > Boris Kolpackov > > > > >>So we use another element type that is a choice between B >>and C, and wherever we want B or C in the schema we use the >>choice. The generated code is very ugly, we obtain something >>close to a union in C langage. >> > > > For the following schema > > > > > > > > the code that uses xsd-generated mapping would look like this: > > PersonOrSuperman ps = ... > > if (ps.person.present ()) > { > Person p = ps.person (); > } > else > { > Superman s = ps.superman (); > } > > Not very pretty, I agree. > > > >>How does xsd handle this problem ? I want to describe a >>model with two or more classes that extend a class, what is >>important to me is the quality of the generated code, >>polymorphism in this case. >> > > > Those are actually very interesting questions. As you can see > from above, XML Schema does have provisions for instance (data) > polymorphism. The question that you probably would like to ask > is how we can take advantage of this in a language mapping > (binding). The problem is that the data polymorphism is quite > useless without the behavior polymorphism which can take advantage > of this extra data. > > Here is what I mean. Suppose, for the schema above, we have > the following mapping: > > struct Person > { > string > name () const; > }; > > struct Superman: Person > { > bool > can_fly () const; > }; > > struct BusinessCard > { > Person& > person (); > }; > > Here BusinessCard::person can return a reference to either a Person > or a Superman. The question is how is this useful to us? Since > there is no behavior associated with Person or Superman (they are > both "pure data" types), there is no real use to this feature. > There is no way to get hold of the can_fly() other than explicit > casting which is not any better than the choice approach you > described above. I am still thinking about this but at the moment > I can't see how XML Schema provisions for polymorphism can be > useful in the language mapping. > > hth, > -boris > Thank you very much for your explanations about XSD and inheritance. About polymorphism, BusinessCard::person returning a person may be intersting if the code manipulates a person for its common attributes. I agree the interest may be limited. I've been thinking about those problems for a long time. I did not found any satisfying solution. I guess you thought about a factory provided by the user. One solution would be to provide a factory at parsing time, each time the parser needs to instantiate an obect it asks the factory to do it. The user may have its own classes instanciated or the factory instanciates the default generated classes. User classes inherit from generated classes. The major problem is that generated classes use relations to generated classes, the user stil have to cast to its own classes. The second solution is to provide a factory at generation time. This way the parser generator can generate relations to user classes. The problem is that you have circular dependencies between the classes generated and the user classes. I use components and I can't have circular dependencies between components. I didn't think more about it as I worked with Java and these solutions use multiple inheritance. I think the second solution can be implemented in C++. Micka?l From vera.mickael at free.fr Mon Sep 12 11:57:07 2005 From: vera.mickael at free.fr (Vera Mickael) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Question about ID/IDREF In-Reply-To: <20050912145150.GA3732@karelia> References: <43256D71.7090508@free.fr> <20050912123800.GB3154@karelia> <432588C1.4050306@free.fr> <20050912145150.GA3732@karelia> Message-ID: <4325A553.9090803@free.fr> Boris Kolpackov a ?crit : > Mickael, > > Vera Mickael writes: > > >>Your solution with ref-type attribute is better than using >>annotations :-) >> >>Yes I would be interested in such a feature, I'm kind on >>statically typed programmation and JAXB really lacks about >>this. It makes it really difficult to change the schema. It >>would be a feature usefull for everybody. > > > Ok, I will let you know when I have something for you to try. > This will most likely happen some time next week. > > > >>I'd like to use xsd as a simple serialization tool, my point >>of view is model centric : I know the model I want (thus the >>C++ code I need) then I write the corresponding XML schema. >> >>How would you write a schema for a collection of IDREF >>without using an intermediate element ? If I use your >>exemple, I'd like to have a method like this : >> >>std::vector & >>author::recommends(); > > > How about using IDREFS built-in type? It is a space-separated > list of IDREF. It is mapped exactly to vector. I will > implement ref-type attribute for both IDREF and IDREFS. Great :-) I'll try your product tonight. Micka?l From badia at mesiog.obspm.fr Mon Sep 12 12:04:36 2005 From: badia at mesiog.obspm.fr (badia) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] suggestions Message-ID: <4325A714.30904@mesiog.obspm.fr> Hy there ! We have done a little bit of digging in xsd and there is a couple of suggestions that I'd like to point out. First, xsd complains a lot about our xsd schemas syntax. Apart from the things I mentioned to Boris so far, there is a new one concerning the list element, I'm sending an attachment of a schema example which contains one. Second thing is it would be nice to see xsd generating a makefile and a reader for the C++ classes just like xbinder does but I don't really know what your schedule is and how much time you would be prepared to spend on that ... Regards Frederic Badia -------------- next part -------------- A non-text attachment was scrubbed... Name: table1v4.xsd Type: text/xml Size: 7388 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050912/5e9c26cf/table1v4.bin From boris at codesynthesis.com Tue Sep 13 05:08:29 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] suggestions In-Reply-To: <4325A714.30904@mesiog.obspm.fr> References: <4325A714.30904@mesiog.obspm.fr> Message-ID: <20050913090829.GA7691@karelia> Frederic, badia writes: > First, xsd complains a lot about our xsd schemas syntax. Apart from the > things I mentioned to Boris so far, there is a new one concerning the > list element, I'm sending an attachment of a schema example which > contains one. xsd:list construct is not yet supported by xsd. This feature is of very limited use (since it can only be used with certain types and uses space as delimiter) so it has somewhat lower priority on our list. Would that be possible for you to use sequence instead? This solution is a bit more verbose in the instance document (i.e., you have "1 2 3" instead of "1 2 3") but it is much more flexible. As of the problem with the anonymous types, we are working on the morphing backend that will automatically "name" anonymous types. It will appear in the next release which is due later this week or early next week. > Second thing is it would be nice to see xsd generating a makefile and a > reader for the C++ classes just like xbinder does but I don't really > know what your schedule is and how much time you would be prepared to > spend on that ... I am not quite sure what you mean by "reader". As of the makefiles, we think this feature will be of a limited use. Most projects have their own build systems with their own ways of writing makefiles, etc. If all you need is a temporary makefile just to try things out then it is quite easy to copy one of the makefiles found in the examples directory and modify it to your needs. One makefile-related thing that we do plan to implement is automatic dependency generation, similar to what gcc -M does. 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/20050913/f17ade27/attachment.pgp From badia at mesiog.obspm.fr Tue Sep 13 11:05:47 2005 From: badia at mesiog.obspm.fr (badia) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] About xsd list In-Reply-To: <20050913090829.GA7691@karelia> References: <4325A714.30904@mesiog.obspm.fr> <20050913090829.GA7691@karelia> Message-ID: <4326EACB.9010606@mesiog.obspm.fr> Dear xsd users About xsd list, we agree that all the items in a list are of the same primitive data type and any value inside an xml tag is considered as a single element. What we do is that we take advantage of this last characteristic to do comparisons between lists e.g. if a list has a key status then we can check the validity of the document. In our business domain, we have cases with a lot of items in a list (1024 or more) We also use the list element as a contracted form for a list of pairs of items e.g. list(1 2 3) to represent (12 13 23) ; since we typically have 64 items in a list, it's obviously more convenient than a sequence of 2016 items, see the example in the attachment. In c++, we use the standard vector class. XBinder uses its own container for this while xsc apparently uses vectors (ref www.cs.wustl.edu/~schmidt/PDF/XSC_ACMSE.pdf") and we consider this as a good feature. We would really like to see this in xsd as well ! Apart from that, what we mean by 'reader' is the 'driver' equivalent to parse an xml instance. Regards Boris Kolpackov wrote: >Frederic, > >badia writes: > > > >>First, xsd complains a lot about our xsd schemas syntax. Apart from the >>things I mentioned to Boris so far, there is a new one concerning the >>list element, I'm sending an attachment of a schema example which >>contains one. >> >> > >xsd:list construct is not yet supported by xsd. This feature is of very >limited use (since it can only be used with certain types and uses space >as delimiter) so it has somewhat lower priority on our list. Would that >be possible for you to use sequence instead? > > > > > > > >This solution is a bit more verbose in the instance document >(i.e., you have "1 2 3" instead of >"1 2 3") but it is much more flexible. > >As of the problem with the anonymous types, we are working on the >morphing backend that will automatically "name" anonymous types. >It will appear in the next release which is due later this week or >early next week. > > > > >>Second thing is it would be nice to see xsd generating a makefile and a >>reader for the C++ classes just like xbinder does but I don't really >>know what your schedule is and how much time you would be prepared to >>spend on that ... >> >> > >I am not quite sure what you mean by "reader". As of the makefiles, we >think this feature will be of a limited use. Most projects have their >own build systems with their own ways of writing makefiles, etc. If all >you need is a temporary makefile just to try things out then it is quite >easy to copy one of the makefiles found in the examples directory and >modify it to your needs. > >One makefile-related thing that we do plan to implement is automatic >dependency generation, similar to what gcc -M does. > >hth, >-boris > > -------------- next part -------------- A non-text attachment was scrubbed... Name: usecaselist.zip Type: application/zip Size: 1101 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050913/ab149675/usecaselist.zip From boris at codesynthesis.com Tue Sep 13 11:34:00 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] About xsd list In-Reply-To: <4326EACB.9010606@mesiog.obspm.fr> References: <4325A714.30904@mesiog.obspm.fr> <20050913090829.GA7691@karelia> <4326EACB.9010606@mesiog.obspm.fr> Message-ID: <20050913153400.GA13061@karelia> Frederic, badia writes: > What we do is that we take advantage of this last characteristic to do > comparisons between lists e.g. if a list has a key status then we can > check the validity of the document. > In our business domain, we have cases with a lot of items in a list > (1024 or more) > We also use the list element as a contracted form for a list of pairs of > items e.g. list(1 2 3) > to represent (12 13 23) ; since we typically have 64 items in a list, > it's obviously more convenient than a sequence of 2016 items, see the > example in the attachment. > I see. > We would really like to see this in xsd as well ! Ok, I will see what I can do. BTW, are you using C++/Tree or C++/Parser mapping? > Apart from that, what we mean by 'reader' is the 'driver' equivalent > to parse an xml instance. That's what I thought. This can be done for the C++/Tree mapping but not for C++/Parser. The C++/Parser mapping generates templates that one has to implement in order to do anything useful. So there is no way to generate a driver that would be compilable on its own. As of C++/Tree, I am not sure how much code it takes in XBinder, in xsd it is a one-liner (taken from examples/cxx/tree/hello/driver.cxx): #include "hello.hxx" int main (int argc, char* argv[]) { auto_ptr h (hello (argv[1])); } Doesn't seem as being worth the trouble. Though we may do this one day. 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/20050913/5b9b0bbe/attachment.pgp From boris at codesynthesis.com Tue Sep 13 12:08:19 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Schema and inheritance In-Reply-To: <43259F48.3070402@free.fr> References: <432571A1.2050004@free.fr> <20050912133534.GC3154@karelia> <43259F48.3070402@free.fr> Message-ID: <20050913160819.GB13061@karelia> Mickael, Vera Mickael writes: > About polymorphism, BusinessCard::person returning a person > may be intersting if the code manipulates a person for its > common attributes. I agree the interest may be limited. Right. You have "convenient" access to one "half" of the data. To get to the other you will have to jump through hoops (casting). > I've been thinking about those problems for a long time. I > did not found any satisfying solution. I guess you thought > about a factory provided by the user. > > One solution would be to provide a factory at parsing time, > each time the parser needs to instantiate an obect it asks > the factory to do it. The user may have its own classes > instanciated or the factory instanciates the default > generated classes. Yes I thought about this. > User classes inherit from generated classes. The major problem > is that generated classes use relations to generated classes, > the user still have to cast to its own classes. Right. There is also one additional benefit to this approach: if accessors are made virtual then the user can override them and get a somewhat crippled behavior polymorphism. This shows what the real problem with translating schema-level polymorphism to the target language polymorphism: schema is about "data" while polymorphism is about "interfaces". With the current state of the art, the user cannot add to the interface, they have to program against the data access API that was generated by the tool from schema. So what would really be cool is to allow to the user to extend the interface of the generated classes. One way to achieve this would be via C++ templates. Here is the "traditional" mapping for the example discussed previously: struct Person { string name () const; }; struct Superman: virtual Person { bool can_fly () const; }; struct BusinessCard { Person& person (); }; Here the interface (Person in this case) is "fixed". Now if the generated code for BusinessCard looked like this: template struct BusinessCard { virtual P& person (); }; Then we could write: struct NewPerson: virtual Person { virtual string print () { return name (); } }; struct NewSuperman: virtual NewPerson, virtual Superman { virtual string print () { return name () + (can_fly () ? "" : " (flying)"); } }; typedef BusinessCard NewBusinessCard; Just need to find time to implement all this ;-) 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/20050913/2940d726/attachment.pgp From jas.post at gmail.com Thu Sep 15 05:16:50 2005 From: jas.post at gmail.com (Andrey Yanukovich) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] compilation problem Message-ID: <1062541901.20050915131650@gmail.com> Hi, I have a problem with compilation of the xsd generator source code. The process breaks at linking stage with errors: /home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/parser/parser-header.o:/home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/parser/parser-header.cxx:442: first defined here /home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/tree/serialization-source.o: In function `void FrontendElements::Traversal::DispatcherBase::dispatch_(XSDFrontend::SemanticGraph::Node const&)' :/home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/elements.hxx:274: multiple definition of `bool CXX::has(XSDFrontend::SemanticGraph::Complex&)::Traverser::~Traverser()' /home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/parser/parser-header.o:/home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/elements.hxx:272: first defined here /home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/tree/serialization-source.o: In function `bool CXX::has(XSDFrontend::SemanticGraph::Complex&)::Traverser::~Traverser()' :/home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/elements.hxx:274: multiple definition of `bool CXX::has(XSDFrontend::SemanticGraph::Complex&)::Traverser::~Traverser()' /home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/parser/parser-header.o:/home/ayanukovich/dev/xsd/xsd-1.2.0/xsd/cxx/elements.hxx:272: first defined here collect2: ld returned 1 exit status I use g++ version 4.0.1 and ld 2.15.97 to build the source tree. Could you give some suggestions about this? Regards, Andrey From boris at codesynthesis.com Thu Sep 15 05:29:37 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] compilation problem In-Reply-To: <1062541901.20050915131650@gmail.com> References: <1062541901.20050915131650@gmail.com> Message-ID: <20050915092937.GA27186@karelia> Skipped content of type multipart/mixed-------------- 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/20050915/53bf7beb/attachment.pgp From boris at codesynthesis.com Fri Sep 16 07:19:07 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd 1.3.0 released Message-ID: <20050916111907.GB13610@karelia> Good day, We've released xsd 1.3.0. The NEWS file entries for this version are as follows: * Numerous bug fixes. * The XML subsystem of libxsd has been reorganized to provide a clean split of DOM and SAX functionalities. cxx-parser * New option, --morph-anonymous, allows automatic morphing of anonymous types to named ones. See the man pages for details. cxx-tree * Additional parser functions provide support for reading from std::istream. 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: 9f874f025e1d66f274ba8112d04bd597e361ba8b xsd-1.3.0.tar.bz2 6177af7b5d92776152493c1880f25420937a653c xsd_1.3.0-1_i386.deb bd1a11df42c7a4f87963f5f80bce64526f08f40b xsd-1.3.0-1.i686.rpm 31394a782cce5d88a446420dfbcc3bf82f247da3 xsd-1.3.0-i686-linux-gnu.tar.bz2 0d96566f454d40afee09a2fabb5141a8276efbab xsd_1.3.0-1_amd64.deb da07fb5c08a8ea55bb35ea17fd4afd29f8c8153c xsd-1.3.0-1.x86_64.rpm d0d1908242ec57c5c5fbc5908c307fb8725d234c xsd-1.3.0-x86_64-linux-gnu.tar.bz2 0882c7a3b15f37856519def2fe0f242750c1c4aa xsd-1.3.0-powerpc-macosx.tar.bz2 a155d307219751f2428cf27b59cf40fd58ee3da4 xsd-1.3.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/20050916/b519f46b/attachment.pgp From frederic.heem at telsey.it Fri Sep 16 11:54:21 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd:include Message-ID: <200509161754.21817.frederic.heem@telsey.it> Hi, I still have some problem with xsd:include even with the version 1.3, it doesn't crash anymore but it doesn't compile: g++ -DP_USE_PRAGMA -D_REENTRANT -Wall -g -D_DEBUG -DNDEBUG -I/home/heefre/software/cti/pwlib_v1_9_1/include -DPTRACING -I/home/heefre/software/cti/opal_v2_1_1/include -I/usr/local/include -I/usr/lib/qt-3.3/include -I/home/heefre/software/cti/xerces-c-src_2_6_0/include -felide-constructors -x c++ -c h323_conf.cxx -o obj_linux_x86_d/h323_conf.o In file included from h323_conf.cxx:40: h323_conf.hxx:160:26: h323_types.hxx: No such file or directory Please find attached the 2 xsd files Regards, Frederic heem -------------- next part -------------- A non-text attachment was scrubbed... Name: h323_conf.xsd Type: application/xml Size: 306 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050916/5d2083eb/h323_conf.xml -------------- next part -------------- A non-text attachment was scrubbed... Name: h323_types.xsd Type: application/xml Size: 2984 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050916/5d2083eb/h323_types.xml From boris at codesynthesis.com Fri Sep 16 12:19:22 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd:include In-Reply-To: <200509161754.21817.frederic.heem@telsey.it> References: <200509161754.21817.frederic.heem@telsey.it> Message-ID: <20050916161922.GA14483@karelia> Frederic, frederic heem writes: > I still have some problem with xsd:include even with the version 1.3, it > doesn't crash anymore but it doesn't compile: > > ... > > In file included from h323_conf.cxx:40: > h323_conf.hxx:160:26: h323_types.hxx: No such file or directory I think you forgot to compile h323_types.xsd. If I do $ xsd cxx-tree h323_conf.xsd $ xsd cxx-tree h323_types.xsd then $ g++ -c h323_conf.cxx works fine. Note also that you will need to compile h323_types.cxx as well. 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/20050916/90e6dec6/attachment.pgp From boris at codesynthesis.com Tue Sep 20 09:57:26 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] plans for xsd 1.4.0 Message-ID: <20050920135726.GA3266@karelia> Good day, We are planning to make a backwards-incompatible change in the C++/Tree mapping for xsd 1.4.0. The change is going to affect the interface that is used to access optional (cardinality 0..1) elements/attributes. The following examples will illustrate the difference. Suppose we have the following XML Schema fragment: ... In the current version one would access element 'foo' like this: Bar& bar = ... if (bar.foo.present ()) // test { Foo& foo = bar.foo (); // get bar.foo (Foo (...)); // set bar.foo.reset (); // reset } After the change the same example would look like this: Bar& bar = ... if (bar.foo ()) // test { Foo& foo = *bar.foo (); // get bar.foo (Foo (...)); // set bar.foo (0); // reset } Or alternatively like this: if (Foo* foo = bar.foo ()) // test & get { ... } Due to inlining the above two cases should be equivalent performance-wise. Here is the motivation for this change: 1. The new interface uses 'iterator' concept which is also used in the access API for sequences (cardinality 0..many). In other words, with this change the way one accesses optional elements and sequences of elements will be conceptually equivalent. 2. The current interface's implementation is based on functors. This model is somewhat unconventional and proved to be hard to explain. For example, when one looks at the generated code it sees something like struct Bar { optional foo; }; 3. The use of functors makes some useful features inaccessible. For example, function overloading in derived classes (via using-declaration) and virtual functions that may be needed in case of a polymorphic schema. Other features that we plan to implement for 1.4.0 are refType attribute for IDREF and IDREFS and support for the xsd:list construct. Your feedback on the proposed changes/new features is always appreciated. -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/20050920/a903a368/attachment.pgp From vandi at email.arc.nasa.gov Wed Sep 21 11:14:31 2005 From: vandi at email.arc.nasa.gov (Vandi Verma) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Syntax supported Message-ID: <433178D7.3070502@email.arc.nasa.gov> From my preliminary test of xsd it appears that xsd does not allow groups of elements to be defined and named using "group" as in the XML schema fragment below: ... .... From the email archive I gathered that it does not support unions, but I am not certain of the above and wanted to confirm it. --Vandi From boris at codesynthesis.com Wed Sep 21 15:56:14 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Syntax supported In-Reply-To: <433178D7.3070502@email.arc.nasa.gov> References: <433178D7.3070502@email.arc.nasa.gov> Message-ID: <20050921195614.GA9832@karelia> Hi Vandi, Vandi Verma writes: > From my preliminary test of xsd it appears that xsd does not allow > groups of elements to be defined and named using "group" as in the XML > schema fragment below: xsd does support element groups. What you stumbled upon is a bug. A simple work-around is to reorder your schema like this: .... ... This will be fixed in the next version of xsd. Also if you would like I can send you a custom binary with this bug fixed (just let me know which platforms/packages and if it is ok to send via email). > From the email archive I gathered that it does not support unions, That's correct. Though we can add support should there be substantial interest. Thanks for report 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/20050921/ac69cb79/attachment.pgp From boris at codesynthesis.com Thu Sep 22 09:01:15 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Syntax supported In-Reply-To: <433195B5.8030408@email.arc.nasa.gov> References: <433178D7.3070502@email.arc.nasa.gov> <20050921195614.GA9832@karelia> <43318A0C.60003@email.arc.nasa.gov> <20050921205700.GB9832@karelia> <433195B5.8030408@email.arc.nasa.gov> Message-ID: <20050922130115.GA15672@karelia> Vandi, Vandi Verma writes: > I took your suggestion and reordered my groups and also removed unions. > I'm not certain if the fact that xsd now does not return is related or > not. I'm attaching my test schema in case there is another known problem > you can detect by looking at it. That's quite a schema you've got here ;-). It has a very deeply nested hierarchy of anonymous types (i.e., type that are embedded inside xsd:element definitions). By default xsd doesn't "flatten" such hierarchy. Instead it generates hierarchy of anonymous types as hierarchy of nested classes. Sometimes this leads to two or more (nested) classes for the same type to be generated. In your case, however, because of such a deep nesting, it resulted in hundreds of duplicate classes being generated. As an experiment, I stripped your schema a bit and the resulting .hxx file was 52M. I haven't seen anything like this before ;-). I guess the best way to go here is to morph anonymous types into named ones. In version 1.3.0 I only enabled such morphing for C++/Parser mapping but for 1.4.0 it will be available for C++/Tree as well. So here is what I did: $ xsd cxx-tree --morph-anonymous vandi_test.xsd vandi_test.xsd:23:39: error: element 'Node/EndCondition' is of type 'anyType' vandi_test.xsd:23:39: info: 'anyType' is not supported vandi_test.xsd:23:39: info: did you forget to specify 'type' attribute? So I changed to read $ xsd cxx-tree --morph-anonymous vandi_test.xsd Which compiled ok. It took about 6 seconds with non-optimized binary of xsd on my Opteron 244 box. I plan to do some more optimizations that should further reduce this time. When I try to compile this I get: $ g++ -I ~/work/xsd/xsd/libxsd -c vandi_test.cxx In file included from vandi_test.cxx:40: vandi_test.hxx:1806: error: redefinition of `struct ADD::_xsd_ADD' vandi_test.hxx:1796: error: previous definition of `struct ADD::_xsd_ADD' vandi_test.hxx:2106: error: invalid use of member `ADD::ADD' vandi_test.hxx:2106: error: syntax error before `const' vandi_test.hxx:1816: error: duplicate nested type `struct ADD::ADD' vandi_test.hxx:1823: error: field `xsd::cxx::tree::sequence ADD::ADD' with same name as class vandi_test.hxx:2107: confused by earlier errors, bailing out It appears that in ADD, SUB, MUL, and DIV there are members that conflict with the class name. In other words it looks like this: class ADD { vector& ADD (); ... }; Ideally, xsd should take care of this but it is a bit trickier than it may seem so it doesn't do it yet. There are two ways we can fix this. The most natural way is to change the schema and add an explicitly-named types for ADD, SUB, MUL, and DIV, e.g., instead of write The other way is to use --anonymous-regex option which allows you to choose the name for an anonymous type (by default it is the same as the element/attribute name). So we can do: $xsd cxx-tree --morph-anonymous --anonymous-regex '%.* .* NumericExpression/(.)(..)$%$1\L$2\E%' vandi_test.xsd This will result in the names being Add, Sub, Mul, and Div. Or you may want to add prefix/suffix to all anonymous types (in order not to confuse them with function names, for example). Then you could write: --anonymous-regex '%.* .* (.+)*(.+)%$2Type%' which will result in all anonymous types having names in the form Type. You can read more about options that control morphing of anonymous types at the bottom of this page: http://codesynthesis.com/projects/xsd/documentation/xsd.xhtml I will send you the binary with optimizations and support for anonymous type morphing in a few minutes. 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/20050922/5e22529a/attachment.pgp From frederic.heem at telsey.it Thu Sep 22 06:30:07 2005 From: frederic.heem at telsey.it (frederic heem) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd:all Message-ID: <200509221230.07569.frederic.heem@telsey.it> Hi, I would recommend to add some examples on how to use xsd:all. I forgot to add minOccurs="0" in the element inside xsd:all, and in this case, the method is present does not exist. Frederic From boris at codesynthesis.com Thu Sep 22 07:06:34 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] xsd:all In-Reply-To: <200509221230.07569.frederic.heem@telsey.it> References: <200509221230.07569.frederic.heem@telsey.it> Message-ID: <20050922110634.GA16565@karelia> Frederic, frederic heem writes: > I would recommend to add some examples on how to use xsd:all. I think what would be even better is to have a mapping documentation that describes (with examples) how various XML Schema constructs are mapped to C++. Such a doc is at the top of our TODO list and we will start working on it as soon as things settle down a bit. 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/20050922/966a7b41/attachment.pgp From Michael.Coulman at mhpcc.hpc.mil Fri Sep 23 19:57:11 2005 From: Michael.Coulman at mhpcc.hpc.mil (Michael Coulman) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] which compiler for amd64? Message-ID: What gcc version ( or other compiler/version ) is supported on linux/amd64? A bug in gcc-3.4.4 prevents me from using xsd on Gentoo Linux. TIA, -- Michael Coulman Senior Applications Engineering Analyst Maui High Performance Computing Center 550 Lipoa Parkway, Kihei, Maui, HI 96753 P: (808) 879-5077 x297 F: (808) 879-5018 E: michael.coulman@mhpcc.hpc.mil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codesynthesis.com/pipermail/xsd-users/attachments/20050923/621e987a/attachment.html From boris at codesynthesis.com Sat Sep 24 07:34:46 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] which compiler for amd64? In-Reply-To: References: Message-ID: <20050924113446.GA28595@karelia> Michael, Michael Coulman writes: > What gcc version ( or other compiler/version ) is supported on > linux/amd64? We routinely test xsd-generated code with g++-3.3, g++-3.4, and g++-4.0 series on amd64. I heard Intel upgraded their C++ compiler to support ET64 (their name for amd64) though we only test with icc on i686. > A bug in gcc-3.4.4 prevents me from using xsd on Gentoo Linux. g++-4.0 seems like a good choice. What exactly is wrong with g++-3.4.4 on Gentoo? Maybe we could work around this bug. 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/20050924/cfc9c096/attachment.pgp From boris at codesynthesis.com Mon Sep 26 09:37:21 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Re: request for a special need In-Reply-To: <4337E931.2000209@dryade.net> References: <4337E931.2000209@dryade.net> Message-ID: <20050926133721.GA11399@karelia> Marc, Marc Florisson writes: > I'd like to compile a XSD Schema expr.xsd (see attachment file). > But there is a use of "mixed content model" in this schema, and I fail > to produce the C++ classes. > > $ ./bin/xsd.exe cxx-tree ../schema/filter/1.0.0/expr.xsd > ..\schema\filter\1.0.0\expr.xsd:57:39: error: mixed content model is not > supported > ..\schema\filter\1.0.0\expr.xsd:63:35: error: expected 'group', > 'choice', 'sequence' or 'element' instead of 'any' > ..\schema\filter\1.0.0\expr.xsd:69:38: error: mixed content model is not > supported > > Could you please tell me if a patch is possible ? We are planning to support mixed content model, xsd:any, xsd:anyAttribute, xsd:anyType, and xsd:anySimpleType in version 1.5.0 which we plan to release in about 3-4 weeks. If you would like to have it sooner and are willing to pay, then let me know and we can discuss the details. Also note that the above mentioned features will be supported in the "fall back" manner by allowing you to access the corresponding "raw" DOM nodes. 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/20050926/96f63e13/attachment.pgp From nelson.faria at netcabo.pt Thu Sep 29 13:48:41 2005 From: nelson.faria at netcabo.pt (nelson.faria) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Microsoft C++ exception: xercesc_2_6::XMLValid::Codes Message-ID: Hi, I'm having some stramge problems when mapping from XML. I should point out that this code is multithread as it is being ran by a callback function. This is what i'm doing: std::string * strxml=new std::string(xml); std::istringstream * stream=new std::istringstream(*strxml); std::auto_ptr info (OSGAannotation(*stream)); and i get this exception: First-chance exception at 0x7c81eb33 in GIDes.exe: Microsoft C++ exception: xercesc_2_6::XMLValid::Codes @ 0x0cefda5c. here: DOMLocatorImpl::~DOMLocatorImpl() { } void DOMBuilderImpl::error().... I thought xsd was responsible for initiating the XMLParser and thus the ErrorHandler as well.. Any ideas? Thanks. Nelson Silva From boris at codesynthesis.com Thu Sep 29 15:18:32 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Microsoft C++ exception: xercesc_2_6::XMLValid::Codes In-Reply-To: References: Message-ID: <20050929191832.GA19919@karelia> Nelson, nelson.faria writes: > I'm having some stramge problems when mapping from XML. I should point > out that this code is multithread as it is being ran by a callback function. Then I suggest that you initialize/terminate Xerces runtime from withing main(). The parsing function that you are calling below (OSGAannotation) initializes/terminates Xerces runtime for you but if that happens concurrently from withing multiple threads bad things can happen. So here is what I suggest you try: 1. Initialize/Terminate Xerces runtime from within main() 2. Call OSGAannotation() like this: xsd::cxx::xml::dom::error_handler eh; std::auto_ptr info (OSGAannotation(*stream, eh)); > and i get this exception: > > First-chance exception at 0x7c81eb33 in GIDes.exe: Microsoft C++ exception: > xercesc_2_6::XMLValid::Codes @ 0x0cefda5c. Note that xsd runtime lets Xerces exceptions propagate freely. Though XMLValid::Codes doesn't seem like an exception that Xerces would throw. > here: > > DOMLocatorImpl::~DOMLocatorImpl() > { > } Are you saying the exception was thrown from this destructor? > I thought xsd was responsible for initiating the XMLParser and thus > the ErrorHandler as well.. Yes it does. However some "hard" errors (like unavailable transcoder), which are not errors in XML per se, Xerces reports via exception. If the above doesn't help, would you be able to send a small Schema and XML fragment so that I could try to reproduce this problem? 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/20050929/1d4ce581/attachment.pgp From boris at codesynthesis.com Fri Sep 30 07:13:50 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Microsoft C++ exception: xercesc_2_6::XMLValid::Codes In-Reply-To: References: Message-ID: <20050930111350.GA24057@karelia> Nelson, I CC'ed xsd-users so that other can benefit from this info. nelson.faria writes: > This is the XML i'm generating: > > > > > and this is the xsd: > > > > > > > > > > > > > > > > > > > > > > > > Any thoughts? I created a small example using your material (test.xsd and test.xml) above: #include #include "test.hxx" int main (int argc, char* argv[]) { std::cerr << *OSGAannotation (argv[1]) << std::endl; } Then when I ran it I got: $ ./test test.xml test.xml:2:85 error: Unknown element 'OSGAannotation' Aborted (Aborted is here because I didn't handle exceptions and xsd throws invalid_instance exception if there were any errors.) So I looked at your xml an noticed that you don't provide location of the schema for validation. And xsd, by default, uses strict validation of instance documents. So I changed your xml to read: $ ./test test.xml x: 246.991 y: -117.927 z: 223.211 active: 1 checked: 0 > I was really hopping to get this up and running in no time... > Murphy's back at it ;) Yeah I noticed the more we hope the less likely it will happen... unless we try really hard ;-) 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/20050930/1c3540fb/attachment.pgp From boris at codesynthesis.com Fri Sep 30 13:08:19 2005 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:40 2009 Subject: [xsd-users] Microsoft C++ exception: xercesc_2_6::XMLValid::Codes In-Reply-To: References: Message-ID: <20050930170819.GA30876@karelia> Nelson, nelson.faria writes: > By the way.. is there any exception i can catch in order to provide > proper error messages ?! The exception that is thrown in case there were any errors that got reported via ErrorHandler is xml_schema::invalid_instance. It doesn't carry any message; the only way to get to it is via ErrorHandler. > I could also create my own error handler and then deal with the > errors.. but if i could just use the standart errorhandler i'd have > less code :P The default error handler (that gets installed if you didn't provide your own) outputs diagnostics to STDERR (std:cerr for char and std::wcerr for wchar_t). Whether it is good enough depends on your application. 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/20050930/7bae13e1/attachment.pgp