From david.r.moss at selex-comm.com Fri Feb 3 06:26:54 2006 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. Message-ID: I have a large schema that contains a lot of optional elements with default values specified. In code, when a query is made as to the value of one of these elements, I'm providing a hard-coded default (the same value as specified in the xsd file) for cases where the element wasn't present: const myData_t wrapper::getData() const { if( m_parent.myData().present() ) { return m_parent.myData().get(); } else { return someDefaultValue; } } This is clearly a maintenance nightmare! It also seems a bit backward as a default is already specified in the xsd file. Is it possible to get the generated code to provide the default i.e. an optional xsd flag that meant get() would return a default value if the optional element wasn't present: const myData_t& wrapper::getData() const { // Code generated with '--defaultElement' flag so no need for // present()check. return m_parent.myData().get(); } This also avoids the need to copy the return value. Any thoughts or alternatives greatly appreciated (I don't want to use attributes instead of elements). Maybe this is already possible and I'm missing something?! Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@seleniacomm.com From boris at codesynthesis.com Fri Feb 3 09:46:49 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. In-Reply-To: References: Message-ID: <20060203144649.GA13469@karelia> David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > I have a large schema that contains a lot of optional elements with > default values specified. In code, when a query is made as to the value > of one of these elements, I'm providing a hard-coded default (the same > value as specified in the xsd file) for cases where the element wasn't > present: > > const myData_t wrapper::getData() const > { > if( m_parent.myData().present() ) > { > return m_parent.myData().get(); > } > else > { > return someDefaultValue; > } > } > > This is clearly a maintenance nightmare! It also seems a bit backward as > a default is already specified in the xsd file. Well, that's the way XML Schema spec prescribes handling of elements with default values. In particular, for elements (unlike attributes), there are three cases to consider: 1. Value specified in the instance - that value is used. 2. Empty value is specified - default value is used. 3. No element specified - element not present. The following table in the manual summarizes all the cases: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#A The reason why XML Schema specifies it this way is probably because element's name (in case of substitution groups) or the xsi:type attribute carries type information. > Is it possible to get the generated code to provide the default i.e. an > optional xsd flag that meant get() would return a default value if the > optional element wasn't present: > > ... > > Any thoughts or alternatives greatly appreciated (I don't want to use > attributes instead of elements). At the moment I don't see any reasons why such an option couldn't be supported. Except that, as for attributes, when this option is specified, optional elements with default/fixed values would be treated as belonging to the One cardinality class because their values will always be present (so no need to call .get ()). I will try to implement it in the next version or two (2.0.0 or 2.0.1). 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/20060203/adf0c47e/attachment.pgp From david.r.moss at selex-comm.com Mon Feb 6 04:41:26 2006 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. Message-ID: Boris, That's great news, thanks. A further thought I had was, having generated these default values, to exclude these elements when serializing the data to file again. i.e. an xml file containing unspecified elements would look the same before and after serialisation. The only slight issue with this is that if a value was set in memory at runtime, overriding the default, then that value would obviously need to be serialized. Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@seleniacomm.com -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: 03 February 2006 14:47 To: Moss, David R (SELEX Comms) (UK Christchurch) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Default values for optional elements. David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > I have a large schema that contains a lot of optional elements with > default values specified. In code, when a query is made as to the value > of one of these elements, I'm providing a hard-coded default (the same > value as specified in the xsd file) for cases where the element wasn't > present: > > const myData_t wrapper::getData() const > { > if( m_parent.myData().present() ) > { > return m_parent.myData().get(); > } > else > { > return someDefaultValue; > } > } > > This is clearly a maintenance nightmare! It also seems a bit backward as > a default is already specified in the xsd file. Well, that's the way XML Schema spec prescribes handling of elements with default values. In particular, for elements (unlike attributes), there are three cases to consider: 1. Value specified in the instance - that value is used. 2. Empty value is specified - default value is used. 3. No element specified - element not present. The following table in the manual summarizes all the cases: http://codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#A The reason why XML Schema specifies it this way is probably because element's name (in case of substitution groups) or the xsi:type attribute carries type information. > Is it possible to get the generated code to provide the default i.e. an > optional xsd flag that meant get() would return a default value if the > optional element wasn't present: > > ... > > Any thoughts or alternatives greatly appreciated (I don't want to use > attributes instead of elements). At the moment I don't see any reasons why such an option couldn't be supported. Except that, as for attributes, when this option is specified, optional elements with default/fixed values would be treated as belonging to the One cardinality class because their values will always be present (so no need to call .get ()). I will try to implement it in the next version or two (2.0.0 or 2.0.1). hth, -boris ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codesynthesis.com/pipermail/xsd-users/attachments/20060206/5469f524/attachment.html From david.r.moss at selex-comm.com Mon Feb 6 05:02:05 2006 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Data validation Message-ID: Boris, The following in-memory data validation would be of most use to me at the moment: - Built-in types (as you mention) - Facet restrictions (especially length, minLength, maxLength, minInclusive, maxInclusive, minExclusive, maxExclusive, enumeration and pattern) - all - unique - union - extension (of user defined types) Keep up the good work! Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@seleniacomm.com -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: 31 January 2006 15:31 To: Moss, David R (SELEX Comms) (UK Christchurch) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Data validation David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > Excellent news that's it's on your list of things to do - I shall await > the next version rather than reform xml files. Any idea on timescales > for this?! :) There is no precise time-table. The next version (1.9.0) which is scheduled for release some time next week, will (hopefully) be the last in the 1.x series and won't include any significant new features - mostly code cleanups, support for extra platforms/compilers (notably HP-UX/aCC) and small fixes. After that we will start working on 2.0.0, with the major new feature being the new parser architecture which will be able to handle repeated element definitions. The in-memory validation is going to be added gradually over several versions, starting from the built-in types and structure and continuing with the more complicated cases, such as facet- based restrictions on simple types, etc. Some of these might end up in 2.0.0 but most likely in 2.0.1. The 2.0.0 is scheduled for around March 6. If you could give us a list of schema constraints that are important to you, we will try to add them first. hth, -boris ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From boris at codesynthesis.com Mon Feb 6 05:11:40 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. In-Reply-To: References: Message-ID: <20060206101140.GD5293@karelia> David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > A further thought I had was, having generated these default values, to > exclude these elements when serializing the data to file again. i.e. an > xml file containing unspecified elements would look the same before and > after serialisation. > > The only slight issue with this is that if a value was set in memory at > runtime, overriding the default, then that value would obviously need to > be serialized. Right, I was thinking about exactly the same problem: if we map optional elements with default values to the One cardinality class then we may and up with invalid instances when serializing back to XML. So it seem like your initial idea (return false from present() and return default value from get()) is winning so far. We will need to extend optional container with something like set_default which will also require an extra flag to distinguish between the normal value and default value cases (at the moment it's just an auto_ptr). So things get a bit hairy and I would like to think some more about other options. Maybe we should use another container, optional_with_default? 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/20060206/9bac6c7f/attachment.pgp From boris at codesynthesis.com Mon Feb 6 05:25:35 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Data validation In-Reply-To: References: Message-ID: <20060206102535.GE5293@karelia> David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > - Built-in types (as you mention) > - Facet restrictions (especially length, minLength, maxLength, > minInclusive, maxInclusive, minExclusive, maxExclusive, enumeration > and pattern) Ok. > - all This is part of the structure, along with choice, sequence, etc. > - unique For this we will first need to add mapping for xsd:unique, xsd:key, and xsd:keyref. This is also on our todo list, we just haven't figured out what's the best way to represent these constructs in C++. > - union At the moment unions are mapped to strings so we will need to implement proper union mapping before we can do any validation. The good news is that once we can validate all elements that can constitute a union we shouldn't have any problems implementing this (modulo coming up with natural C++ mapping, of course). > - extension (of user defined types) This is already enforced by static typing of the mapping. > Keep up the good work! Thanks, will do ;-) I will keep this list in mind. 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/20060206/e2f53469/attachment.pgp From boris at codesynthesis.com Mon Feb 6 07:23:34 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] xsd 1.9.0 released Message-ID: <20060206122334.GB5683@karelia> Good day, We've released xsd 1.9.0. The NEWS file entries for this version are as follows: cxx-tree * The size modifier function in the base64_binary and hex_binary built-in types automatically adjusts capacity if needed. * More internal names (names that start with _xsd_) were made private or protected. cxx-parser * Typedef for the parser base in the xml_schema namespace. cxx-parser-e * C++/Parser mapping optimized for embedded systems. For now it is equivalent to 'cxx-parser --xml-parser expat'. With this version we also added support for HP-UX 11.11 and 11.23 on PA-RISC and IA-64 as well as for the following C++ compilers: * Intel C++ 9.0 * HP aCC A.03.63 on PA-RISC, 32/64 bit (C++/Tree only) * HP aCC A.06.05 on IA-64, 32/64 bit This version is the last minor version in the 1.x.y major version series. The next major and minor versions are going to be 2.0.0. There still might be the 1.9.1 maintenance release should any significant bugs get uncovered. 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: 724ee8ea1881f130bcd491174b8661c5cb349bbb xsd-1.9.0.tar.bz2 bce4528404b53f217806f76f3143b1baa6e75439 xsd_1.9.0-1_i386.deb 295761d8e838fb6542a58a3bd7d063d0228832e0 xsd-1.9.0-1.i686.rpm 62edb4ffd69f15974a60ac24bfe66df41473f077 xsd-1.9.0-i686-linux-gnu.tar.bz2 7cefb15b23b8d04f5daea6ed2c47c41b13124518 xsd_1.9.0-1_amd64.deb 305fd4a19596669332a86f720f041ee375c41493 xsd-1.9.0-1.x86_64.rpm fbe7b9054a8894254fd3a201b7814c6db1ae35e4 xsd-1.9.0-x86_64-linux-gnu.tar.bz2 aacc81ce8d64ae0c4cf90c0ef6e84f9914203711 xsd-1.9.0-hppa-hpux.tar.bz2 e268f4af0b4aa384d20519b3ed307bc3b4134a61 xsd-1.9.0-powerpc-macosx.tar.bz2 e87423de267628ab9491fb9ee48ba92b6f173601 xsd-1.9.0-sparc-solaris.tar.bz2 46c536ddbe25249e740434047853eb94018f0933 xsd-1.9.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/20060206/ea606c75/attachment.pgp From boris at codesynthesis.com Mon Feb 13 05:08:19 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] xsd-announcements mailing list and RSS feed Message-ID: <20060213100819.GA13987@karelia> Good day, I've just created the xsd-announcements mailing list which is a read- only, low-volume news mailing list for xsd. You don't need to subscribe to this mailing list if you are already a member of xsd-users because all announcements are going to be posted there as well: http://codesynthesis.com/mailman/listinfo/xsd-announcements There is also an RSS feed for news about all our products: http://codesynthesis.com/news.rss 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/20060213/621d5e9d/attachment.pgp From boris at codesynthesis.com Tue Feb 14 03:09:55 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. In-Reply-To: <20060206101140.GD5293@karelia> References: <20060206101140.GD5293@karelia> Message-ID: <20060214080955.GB17532@karelia> Hi David, Boris Kolpackov writes: > We will need to extend optional container with something like set_default > which will also require an extra flag to distinguish between the normal > value and default value cases (at the moment it's just an auto_ptr). So > things get a bit hairy and I would like to think some more about other > options. Maybe we should use another container, optional_with_default? I tend to think that creating a separate container (which inherits from the optional container) with this additional logic is the best way to go. I also think it will make sense to use a different name for the accessor function which has the additional, "default value" logic, something like get_with_default. This way, when you have return foo.bar ().get_with_default (); and later change definition of bar not to have a default value or remove the option that allow this behavior, you will get an error at compile- time rather than at run-time. Any thoughts? 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/20060214/feb12fcb/attachment.pgp From david.r.moss at selex-comm.com Tue Feb 14 04:12:19 2006 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. Message-ID: Boris, Yes, that sounds good - catching problems caused by changes at compile time is definitely a good idea! I did think there may be an issue with a scenario where the in-memory value is set to that of the default (i.e. what should be serialised) but that should just be treated as if it was any other non-default value I guess. Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@selex-comm.com -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: 14 February 2006 08:10 To: Moss, David R (SELEX Comms) (UK Christchurch) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Default values for optional elements. Hi David, Boris Kolpackov writes: > We will need to extend optional container with something like set_default > which will also require an extra flag to distinguish between the normal > value and default value cases (at the moment it's just an auto_ptr). So > things get a bit hairy and I would like to think some more about other > options. Maybe we should use another container, optional_with_default? I tend to think that creating a separate container (which inherits from the optional container) with this additional logic is the best way to go. I also think it will make sense to use a different name for the accessor function which has the additional, "default value" logic, something like get_with_default. This way, when you have return foo.bar ().get_with_default (); and later change definition of bar not to have a default value or remove the option that allow this behavior, you will get an error at compile- time rather than at run-time. Any thoughts? thanks, -boris ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From boris at codesynthesis.com Wed Feb 15 06:47:01 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. In-Reply-To: References: Message-ID: <20060215114701.GA21679@karelia> Hi David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > Yes, that sounds good - catching problems caused by changes at compile > time is definitely a good idea! I think I came up with an even better and more generic solution: a static default_value function in element/attributes infoscope. With this approach you would write your code like this: return foo.bar ().present ? foo.bar ().get () : foo::bar::default_value (); or, using pointer notation: return foo.bar () ? *foo.bar () : foo::bar::default_value (); A bit more verbose but more universal and works for all containers, not just optional. It also has the compile-time error catching feature (the default_value function will disappear if you remove the default= attribute). I have this implemented in my workspace and can build you a pre-release. Just let me know which platform/package you would like. > I did think there may be an issue with a scenario where the in-memory > value is set to that of the default (i.e. what should be serialised) but > that should just be treated as if it was any other non-default value I > guess. A smart implementation can always check if the user-provided value is the same as the default and treat it as such. Right now xsd serializes without checking. This optimization can be implemented shout there be strong interest. 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/20060215/7a142237/attachment.pgp From eb.brain at gmx.net Thu Feb 16 08:15:27 2006 From: eb.brain at gmx.net (eb.brain@gmx.net) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Custom XSD type to C++ type mapping / performance Message-ID: <2834.1140095727@www097.gmx.net> Hi all, I have some experience with XML binding tools (JAXB / LEIF), but now I've found "xsd c++/tree" and I want to try it out. Event after reading the docs and the postings, I still have some questions: - does "xsd" provide a way to customize the type mappings? (for example: map the XMLSchema type "xsd:dateTime" to the C++ type "boost::posix_time::ptime" - or event any custom C++ - class) - does "xsd" generate a perfect parser or just a wrapper arround a general XML parser (Xerces)? What about the runtime performance? Thanks & best regards, eb -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner From boris at codesynthesis.com Thu Feb 16 13:14:07 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Custom XSD type to C++ type mapping / performance In-Reply-To: <2834.1140095727@www097.gmx.net> References: <2834.1140095727@www097.gmx.net> Message-ID: <20060216181407.GA30677@karelia> Hi, eb.brain@gmx.net writes: > I have some experience with XML binding tools (JAXB / LEIF), but now I've > found "xsd c++/tree" and I want to try it out. Cool. Let us know how it stacks up. > Event after reading the docs and the postings, I still have some questions: > > - does "xsd" provide a way to customize the type mappings? There is no such facility in xsd at the moment mainly because we haven't come up with something universally useful and convenient at the same time. Here are some ideas we have so far: 1. Allow to derive from generated types and use these new types when constructing the tree (via a factory that is passed to the parsing function). This is a fairly clean but not very generic approach. 2. Allow to specify base classes for generated types (either in the schema or as a command-line option). This is fairly generic and reasonably convenient. The base classes can be either inserted "inline" in the generated code or included from a separate file using the prologue/epilogue options. 3. Allow to provide custom mapping for individual types. This is fairly easy to implement but will require the user to support interface expected by the type system (e.g., inherit from xml_schema::type base type (mapping for XML Schema anyType), etc.) Again the custom type names can be specified either directly in the schema or using command- line options. > (for example: map the XMLSchema type "xsd:dateTime" to the C++ type > "boost::posix_time::ptime" - or event any custom C++ - class) It is actually on our TODO list to support optional mapping of XML Schema date/time types to types from boost's date_time library: http://codesynthesis.com/projects/xsd/documentation/future.xhtml I think to achieve what you want we will need to support (3) above. Note also that you won't be able to use arbitrary C++ classes - you will have to implement the interface expected by the type system. It shouldn't be hard to implement (3) above so let me know if you would like to try it out. > - does "xsd" generate a perfect parser or just a wrapper arround a general > XML parser (Xerces)? Quoting from C++/Tree Mapping FAQ[1]: "Parsers generated by xsd do not assume instance documents are valid. They include a number of checks that prevent construction of inconsistent in- memory representations. This, however, does not mean that an instance document that was successfully parsed by the xsd-generated parsers is valid per the corresponding schema." In other words, we support two approaches: fast and compact validation implemented in generated code which checks for basic structure but does not handle things like key/keyref, etc. and complete validation using Xerces-C++. > What about the runtime performance? Nobody complained so far ;-). I believe our validation in generated code is as fast as it gets. For the complete validation with Xerces-C++, there are a number of optimization techniques (like grammar pre-loading and caching) that makes it fairly fast. I think that once the grammar was pre-compiled the performance should be comparable to that of a generated validator. I believe JABX delegates validation to the generic schema validator. You said you have experience with LEIF; does it support complete XML Schema support in generated code? If so how's the code size and performance? [1] http://codesynthesis.com/projects/xsd/documentation/cxx/tree/faq/#2.3 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/20060216/cfc661ba/attachment.pgp From boris at codesynthesis.com Fri Feb 17 02:58:39 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. In-Reply-To: References: Message-ID: <20060217075839.GA32550@karelia> Hi David, [I've CC'ed xsd-users back in.] Moss, David R (SELEX Comms) (UK Christchurch) writes: > I've had a play with the new version and noticed that the > default_value() function creates and returns a copy each time it is > called. > > This means that a function that does: > > return foo.bar ().present ? foo.bar ().get () : foo.bar::default_value > (); > > has to return a copy. Whereas the following would not require any copies > to be made and the client also would not require its own copy: > > > static const type& default_value(); > > inline > const foo::bar::type& foo::bar:: > default_value () > { > static foo::bar::type instance = > ::xsd::cxx::tree::default_value_factory< > foo::bar::type>::create("default_value", 0); > > return instance; > } > > Any thoughts? Hm, this is an interesting idea. I agree that it would be nice to have return types of get() and default_value() aligned. However, adding a static variable in the default_value will effectively make it uninlinable. I guess it is a good tradeoff for string-based types (where, currently, we are looking at heap allocation every time default_value is called) but could be not so good for fundamental C++ types (e.g., bool, int). However, this case can be specialized to return by value (along with get(), which is on my TODO). Yet another approach would be to have a class-static variable with default value. The drawback is that it will always be initialized no matter whether it is used or not. The advantages of this approach include inlinable default_value and, more importantly, this makes it usable in MT environments. This approach can also benefit from specialization for fundamental types. It seems to me like the class-static variable is the winner. Thoughts? 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/20060217/c06ffc76/attachment.pgp From david.r.moss at selex-comm.com Fri Feb 17 04:13:04 2006 From: david.r.moss at selex-comm.com (Moss, David R (SELEX Comms) (UK Christchurch)) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. Message-ID: Boris, Yes, the class-static variable does sound the way forward despite the initialisation overhead - seems like a reasonable trade-off against making two object copies per call to default() and aligning that behaviour with that of get(). Cheers, Dave. Dave Moss SELEX Communications Grange Road Christchurch Dorset BH23 4JE United Kingdom Tel: + 44 (0) 1202 404841 Email: david.r.moss@selex-comm.com -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: 17 February 2006 07:59 To: Moss, David R (SELEX Comms) (UK Christchurch) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Default values for optional elements. Hi David, [I've CC'ed xsd-users back in.] Moss, David R (SELEX Comms) (UK Christchurch) writes: > I've had a play with the new version and noticed that the > default_value() function creates and returns a copy each time it is > called. > > This means that a function that does: > > return foo.bar ().present ? foo.bar ().get () : foo.bar::default_value > (); > > has to return a copy. Whereas the following would not require any copies > to be made and the client also would not require its own copy: > > > static const type& default_value(); > > inline > const foo::bar::type& foo::bar:: > default_value () > { > static foo::bar::type instance = > ::xsd::cxx::tree::default_value_factory< > foo::bar::type>::create("default_value", 0); > > return instance; > } > > Any thoughts? Hm, this is an interesting idea. I agree that it would be nice to have return types of get() and default_value() aligned. However, adding a static variable in the default_value will effectively make it uninlinable. I guess it is a good tradeoff for string-based types (where, currently, we are looking at heap allocation every time default_value is called) but could be not so good for fundamental C++ types (e.g., bool, int). However, this case can be specialized to return by value (along with get(), which is on my TODO). Yet another approach would be to have a class-static variable with default value. The drawback is that it will always be initialized no matter whether it is used or not. The advantages of this approach include inlinable default_value and, more importantly, this makes it usable in MT environments. This approach can also benefit from specialization for fundamental types. It seems to me like the class-static variable is the winner. Thoughts? thanks, -boris ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From karen at ocslab.com Fri Feb 17 05:07:49 2006 From: karen at ocslab.com (Karen Arutyunov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Problem with xsd 1.9.0 & g++ 3.2.3 Message-ID: <002c01c633aa$026d4410$3d8930d4@karenxp> Hello, I'm using xsd C++ tree mapping in one of my projects. Everything was working just fine but with xsd 1.9.0 I have got some compiler internal error. Understand that g++ 3.2.3 is not in the XSD Supported C++ Compilers list but would be great if you could look into the problem and fix it if possible. Thanks in advance, Karen. Compiler info: [karen@localhost build]$ g++ --version g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-53) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compilation output: /usr/bin/xsd cxx-tree --hxx-suffix .hpp --cxx-suffix .cpp ../../../xsd/TestRSSFeed/Config.xsd g++ -c -Wall -g -ggdb -fno-inline -D_REENTRANT -D_GLIBCPP_USE_WCHAR_T -I../../ . -I.././. -I/home/karen/projects/research/include -I/usr/include -o Config.so. o Config.cpp /usr/include/xsd/cxx/tree/type-factory-map.ixx: In constructor `xsd::cxx::tree::type_factory_map::type_factory_map() [with C = char]': /usr/include/xsd/cxx/tree/type-factory-map.ixx:29: Internal compiler error in c_expand_expr, at c-common.c:3830 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Content of TestRSSFeed/Config.xsd: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codesynthesis.com/pipermail/xsd-users/attachments/20060217/c6588367/attachment.htm From boris at codesynthesis.com Fri Feb 17 06:06:18 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Problem with xsd 1.9.0 & g++ 3.2.3 In-Reply-To: <002c01c633aa$026d4410$3d8930d4@karenxp> References: <002c01c633aa$026d4410$3d8930d4@karenxp> Message-ID: <20060217110618.GA1457@karelia> Karen, Karen Arutyunov writes: > I'm using xsd C++ tree mapping in one of my projects. Everything was > working just fine but with xsd 1.9.0 I have got some compiler internal > error. Understand that g++ 3.2.3 is not in the XSD Supported C++ > Compilers list but would be great if you could look into the problem > and fix it if possible. Here is a workaround for this problem: http://codesynthesis.com/~boris/tmp/xsd-1.9.0-g++-3.2.3-extras.tar.bz2 The archive contains two .hxx files which you need to replace in your vanilla 1.9.0 distribution. After that everything should work with 3.2.3. 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/20060217/206090a4/attachment.pgp From boris at codesynthesis.com Fri Feb 17 06:27:56 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Default values for optional elements. In-Reply-To: References: Message-ID: <20060217112756.GA2071@karelia> David, Moss, David R (SELEX Comms) (UK Christchurch) writes: > Yes, the class-static variable does sound the way forward despite the > initialisation overhead - seems like a reasonable trade-off against > making two object copies per call to default() and aligning that > behaviour with that of get(). Ok, I implemented this in my workspace. Here is a binary for you to play with: http://codesynthesis.com/~boris/tmp/xsd-1.9.0-2-i686-windows.zip Let me know if you run into any problems. 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/20060217/b87e8a95/attachment.pgp From marco.fischer at chipvision.com Mon Feb 20 05:21:06 2006 From: marco.fischer at chipvision.com (Marco Fischer) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Obtaining a referenced element via IDREF Message-ID: <1140430866.7039.23.camel@wiesel.fauna> Hello, I have problems to obtain a referenced element from an IDREF attribute. My schema looks like the following: I work on an in-memory representation with the following code: A *a; B *b; ... b->ref(xml_schema::idref(a->name())); ... xsd::cxx::tree::type *t = b->ref().get().get(); // t is null here As I understood, ref is a container, ref() returns the optional representing the attribute, ref().get() returns the idref instance and ref().get().get() should resolve to the referenced element. For some reason, I can't get back a pointer to 'a'. Surprisingly, using the same code to get a pointer to a referenced element on the in-memory representation of a just de-serialized XML file works. I think I did not correctly initialize the idref instance that I want to add to the in-memory representation. What am I doing wrong? Thanks for your help, Marco Fischer ChipVision Design Systems AG Fritz-Bock-Strasse 5 - 26121 Oldenburg - Germany From boris at codesynthesis.com Mon Feb 20 06:19:45 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Obtaining a referenced element via IDREF In-Reply-To: <1140430866.7039.23.camel@wiesel.fauna> References: <1140430866.7039.23.camel@wiesel.fauna> Message-ID: <20060220111945.GA10016@karelia> Marco, Marco Fischer writes: > I have problems to obtain a referenced element from an IDREF attribute. > My schema looks like the following: > > > > > > > > > > I work on an in-memory representation with the following code: > > A *a; > B *b; > ... > b->ref(xml_schema::idref(a->name())); > ... > xsd::cxx::tree::type *t = b->ref().get().get(); > // t is null here Do a and b point to objects that are in the same tree? It is important that they do when you try to resolve the idref. Otherwise the ID/IDREF mechanism don't have a way of finding them. For example, the following won't work: A a; B b; a.name ("foo"); b.ref (a.name ()); xml_schema::type* p (b.ref ().get ().get ()); // p is 0 While, provided we have something like this: the following will work as expected: C c (a, b); p = c.b ().ref ().get ().get (); // p is &(c.a ()) Also note that you should used xml_schema::type instead of xsd::cxx::tree::type. > As I understood, ref is a container, ref() returns the optional > representing the attribute, ref().get() returns the idref instance and > ref().get().get() should resolve to the referenced element. That's correct. > For some reason, I can't get back a pointer to 'a'. > Surprisingly, using the same code to get a pointer to a referenced > element on the in-memory representation of a just de-serialized XML file > works. That's probably because all the individual objects belong to a tree right after parsing and therefore "connected". 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/20060220/9d87e428/attachment.pgp From marco.fischer at chipvision.com Mon Feb 20 08:37:46 2006 From: marco.fischer at chipvision.com (Marco Fischer) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Obtaining a referenced element via IDREF In-Reply-To: <20060220111945.GA10016@karelia> References: <1140430866.7039.23.camel@wiesel.fauna> <20060220111945.GA10016@karelia> Message-ID: <1140442666.7039.40.camel@wiesel.fauna> Hi Boris, > Do a and b point to objects that are in the same tree? Aahh, ok, probably not. You have some generic navigation functionality in the underlying classes, used for looking up IDREFS. So all elements can be reached, only if they are somewhere on the underlying navigation paths, right? Which actions make elements part of the same tree? If I have a sequence of B's in A called children, would then A *a; B *b; ... a.children.push_back(b); make 'b' reachable from 'a', and vice versa? Regards, Marco From boris at codesynthesis.com Mon Feb 20 10:02:41 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Obtaining a referenced element via IDREF In-Reply-To: <1140442666.7039.40.camel@wiesel.fauna> References: <1140430866.7039.23.camel@wiesel.fauna> <20060220111945.GA10016@karelia> <1140442666.7039.40.camel@wiesel.fauna> Message-ID: <20060220150241.GA3088@karelia> Marco, Marco Fischer writes: > Aahh, ok, probably not. You have some generic navigation functionality > in the underlying classes, used for looking up IDREFS. So all elements > can be reached, only if they are somewhere on the underlying navigation > paths, right? Not necessarily underlying, just if they are in the same tree (formally, if they have a common root). > Which actions make elements part of the same tree? The tree is a container, it maintains ownership of its nodes. When you call an accessor function you get a reference to the node which is part of the tree. Modifier functions make copies and store them in the tree. Here are a couple of examples assuming schemas for A, B, and C from the previous email: A a; B b; a.name ("foo"); b.ref ("foo"); C c (a, b); // C makes a copy of 'a' and 'b'. 'a' and 'b' are not part // of the tree with the root being 'c' A& ra (c.a ()); // ra refers to a copy of 'a' which is part of the tree B& rb (c.b ()); // ditto A* p (rb.ref ().get ().get ()); // p is (&ra) p = b.ref ().get ().get (); // p is 0 B cb (c.b ()); // cb is a copy of (c.b ()) and not part of the tree p = b.ref ().get ().get (); // p is 0 > If I have a sequence of B's in A called children, would then > > A *a; > B *b; > ... > a.children.push_back(b); > > make 'b' reachable from 'a', and vice versa? No, because a.children ().push_back (b); will create a copy of 'b'. But B& rb (a.children ().back ()); will. 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/20060220/ebf3c12b/attachment.pgp From buscarini at gmail.com Mon Feb 20 13:01:27 2006 From: buscarini at gmail.com (=?ISO-8859-1?Q?Jos=E9_Manuel_S=E1nchez?=) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Problems with 1.9 and visual studio 2005 Message-ID: <979b10010602201001u4b0bffdbibc6b4e82de577b60@mail.gmail.com> I have compiled xerces-2.7, and i can compile the examples in the xsd 1.9distribution, but i can't parse the example file " hello.xml" . This is what I get: C:\ .. \xsd-1.9.0-i686-windows\examples\cxx\tree\hello\Release>driver.exe hello.xml C:\ .. \xsd- 1.9.0-i686-windows\examples\cxx\tree\hello\Release/hello.xml:11:8 error: Unknown element 'hello' C:\ .. \xsd-1.9.0-i686-windows\examples\ cxx\tree\hello\Release/hello.xml:15:13 error: Unknown element 'greeting' C:\ .. \xsd- 1.9.0-i686-windows\xsd-1.9.0-i686-windows\examples\cxx\tree\hello\Release/hello.xml:17:9error: Unknown element 'name' C:\ .. \xsd- 1.9.0-i686-windows\xsd-1.9.0-i686-windows\examples\cxx\tree\hello\Release/hello.xml:18:9error: Unknown element 'name' C:\ .. \xsd- 1.9.0-i686-windows\xsd-1.9.0-i686-windows\examples\cxx\tree\hello\Release/hello.xml:19:9error: Unknown element 'name' Anyone knows what's going on? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codesynthesis.com/pipermail/xsd-users/attachments/20060220/8af4bd5a/attachment.html From boris at codesynthesis.com Tue Feb 21 01:13:59 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Problems with 1.9 and visual studio 2005 In-Reply-To: <979b10010602201001u4b0bffdbibc6b4e82de577b60@mail.gmail.com> References: <979b10010602201001u4b0bffdbibc6b4e82de577b60@mail.gmail.com> Message-ID: <20060221061359.GA2895@karelia> Hi, Jos? Manuel S?nchez writes: > I have compiled xerces-2.7, and i can compile the examples in the xsd > 1.9distribution, but i can't parse the example file " > hello.xml" . This is what I get: > > C:\ .. \xsd-1.9.0-i686-windows\examples\cxx\tree\hello\Release>driver.exe > hello.xml > C:\ .. \xsd- > 1.9.0-i686-windows\examples\cxx\tree\hello\Release/hello.xml:11:8 error: > Unknown element 'hello' I think you did not copy hello.xsd into the Release directory. By default, the generated code validates the instance against the corresponding schema. I usually run examples on Windows like this: ...\xsd-1.9.0-i686-windows\examples\cxx\tree\hello> Release\driver.exe hello.xml This way you don't need to copy anything. 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/20060221/50402bd8/attachment.pgp From skhabbaz at noos.fr Tue Feb 21 05:56:22 2006 From: skhabbaz at noos.fr (Si Mohammed KHABBAZ) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] xsd port to Borland C++ Message-ID: <43FAF1D6.7070802@noos.fr> Hi, I'm trying to compile xsd 1.9.0 under "Borland C++ 5.6.4". I had some compilers internal errors at the begining (mainly due to templates) that I came over. Until now I succeded to build xsd's parser examples and I'm fighting with the tree examples. Basically, I have still one problem with construction like this : (here a snap from "library.hxx" generated by xsd) class person : public ::xsd::cxx::tree::type { public: struct _xsd_person { typedef ::xsd::cxx::tree::type base_; typedef ::xsd::cxx::tree::type member_; typedef ::xsd::cxx::tree::traits< base_ > traits_; }; // name // protected: struct _xsd_name { typedef ::xml_schema::string type_; typedef ::xsd::cxx::tree::traits< type_ > traits_; }; public: struct name { typedef _xsd_name::type_ type; }; name::type const& name () const; .... }; The compiler does not recognize the other "name" methods when the "struct name" is defined. As a workaround I renamed the "struct name" into "struct _name" but afterwords I had to replace all the occurences of the old "name::" scope. Actually, I'm planning to use xsd with a large xsd schema and it's important that I do not have to rewrite the generated code. My question is : "Is there anything I can do (command line, work over the xsd schema, etc.) so the generated code comes with the workarount that I used ?" I will looking forward to your reponse. Thanks in advance -------------- next part -------------- A non-text attachment was scrubbed... Name: skhabbaz.vcf Type: text/x-vcard Size: 136 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060221/501f93da/skhabbaz.vcf From boris at codesynthesis.com Tue Feb 21 09:59:38 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] xsd port to Borland C++ In-Reply-To: <43FAF1D6.7070802@noos.fr> References: <43FAF1D6.7070802@noos.fr> Message-ID: <20060221145938.GA2771@karelia> Hi, Si Mohammed KHABBAZ writes: > I'm trying to compile xsd 1.9.0 under "Borland C++ 5.6.4". I had some > compilers internal errors at the begining (mainly due to templates) that No, this is not due to templates, it is due to Borland C++ not being able to properly support most basic C++ constructs in 2006, 8 years since the official standard was published. I don't understand why someone would pay money for something so broken when there are decent alternatives available for free: VC++ 2005 Express Edition (as in beer) and GCC (as in speech). I guess you have your reasons. > The compiler does not recognize the other "name" methods when the > "struct name" is defined. As a workaround I renamed the "struct name" > into "struct _name" but afterwords I had to replace all the occurences > of the old "name::" scope. Actually, I'm planning to use xsd with a > large xsd schema and it's important that I do not have to rewrite the > generated code. I can imagine. We cannot implement this workaround in our mapping because of it's potential for conflicts. Imagine a schema like this: With your workaround the compiler will produce invalid code. This might be acceptable in your particular case, however. > My question is : "Is there anything I can do (command line, work over > the xsd schema, etc.) so the generated code comes with the workarount > that I used ?" Hm, the only way I can think of is to change code generators to implement your workaround. You can do it yourself or we can do it for you as a custom development service on commercial basis. 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/20060221/a05c2021/attachment.pgp From galathaea at gmail.com Wed Feb 22 01:35:11 2006 From: galathaea at gmail.com (galathaea galathaea) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] :: Segmentation fault :: Message-ID: boris i am building a project with xsd that i want to compile on both macosx (gcc 4.0.0 - osx 10.4.4) and linux (gcc 2.96 - kernel 2.4.18) to automate portability i have decided to makefile the full source build including all the subproject dependencies (I also wanted to study some of the structure of xsd because i enjoyed the modern api) it seems it all starts with a "build" layer where you add some project management to the make process i have downloaded and extracted the build project (0.2.1) on both the macosx and linux when i enter make install install_prefix=/direct.path.to.install.location or even just make i get Segmentation fault on the macosx i am using make 3.80 i was going to start turning on makefile output attaching a debugger and hunting through the code but i was hoping this might be obvious to someone familiar with the code i understand the linux doesn't meet the minimum gcc version (i will be upgrading everything - including kernel - in a few weeks) but are there any known difficulties on the macosx? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- galathaea: prankster, fablist, magician, liar From galathaea at gmail.com Wed Feb 22 03:20:19 2006 From: galathaea at gmail.com (galathaea galathaea) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] :: Segmentation fault :: Message-ID: boris i may have been a bit impatient before sending my last email i had tried to upgrade to the prerequisites for the project but had not seen that you require a beta version make which was not available in the normal release mirror (i already had 3.1.0 bash) upgrading make (3.81beta4) changed the nature of the problem then a "make install" caused errors: /bin/sh: -c: line 0: syntax error near unexpected token `newline' /bin/sh: -c: line 0: `sed -e '1q' <' /bin/sh: -c: line 0: syntax error near unexpected token `newline' /bin/sh: -c: line 0: `sed -e '1q' <' xargs: illegal option -- - usage: xargs [-0pt] [-E eofstr] [-I replstr [-R replacements]] [-J replstr] [-L number] [-n number [-x] [-s size] [utility [argument ...]] find: -printf: unknown expression primary xargs: illegal option -- - usage: xargs [-0pt] [-E eofstr] [-I replstr [-R replacements]] [-J replstr] [-L number] [-n number [-x] [-s size] [utility [argument ...]] finally, rtfming around i realised i actually needed a patched make which you provided on a different site (3.81beta1-bk5) a tar, configure, make, install later i try to build and Segmentation fault i certainly am beginning to understand the expediency of the target specific archives but i fear i am already growing obstinate and will have to defeat this challenge... i notice in the NEWS mention of host_system and target_system but setting these to "apple" does not behave as i expect again i defer to more experienced eyes (while frantically trying to debug it myself) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- galathaea: prankster, fablist, magician, liar From boris at codesynthesis.com Wed Feb 22 09:55:06 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] xsd port to Borland C++ In-Reply-To: <43FB3601.7010801@noos.fr> References: <43FAF1D6.7070802@noos.fr> <20060221145938.GA2771@karelia> <43FB3601.7010801@noos.fr> Message-ID: <20060222145506.GC2819@karelia> Hi, [I've CC'ed xsd-users back in; someone might be interested in this info.] Si Mohammed KHABBAZ writes: > I would appreciate it if you could give me some hints on building the > xsd compiler under windows. I downloaded the source package and I tried > to install the "build" package using "migwn" and I had some weird error. > Maybe it's because I'm using the "migwn sh" and you have marked "bash" > as prerequisite to install "build". > How do you build xsd under windows ? We use mingw port of g++. Unfortunately, the stock libstdc++ (Standard C++ Library, part of g++) that comes with the cygwin/mingw environment is compiled without support for wchar_t. You can read more about this here: http://www.mingw.org/MinGWiki/index.php/wide%20characters So we are using a custom-built linux-to-mingw g++ cross- compiler to build xsd for windows. There is another option (as suggested in the page above) - use STLPort instead of g++ libstdc++. I am going to investigate this and also prepare a guide on how to build xsd in the cygwin environment. Just give me a couple of days. 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/20060222/ad8eb93e/attachment.pgp From boris at codesynthesis.com Wed Feb 22 12:06:50 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] :: Segmentation fault :: In-Reply-To: References: Message-ID: <20060222170650.GA3170@karelia> Hi, It's the first time I see a bug report in a poem-like style ;-). galathaea galathaea writes: > upgrading make (3.81beta4) changed the nature of the problem This stuff is a bit messy at the moment. make-3.81 is being released with betas and release candidates floating around. Soon (hopefully this coming Sunday) it will all be in the past. The 3.81beta4 has some bugs that make it incompatible with the latest build (0.2.1). Unfortunately, even 3.81rc1, released last Sunday, has some critical bugs that make it unusable. I have created a distribution of make from CVS that is known to work with build-0.2.1. You can get it here: http://codesynthesis.com/~boris/tmp/make-3.81rc1.tar.bz2 Note that even though it says 3.81rc1, it actually includes additional fixes from CVS. Let me know if you run into any other problems. -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/20060222/ac434cf2/attachment.pgp From boris at codesynthesis.com Wed Feb 22 12:11:32 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] :: Segmentation fault :: In-Reply-To: References: Message-ID: <20060222171132.GB3170@karelia> Hi, galathaea galathaea writes: > i am building a project > with xsd > that i want to compile > on both macosx (gcc 4.0.0 - osx 10.4.4) > and linux (gcc 2.96 - kernel 2.4.18) > > i understand the linux doesn't meet the minimum gcc version > (i will be upgrading everything - including kernel - in a few weeks) The kernel version does not matter for xsd. You will definitely have to upgrade g++ though. Both 3.4.4 and 4.0.1 are known to work (we build using these versions). > but are there any known difficulties on the macosx? None that we are aware of. Apple's g++ 4.0.0 should work just fine. If you run into any problems please let me know and we will resolve them. 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/20060222/df9b8022/attachment.pgp From jf at magnu.polymtl.ca Fri Feb 24 16:42:51 2006 From: jf at magnu.polymtl.ca (Jean-Francois Dube) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Constructors Message-ID: <43FF7DDB.7050408@magnu.polymtl.ca> Would it be possible for the derived object to receive a base class object as argument at construction. For instance, in the polymorphism example, the superman_type class would also have the following for constructor: superman_type (person_type const&, can_fly::type const&); This little example shows how it would be useful. I have a myPerson class and a derived mySuperman class, and I use wrappers to transfert the content of my objects into xsd person_type and superman_type for serialization, as such: ////////////////////////////////////////////////////// // wrapper for the base class person_type PersonWrapper::toXsd( myPersonType& const ) { // create a xsd person_type handler for my own myPersonType object } // wrapper for the derived class superman_type SupermanWrapper::toXsd( mySupermanType& const my_hero ) { // take care of the Clark Kent part person_type a_xsd_person ( PersonWrapper::toXsd(my_hero) ) ; // add the superhero part superman_type a_xsd_superman ( a_xsd_person, my_hero.getCanFly() ) ; // then add optional and sequence properties for superman_type, if any return a_xsd_superman; // I could use new and auto_ptr.... } ////////////////////////////////////////////////////// That way, we don't have to duplicate the code that relates to the base class in the derived class wrapper. Also, is there a reason to prevent the generated handlers from having a default constructor? I understand that the current constructors prevent us from generating incomplete objects (per schema), but it would be convenient to be able to transfert all data to the xsd handlers using the standard accessors. It the previous example, it would have given the option of creating an empty superman_type (using the default contructor) outside of the wrapper and to pass it by reference to the wrapper (where it could be filled using the accessors). I also suspect that the constructor calls can become quite confusing for large objects. From jf at magnu.polymtl.ca Fri Feb 24 16:51:01 2006 From: jf at magnu.polymtl.ca (Jean-Francois Dube) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] using Message-ID: <43FF7FC5.9060301@magnu.polymtl.ca> Is there a way to use the standard library with sequence iterators? For intance, I could use the find_if() algorithm on a sequence of books : find_if ( begin, end, hasISBN( 1234 ) ) In this case, it would emulate the selector mecanism. From boris at codesynthesis.com Sat Feb 25 08:30:28 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] using In-Reply-To: <43FF7FC5.9060301@magnu.polymtl.ca> References: <43FF7FC5.9060301@magnu.polymtl.ca> Message-ID: <20060225133028.GB13480@karelia> Jean-Francois, Jean-Francois Dube writes: > Is there a way to use the standard library with sequence > iterators? > > For intance, I could use the find_if() algorithm on a sequence of books : > > find_if ( begin, end, hasISBN( 1234 ) ) > > In this case, it would emulate the selector mecanism. There are some parts missing in the iterator implementation in 1.9.0. I've fixed it on my workspace and put out a patch: http://codesynthesis.com/~boris/tmp/xsd-1.9.0-algorithm-extras.tar.bz2 Just replace containers.hxx in xsd/cxx/tree with the one in the archive. This will also appear in the next release. With this fix, the following example works fine for me: struct has_isbn { has_isbn (library::isbn v) : v_ (v) { } bool operator() (library::book const& b) const { return b.isbn () == v_; } private: library::isbn v_; }; catalog::book::iterator i ( std::find_if ( l->book ().begin (), l->book ().end (), has_isbn (679760806))); 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/20060225/3e80b5ea/attachment.pgp From carmi at avaya.com Sun Feb 26 03:50:47 2006 From: carmi at avaya.com (Carmi, Eyal (Eyal)) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Defining key and key ref Message-ID: Hi, I have the following schema: Where I tried to define 'pKey' attribute as a key, when I created the following file: -0 -0 -0 -0 It validates even though the pKey 'A' appears twice... I also tried defining 'pKey' as an element (instead of attribute) but the results are the same. I anyone manages to solve the problem I would appreciate an example of how to define a keyref based on this key. Thanks, Eyal Carmi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codesynthesis.com/pipermail/xsd-users/attachments/20060226/1f1117ac/attachment.html From boris at codesynthesis.com Sun Feb 26 08:45:51 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Defining key and key ref In-Reply-To: References: Message-ID: <20060226134551.GA17298@karelia> Eyal, Carmi, Eyal (Eyal) writes: > It validates even though the pKey 'A' appears twice... I also tried > defining 'pKey' as an element (instead of attribute) but the results are > the same. I tried your schema and test xml with xsd-1.9.0 and xerces-c-2.7.0 and everything works as expected: test.xsd: test.xml: -0 -0 -0 -0 driver.cxx: #include #include "test.hxx" int main () { try { MyFilters ("test.xml"); } catch (xml_schema::parsing const& e) { std::cerr << e << std::endl; return 1; } } $ xsd cxx-tree test.xsd $ g++ driver.cxx test.cxx -lxerces-c $ ./driver /tmp/test.xml:9:20 error: Duplicate key value declared for identity constraint of element 'MyFilters'. 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/20060226/d37ccddd/attachment.pgp From carmi at avaya.com Sun Feb 26 09:06:59 2006 From: carmi at avaya.com (Carmi, Eyal (Eyal)) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Defining key and key ref Message-ID: Strange, Are you aware of a bug in XMLSpy (I'm using it as my editor/validate) that may cause this problem? (It shows that the XML is valid...) Anyways, Thank you very much. -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Sunday, February 26, 2006 3:46 PM To: Carmi, Eyal (Eyal) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Defining key and key ref Eyal, Carmi, Eyal (Eyal) writes: > It validates even though the pKey 'A' appears twice... I also tried > defining 'pKey' as an element (instead of attribute) but the results > are the same. I tried your schema and test xml with xsd-1.9.0 and xerces-c-2.7.0 and everything works as expected: test.xsd: test.xml: -0 -0 -0 -0 driver.cxx: #include #include "test.hxx" int main () { try { MyFilters ("test.xml"); } catch (xml_schema::parsing const& e) { std::cerr << e << std::endl; return 1; } } $ xsd cxx-tree test.xsd $ g++ driver.cxx test.cxx -lxerces-c $ ./driver /tmp/test.xml:9:20 error: Duplicate key value declared for identity constraint of element 'MyFilters'. hth, -boris From boris at codesynthesis.com Sun Feb 26 09:02:10 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Constructors In-Reply-To: <43FF7DDB.7050408@magnu.polymtl.ca> References: <43FF7DDB.7050408@magnu.polymtl.ca> Message-ID: <20060226140210.GB17298@karelia> Jean-Francois, Jean-Francois Dube writes: > Would it be possible for the derived object to receive a base class > object as argument at construction. > > For instance, in the polymorphism example, the superman_type class would > also have the following for constructor: > > superman_type (person_type const&, can_fly::type const&); Yes, I think we can add an option to generate this c-tor in addition to the ones already there. > Also, is there a reason to prevent the generated handlers from having a > default constructor? > > I understand that the current constructors prevent us from generating > incomplete objects (per schema), Yes, that's the reason default c-tors are not generate for some types. > but it would be convenient to be able > to transfert all data to the xsd handlers using the standard accessors. > > It the previous example, it would have given the option of creating an > empty superman_type (using the default contructor) outside of the > wrapper and to pass it by reference to the wrapper (where it could be > filled using the accessors). > > I also suspect that the constructor calls can become quite confusing for > large objects. I don't see a reason why we can't have an option to always generate default c-tors for types. I can add these two options and build you a binary. Just let me know which platform(s)/package(s) you use. 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/20060226/0f7e216c/attachment.pgp From boris at codesynthesis.com Sun Feb 26 09:09:14 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] Defining key and key ref In-Reply-To: References: Message-ID: <20060226140914.GC17298@karelia> Eyal, Carmi, Eyal (Eyal) writes: > Strange, Are you aware of a bug in XMLSpy (I'm using it as my > editor/validate) that may cause this problem? (It shows that the XML is > valid...) I haven't personally used XMLSpy but I constantly hear people complaining (especially on the schema-dev mailing list) that in many areas XMLSpy does not conform to the XML Schema specification. You may also find the NIST online XML Schema and instance validator useful: http://www.mel.nist.gov/msid/validation/ It validates your schema and/or instance using a bunch of different validating parsers. 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/20060226/fa9c583d/attachment.pgp From boris at codesynthesis.com Mon Feb 27 02:40:02 2006 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:43 2009 Subject: [xsd-users] xsd port to Borland C++ In-Reply-To: <20060222145506.GC2819@karelia> References: <43FAF1D6.7070802@noos.fr> <20060221145938.GA2771@karelia> <43FB3601.7010801@noos.fr> <20060222145506.GC2819@karelia> Message-ID: <20060227074002.GA20161@karelia> Hi, Boris Kolpackov writes: > So we are using a custom-built linux-to-mingw g++ cross- compiler to > build xsd for windows. There is another option (as suggested in the > page above) - use STLPort instead of g++ libstdc++. I am going to > investigate this and also prepare a guide on how to build xsd in the > cygwin environment. Just give me a couple of days. After some minor modifications I was able to compile xsd using gcc-mingw under cygwin with STLPort instead of stock libstd++. Here is the guide: http://codesynthesis.com/~boris/tmp/mingw-build Please let me know if you run into any problems. 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/20060227/0c56d766/attachment.pgp