From hing.liu at gmail.com Sun Jul 2 05:36:20 2017 From: hing.liu at gmail.com (Hing Liu) Date: Sun Jul 2 05:36:32 2017 Subject: [xsd-users] multiple namespace prefix problem Message-ID: Hi Expert, I got a multiple namespace (due to xsd definition are in two different namespaces) and I can only remove one of the "prefix" through the use of: xml_schema::namespace_infomap map; like this: map[""].name = "http://www.ird.gov.hk/AEOI/crs/v1"; However, some classes are located in " http://www.ird.gov.hk/AEOI/aeoitypes/v1" and result the following:
*"> <*p1*:CountryCode>AF <*p1*:AddressFree> <*p1*:Line>Line1 <*p1*:Line>Line2 <*p1*:Line>Line3
I want to remove the "p1" and make it appear like:
AF Line1 Line2 Line3
How can I remove the prefix "p1"? Thanks, Hing From shynamatharu at gmail.com Sun Jul 2 00:53:24 2017 From: shynamatharu at gmail.com (joe florence) Date: Sun Jul 2 12:11:18 2017 Subject: [xsd-users] Can I retain custom type and original type? Message-ID: Hi Boris, Just a quick question, is it possible to retain functionality of built-in type along with its custom type defined or do I need to redefine everything in custom type that is there in built in type? For example, if I need to redefine xsd:time as custom type, do I need to have everything redefined that class time in date-time has? Thanks in advance. From boris at codesynthesis.com Mon Jul 3 12:56:15 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jul 3 12:56:24 2017 Subject: [xsd-users] Can I retain custom type and original type? In-Reply-To: References: Message-ID: joe florence writes: > Just a quick question, is it possible to retain functionality of built-in > type along with its custom type defined or do I need to redefine everything > in custom type that is there in built in type? > For example, if I need to redefine xsd:time as custom type, do I need to > have everything redefined that class time in date-time has? You should be able to inherit from the default implementation. Boris From boris at codesynthesis.com Mon Jul 3 13:00:55 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jul 3 13:01:05 2017 Subject: [xsd-users] multiple namespace prefix problem In-Reply-To: References: Message-ID: Hing Liu writes: >
xmlns:*p1*=*"http://www.ird.gov.hk/AEOI/aeoitypes/v1 > *"> > <*p1*:CountryCode>AF > <*p1*:AddressFree> > <*p1*:Line>Line1 > <*p1*:Line>Line2 > <*p1*:Line>Line3 > >
> > I want to remove the "p1" and make it appear like: > >
> AF > > Line1 > Line2 > Line3 > >
This is not going to be easy to achieve. You will have to serialize CountryCode and AddressFree separately into DOMElements. In such situations, the commonly-used approach is to assign a meaningful prefix to each namespace since when there is more then one, none of them is really the "default". Boris From ashish at ashishsinghal.com Wed Jul 12 03:44:27 2017 From: ashish at ashishsinghal.com (Ashish Singhal) Date: Wed Jul 12 04:13:02 2017 Subject: [xsd-users] xml_schema::date_time from std::string Message-ID: I'm trying to construct a xml_schema::date_time directly from std::string Any pointers on how to do this? From boris at codesynthesis.com Thu Jul 13 09:44:32 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jul 13 09:44:43 2017 Subject: [xsd-users] xml_schema::date_time from std::string In-Reply-To: References: Message-ID: Ashish Singhal writes: > I'm trying to construct a xml_schema::date_time directly from std::string If the string representation conforms to the XML Schema format then you should be able to use this constructor: date_time (const std::basic_string& s, const xercesc::DOMElement* e, flags f = 0, container* c = 0); You can pass NULL as the second argument. Boris From isharp at atis.org Mon Jul 17 08:40:07 2017 From: isharp at atis.org (Iain Sharp) Date: Mon Jul 17 08:40:20 2017 Subject: [xsd-users] XSD Vs XSD/e differences Message-ID: Hi Folks, I am looking at a project for an embedded application which is built around an object model derived from a set of already-defined XML Schema (XSD) files. The technical needs include: * Generate an in-memory C++ data model based on the XSD * Manipulate (read and write) the data model in C++ * Serialize data model instances to XML * Parse XML to create an instance of the data model * Export and import the data model to/from a DOM to allow serialization and parsing in protocols other than XML (the prototype uses Xerces in addition to XSD tree output) I built an initial trial based on XSD which works OK, but even with the best optimizations I can find the code size is rather large - this seems to be mostly due to the large number of objects defined in the XSD. Would swapping to XSD/e be expected to reduce the code size? If so, is there a rule of thumb for the benefit? On the "hello" example the code size actually seems to be bigger in XSD/e rather than XSD which I guess is due to substituting for the dynamically linked dependency on Xerces. Is there a guide to the functional differences between XSD and XSD/e? The introductory material on the web site seems to imply the functionality and generated code is very similar. Regards Iain From boris at codesynthesis.com Mon Jul 17 09:05:18 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jul 17 09:05:27 2017 Subject: [xsd-users] XSD Vs XSD/e differences In-Reply-To: References: Message-ID: Iain Sharp writes: > * Export and import the data model to/from a DOM to allow serialization > and parsing in protocols other than XML (the prototype uses Xerces in > addition to XSD tree output) This will be pretty hard to achieve in XSD/e since it doesn't have an intermediate representation like this. > I built an initial trial based on XSD which works OK, but even with > the best optimizations I can find the code size is rather large - > this seems to be mostly due to the large number of objects defined > in the XSD. > > Would swapping to XSD/e be expected to reduce the code size? Highly unlikely. XSD/e will generate even more code for each schema type (for parser and serializer), especially if you don't disable validation. Another thing you can try is look through --suppress-* options in XSD to eliminate features you don't need. Plus --generate-inline is a good idea. Finally, if desperate, you may want to disable generation of parsing/serialization functions (--root-element-none) and set this up yourself. In fact, generating these for all the global elements is usually a source of huge (and usually unnecessary) bloat. > Is there a guide to the functional differences between XSD and XSD/e? There is no feature-by-feature comparison. Generally, XSD has more features, is more powerful, flexible, and convenient. My recommendation would be to go with XSD unless you have a good reason to prefer XSD/e and are prepared for a "spartan" object model. In your case I believe XSD is a better choice. Boris From isharp at atis.org Mon Jul 17 09:56:59 2017 From: isharp at atis.org (Iain Sharp) Date: Mon Jul 17 09:57:16 2017 Subject: [xsd-users] XSD Vs XSD/e differences In-Reply-To: References: Message-ID: Hi Boris, Thanks for the answer - this is very helpful. > In fact, generating these for all the global elements is usually a source of huge (and usually unnecessary) bloat. Yes, ultimately I think this is the root cause of our problem. I will look at how we can optimize-out unneeded elements and features. Regards Iain -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: 17 July 2017 14:05 To: Iain Sharp Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] XSD Vs XSD/e differences Iain Sharp writes: > * Export and import the data model to/from a DOM to allow serialization > and parsing in protocols other than XML (the prototype uses Xerces in > addition to XSD tree output) This will be pretty hard to achieve in XSD/e since it doesn't have an intermediate representation like this. > I built an initial trial based on XSD which works OK, but even with > the best optimizations I can find the code size is rather large - this > seems to be mostly due to the large number of objects defined in the > XSD. > > Would swapping to XSD/e be expected to reduce the code size? Highly unlikely. XSD/e will generate even more code for each schema type (for parser and serializer), especially if you don't disable validation. Another thing you can try is look through --suppress-* options in XSD to eliminate features you don't need. Plus --generate-inline is a good idea. Finally, if desperate, you may want to disable generation of parsing/serialization functions (--root-element-none) and set this up yourself. In fact, generating these for all the global elements is usually a source of huge (and usually unnecessary) bloat. > Is there a guide to the functional differences between XSD and XSD/e? There is no feature-by-feature comparison. Generally, XSD has more features, is more powerful, flexible, and convenient. My recommendation would be to go with XSD unless you have a good reason to prefer XSD/e and are prepared for a "spartan" object model. In your case I believe XSD is a better choice. Boris