From petteri.tolonen at logica.com Tue Sep 1 02:33:58 2009 From: petteri.tolonen at logica.com (Tolonen, Petteri) Date: Sun Oct 11 15:34:10 2009 Subject: [xsd-users] Total Digits Message-ID: <9CD0EFB2583B894190C8D1883F0085B533CA38F78E@SE-EX007.groupinfra.com> Hi, I have a problem with Total Digits restriction... I think it should work differently. Here is part of my schema: Positive decimals work nicely, but i can't output negative -99999999999.999 value because totalDigits cuts one digit from the end result is -99999999999.99 I am pretty sure that totalDigits shouldn't take the minus sign in count of digits. Xerces validates both -99999999999.999 as OK. I think this is bug in XSD Platform information: Redhat xsd-3.2.0-1.x86_64 xerces-c_2_8_0-x86_64 Petteri Tolonen From boris at codesynthesis.com Wed Sep 2 05:04:37 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:10 2009 Subject: [xsd-users] Total Digits In-Reply-To: <9CD0EFB2583B894190C8D1883F0085B533CA38F78E@SE-EX007.groupinfra.com> References: <9CD0EFB2583B894190C8D1883F0085B533CA38F78E@SE-EX007.groupinfra.com> Message-ID: Hi Petteri, Tolonen, Petteri writes: > I am pretty sure that totalDigits shouldn't take the minus sign in > count of digits. Yes, this is a bug in XSD. I have fixed it for the next release and you can apply it to 3.2.0 by getting this package: http://codesynthesis.com/~boris/tmp/xsd-3.2.0-total-digits-sign.tar.gz And replacing files in 3.2.0 with the versions in the archive. Thanks for reporting this! Boris From boris at codesynthesis.com Wed Sep 2 12:06:44 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:10 2009 Subject: [xsd-users] import, include, namespaces, restriction and schema versioning In-Reply-To: <4A9BFE13.1050201@boostpro.com> References: <4A8B1C3A.2040406@boostpro.com> <4A8C2521.5060102@boostpro.com> <4A8EC2DA.9060401@boostpro.com> <4A9BFE13.1050201@boostpro.com> Message-ID: Hi Eric, Eric Niebler writes: > > (2) Notify the user somehow about missing elements, presumably, > > during parsing. > > I wasn't thinking of that. By "user" you mean me, the user of CodeSynth, > right? Right. > And by "notify" you mean invoke a registered callback. Correct. > Huh, could be useful, but is beyond my basic needs. Without this mechanism you (or someone else) will have to maintain code which "knows" about all the additions to the vocabulary and check the document for their absence. I think it would be a good idea to automate this task. For example, with the callback approach I described in my previous email, if you forget to actually implement it, you will get a compiler/linker error. I agree, though, that if most of your additions are covered by the default values feature, this mechanism is not critical. > > Wouldn't this be more naturally done during parsing so that the > > application developer doesn't have to worry about missing elements? > > More naturally? Why? My intention is that the resulting XML produced by > our tools is always in the most up-to-date form and doesn't need to be > read back in in order to be patched up. The output XML will be the same regardless of when you do the fixup, on read or on write. However, if you do it on read, the application itself will only need to know about the latest version of the schema. If the fixup is done on write, the application should be prepared to handle both old and new document versions. > But the fix-up-on-write thought is beyond my basic needs. For my > scenario, what I'd like is: > > 1) On write, assert when a writeRequired element is missing. > > 2) On read, when a writeRequired element is missing, fill in a default > value. What do you mean by assert? Treat is as an error? Also, if the document is going to be fixed on read, the only reason to also verify it on write would be if the application logic can modify it so that it does not conform to the new vocabulary version (normally, without generating default c-tors, this won't be possible). Or am I missing something? > I was hoping it could be as simple as something like this: > > > ... > > > > > ... > > > name="SomeOtherType"> > > type="MyType" > minOccurs="0" > xse:writeRequired="true" > xse:defaultValue="MyTypeDefault"/> > > This won't be valid XML Schema because the MyTypeDefault declaration would need to be able to contain arbitrary XML fragments, for example: foo 1 2 3 I think the only way to capture such information directly in XML Schema is to use the appinfo element which allows arbitrary content, for example: foo 1 2 3 This might actually be a better idea than a separate default values file and XPath expressions. > Whoa, you're going WAY beyond anything I had in mind. :-) Pretty cool, > but feels over-engineered for my purposes. Yes, it feels a bit wild at the beginning (C++ function names in XML Schema). But then I try to avoid incomplete solutions since people will keep coming back and asking why this, now "obvious", feature is not supported ;-). > Could it really be accomplished? The C++ callbacks are actually very easy to implement. The custom header with their declarations can be included using the --hxx-prologue option. The default value part is harder mainly because of the difficulty of initializing a static object model fragment from XML. But I think I have an idea. What I can do, fairly easily, is, based on the DOM fragment that represents the default value, generate a series of C++ calls that re-create this DOM fragment. This code can then be used to "build up" the DOM document with fragments corresponding to the default values when they are missing. The nice thing about this approach is that it will work transparently with other features such as the DOM association. The only problem that I see so far is const- correctness (DOMDocument and DOMElement are passed as const references to parsing functions/c-tors). Boris From boris at codesynthesis.com Wed Sep 2 12:53:23 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:10 2009 Subject: [xsd-users] import, include, namespaces, restriction and schema versioning In-Reply-To: <87eiqt51f2.fsf@sympatico.ca> References: <4A8B1C3A.2040406@boostpro.com> <87ab1ru5wb.fsf@sympatico.ca> <87eiqt51f2.fsf@sympatico.ca> Message-ID: Hi Bill, Bill Pringlemeir writes: > The schema has parts of a SOAP infra-structure with 'request' and > 'response' messages. I meant that the service provider will never be > the application. So I will only ever want my application to have > 'getters' and parsing code for the 'response' and only 'setters' and > serialization code for the request. Hm, I see what you mean now. The parsing/serialization split is possible now if you can split the schema into two, one for the request, one for the response. Without the schema split the only way to make it work would be to tell the XSD compiler which types are read-only and which are write-only. This can be quite tedious. I also had and idea of having a --read-only option that would make the XSD compiler only generate accessors and omit modifiers and most of the c-tors. I am not sure if --write-only (i.e., an object model which only supports modifications) would be useful. BTW, which library/tool do you use for the SOAP part? > XSD tends to generate multiple constructors which can be very > expensive with elements. Especially if polymorphism, base-ctor, > and auto_ptr variants are all in use. Yes, there is going to be a significant improvement in this area in the next release of XSD. > I think parts of the versioning discussion are still relevant. Yes, I agree. Though you seem to be talking about an opposite transformation. That is, instead of extending the schemas, you are interested in subsetting them. > A main point in all of these discussions being that we wish to produce > and parse XML as defined by a primary schema, but wish to deal in an > object model that is a subset. It seems to me that there are two dimensions to this: code and data. You want to only have a subset of code that corresponds to the subset of the schema (and subset of functionality, such as parsing/serialization, access/modify) that you are interested in. And you only want a subset of data that you get or need to set (e.g., "fixed" or pre-filled USD as currency). I think most of such subsetting should be handled outside of XSD. Some things, such as functionality subsetting, can be handled by XSD. One approach that some standards bodies (e.g., OGC) employ to achieve this is the notion of a schema profile. That is, they create a subset of the full schema for a particular purpose which they call a profile. > Xpath/xslt/XQuery type rules to transform an industry schema to a > working schema for XSD to process. I don't know what kind of rules > would allow transformation so that the input/output documents were > handled. It is fairly easy to ignore input xml ( minOccurs="0"/>). Perhaps for the output, > would be the appropriate translation. This isn't much more help than > just editing the schema by hand. I think the main problem with such transformations is that they don't understand the semantics of the data they are transforming. For example, they won't be able to check or ensure that the modified type is a subset of the original. > However, a well thought out set of transformations that could be > applied programatically would lower the barrier for a novice and > also allow for updates of the primary schema. The down side to that > is a new language that could just as well confuse things. A general-purpose profiling or versioning tool that understands the semantics of the XML Schema language could be an interesting project. The hard part would be to come up with a set of "legal" transformations that will result in a "true" subset. For example, for the write direction it would be legal to remove optional elements and attributes (and replace them with xs:any for the read direction). Or to add a default value for an attribute (too bad there are no usable default elements in XML Schema; we could generate a DOM fixup code to address this). In fact, this is somewhat similar to the inheritance-by-restriction mechanism in XML Schema. Boris From duncan.blair at scu.edu.au Thu Sep 10 01:41:03 2009 From: duncan.blair at scu.edu.au (Duncan Blair) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Enabling the Full Checking parameter on the Xerces Parser Message-ID: <4AA8916F.9040103@scu.edu.au> Hi All, I am trying to enable the fgXercesSchemaFullChecking option on the xerces parser. It appears that there is no way to enable it no matter what flags are passed. This results in (atleast) an unreported error being thrown if an element in the schema is missing a required attribute. See lines 341 and 352 of file parsing-source.txx in the install folder \CodeSynthesis XSD 3.2\include\xsd\cxx\xml\dom\ Any thoughts? Thanks, Duncan -- ------------------------------------------------ Duncan Blair B.InfTech(Software Engineering) B.InfTech(Hons 1st class) * Technical Officer Southern Cross University - Faculty of Health and Applied Science -- School of Health and Human Science Office: M.1.30 (M block, Coffs Harbour Campus) Email: duncan.blair@scu.edu.au Phone(International): +61 2 6659 3064 Phone(Australia): 02 6659 3064 Fax(International): +61 2 6659 3202 Fax(Australia): 02 6659 3202 Mobile: 0408 628 432 Postal: Health and Human Science Southern Cross University Hogbin Dr. Coffs Harbour NSW 2450 Australia ------------------------------------------------- http://infotech.scu.edu.au/~dblair/ ------------------------------------------------- From boris at codesynthesis.com Thu Sep 10 03:13:29 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Enabling the Full Checking parameter on the Xerces Parser In-Reply-To: <4AA8916F.9040103@scu.edu.au> References: <4AA8916F.9040103@scu.edu.au> Message-ID: Hi Duncan, Duncan Blair writes: > I am trying to enable the fgXercesSchemaFullChecking option on the > xerces parser. It appears that there is no way to enable it no matter > what flags are passed. This results in (atleast) an unreported error > being thrown if an element in the schema is missing a required attribute. The full schema checking feature in Xerces-C++ enables the more expensive error detection in the schema definition itself, as opposed to the XML documents. Since the schemas that you use for validation were presumably compiled with XSD (which has the full checking enabled), there is normally no need to do the same in the application. In other words, if you use the same schemas for code generation and validation, then the full checking has been performed during code generation. There could be (rare) situations where you use schemas for validation which haven't been processed by XSD. For example, you could have schemas that are used to validate content matched by wildcards. In such situations it may make sense to use the full schema checking feature. To enable it, you will need to perform your own XML-to-DOM parsing. This way you will be able to configure the parser the way you want. See the 'multiroot' example in the examples/cxx/tree/ directory, in particular, the dom-parser.* files, for an example on how to do this. Boris From duncan.blair at scu.edu.au Fri Sep 11 03:05:02 2009 From: duncan.blair at scu.edu.au (Duncan Blair) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Enabling the Full Checking parameter on the Xerces Parser In-Reply-To: References: <4AA8916F.9040103@scu.edu.au> Message-ID: <4AA9F69E.9010604@scu.edu.au> Hi Boris, Thanks for the quality reply. It seems obvious now you say it. I will rethink my approach. Thanks again, Duncan On 10/09/2009 5:13 PM, Boris Kolpackov wrote: > Hi Duncan, > > Duncan Blair writes: > >> I am trying to enable the fgXercesSchemaFullChecking option on the >> xerces parser. It appears that there is no way to enable it no matter >> what flags are passed. This results in (atleast) an unreported error >> being thrown if an element in the schema is missing a required attribute. > > The full schema checking feature in Xerces-C++ enables the more > expensive error detection in the schema definition itself, as > opposed to the XML documents. Since the schemas that you use > for validation were presumably compiled with XSD (which has > the full checking enabled), there is normally no need to do > the same in the application. In other words, if you use the > same schemas for code generation and validation, then the > full checking has been performed during code generation. > > There could be (rare) situations where you use schemas for > validation which haven't been processed by XSD. For example, > you could have schemas that are used to validate content > matched by wildcards. In such situations it may make sense > to use the full schema checking feature. To enable it, you > will need to perform your own XML-to-DOM parsing. This way > you will be able to configure the parser the way you want. > See the 'multiroot' example in the examples/cxx/tree/ > directory, in particular, the dom-parser.* files, for an > example on how to do this. > > Boris > > -- ------------------------------------------------ Duncan Blair B.InfTech(Software Engineering) B.InfTech(Hons 1st class) * Technical Officer Southern Cross University - Faculty of Health and Applied Science -- School of Health and Human Science Office: M.1.30 (M block, Coffs Harbour Campus) Email: duncan.blair@scu.edu.au Phone(International): +61 2 6659 3064 Phone(Australia): 02 6659 3064 Fax(International): +61 2 6659 3202 Fax(Australia): 02 6659 3202 Mobile: 0408 628 432 Postal: Health and Human Science Southern Cross University Hogbin Dr. Coffs Harbour NSW 2450 Australia ------------------------------------------------- http://infotech.scu.edu.au/~dblair/ ------------------------------------------------- From simon at thinkresearch.co.uk Tue Sep 15 13:21:39 2009 From: simon at thinkresearch.co.uk (PICKUP Simon) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Removing whitespace from xml document Message-ID: <000001ca3629$0500fbb0$0f02f310$@co.uk> Hi, I am serialising to XML a system memory Document Object Model using the simple serialisation function copied below. The problem is, the resulting xml file is incredibly large due to all the tabs and whitespace in the file. Is there any modifier or function I can use to write the xml file without whitespace and tabs? //SERIALIZE BACK TO XML std::string filename = "ACE_RUNWAY_"+sims_iter->getname()+"_"+sims_iter->getscenario()+".xml"; xml_schema::namespace_infomap map; map[""].schema = "ACE_RUNWAY_ANALYSIS_DOM.xsd"; std::ofstream ofs (filename.c_str()); ACE_RUNWAY_ANALYSIS(ofs, R, map); Many thanks ................................ Simon Pickup ' +44 (0) 1202 247 204 ? +44 (0) 7595 280 363 * simon@thinkresearch.co.uk ................................ http://www.thinkresearch.co.uk/TRlogoemail_sig.jpg www.thinkresearch.co.uk Cromwell House | 64-68 Calvin Road | Bournemouth | Dorset | BH9 1LN | UK -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 17424 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20090915/e5a6a783/attachment.jpe From boris at codesynthesis.com Wed Sep 16 09:56:46 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Removing whitespace from xml document In-Reply-To: <000001ca3629$0500fbb0$0f02f310$@co.uk> References: <000001ca3629$0500fbb0$0f02f310$@co.uk> Message-ID: Hi Simon, PICKUP Simon writes: > Is there any modifier or function I can use to write the xml file without > whitespace and tabs? > > [...] > > ACE_RUNWAY_ANALYSIS(ofs, R, map); Assuming you are using XSD 3.2.0, you can pass the dont_pretty_print flag to the serialization functions. For example: ACE_RUNWAY_ANALYSIS(ofs, R, map, "UTF-8", xml_schema::flags::dont_pretty_print); For more information on serialization flags, see Section 4.3, "Flags" in the C++/Tree Mapping User Manual: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#4.3 Boris From boris at codesynthesis.com Fri Sep 18 03:46:31 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Removing whitespace from xml document In-Reply-To: <000001ca37ac$ff5fee20$fe1fca60$@co.uk> References: <000001ca3629$0500fbb0$0f02f310$@co.uk> <000001ca37ac$ff5fee20$fe1fca60$@co.uk> Message-ID: Hi Simon, [I CC'ed xsd-users in case others are interested in this.] PICKUP Simon writes: > I did expect this process to actually decrease the size of my xml > output - it hasn?t. It has however successfully removed all the > whitespace and tabs. It probably did decrease the size, just no significantly. There a few more things that you can do or may want to consider: 1. If your schemas use attributes with default values heavily, then you may want to omit them from the output XML. To do this you will need to recompile your schemas with the --omit-default-attributes option. 2. You may want to consider compressing the resulting XML before storage or over-the-wire transfer. This can be done on the fly with a compression library (e.g., zlib) and custom Xerces-C++ InputSource and XMLFormatTarget implementations. 3. You may want to consider using binary serialization of XML for storage or over-the-wire transfer. This will work well if both the producer and consumer of your XML are using the XSD-generated object model (or you can convert from binary to the XML representation as required). See Section 5.2, "Binary Serialization" in the C++/Tree Mapping User Manual for more information: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#5.2 Boris From juanpablo.perez at gmail.com Fri Sep 18 15:17:36 2009 From: juanpablo.perez at gmail.com (Juan Pablo Perez) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Failing to parse XML document generated with the same code. Message-ID: <9ef90e310909181217q4142d9baje7f530e6d1587efa@mail.gmail.com> Hi, I'm working with a simple XSD schema: And then, using code I dump a simple XML document: xml_t xml("PAN", "TYPE", 10.50, 9); xml_schema::namespace_infomap map; map[""].name = ""; map[""].schema = "xml1.xsd"; msg(cout, xml, map); That results on this: PAN TYPE 10.5 9 Then I try to load that same XML with the following code in the same application (2 lines down from before): try { auto_ptr xml(msg("xml1.xml")); } catch (const xml_schema::exception& e) { cerr << e << endl; return 1; } And when I run the code I get the following errors: xml1.xml:2:93 error: Unknown element 'msg' xml1.xml:2:93 error: Attribute 'xmlns' is not declared for element 'msg' xml1.xml:2:93 error: Attribute '{http://www.w3.org/2000/xmlns/}xsi' is not declared for element 'msg' xml1.xml:2:93 error: Attribute '{http://www.w3.org/2001/XMLSchema}schemaLocation' is not declared for element 'msg' xml1.xml:4:8 error: Unknown element 'pan' xml1.xml:6:9 error: Unknown element 'type' xml1.xml:8:11 error: Unknown element 'amount' xml1.xml:10:13 error: Unknown element 'respcode' I think that the document I created should be parsed back in easily... What am I doing wrong? Thanks and regards. Juan Any ideas From boris at codesynthesis.com Fri Sep 18 15:54:16 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Failing to parse XML document generated with the same code. In-Reply-To: <9ef90e310909181217q4142d9baje7f530e6d1587efa@mail.gmail.com> References: <9ef90e310909181217q4142d9baje7f530e6d1587efa@mail.gmail.com> Message-ID: Hi Juan, Juan Pablo Perez writes: > And when I run the code I get the following errors: > > xml1.xml:2:93 error: Unknown element 'msg' I created a test case based on your schema and code. It works fine if I keep xml1.xsd in the same directory as xml1.xml. If I move this file somewhere else, I get the same errors you do. I also got the following warning before all the errors: warning: unable to open primary document entity 'xml1.xsd' Do you get the warning as well? If you do, then the problem is that the parser cannot find the schema to validate the XML document. For various ways to resolve this see Section 5.1, "XML Schema Validation and Searching" in the C++/Tree Mapping Getting Started Guide: http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#5.1 Boris From juanpablo.perez at gmail.com Fri Sep 18 20:16:19 2009 From: juanpablo.perez at gmail.com (Juan Pablo Perez) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Failing to parse XML document generated with the same code. In-Reply-To: References: <9ef90e310909181217q4142d9baje7f530e6d1587efa@mail.gmail.com> Message-ID: <9ef90e310909181716m355ca347r399a80a9f1d9a126@mail.gmail.com> Boris, Thanks for the amaizingly quick reply! The files are all on the same directory and I don't get any more errors or warning that the ones on my previous email... so, no, I don't get: warning: unable to open primary document entity 'xml1.xsd' :S Regards. Juan On Fri, Sep 18, 2009 at 4:54 PM, Boris Kolpackov wrote: > Hi Juan, > > Juan Pablo Perez writes: > >> And when I run the code I get the following errors: >> >> xml1.xml:2:93 error: Unknown element 'msg' > > I created a test case based on your schema and code. It works fine > if I keep xml1.xsd in the same directory as xml1.xml. If I move > this file somewhere else, I get the same errors you do. I also got > the following warning before all the errors: > > warning: unable to open primary document entity 'xml1.xsd' > > Do you get the warning as well? If you do, then the problem is that > the parser cannot find the schema to validate the XML document. For > various ways to resolve this see Section 5.1, "XML Schema Validation > and Searching" in the C++/Tree Mapping Getting Started Guide: > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/guide/#5.1 > > Boris > From boris at codesynthesis.com Sat Sep 19 12:13:34 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Failing to parse XML document generated with the same code. In-Reply-To: <9ef90e310909181716m355ca347r399a80a9f1d9a126@mail.gmail.com> References: <9ef90e310909181217q4142d9baje7f530e6d1587efa@mail.gmail.com> <9ef90e310909181716m355ca347r399a80a9f1d9a126@mail.gmail.com> Message-ID: Hi Juan, Juan Pablo Perez writes: > The files are all on the same directory and I don't get any more > errors or warning that the ones on my previous email. Hm, that's getting interesting. Just to make sure that we are talking about the same code, can you try this test: http://www.codesynthesis.com/~boris/tmp/test.tar.gz I build it like this: $ xsd cxx-tree --generate-serialization xml1.xsd $ g++ *.cxx -lxerces-c If you still get the errors, can you let me know more about your setup (OS, compiler, Xerces-C++ and their versions) so that I could try to reproduce this. Also can you try to run one of the Xerces-C++ examples on the output XML, for example: $ DOMCount -v=always -n -s -f xml1.xml Boris From juanpablo.perez at gmail.com Mon Sep 21 09:02:26 2009 From: juanpablo.perez at gmail.com (Juan Pablo Perez) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Failing to parse XML document generated with the same code. In-Reply-To: References: <9ef90e310909181217q4142d9baje7f530e6d1587efa@mail.gmail.com> <9ef90e310909181716m355ca347r399a80a9f1d9a126@mail.gmail.com> Message-ID: <9ef90e310909210602v60a45737n57b4479efa7e6056@mail.gmail.com> Boris, Thanks again! I've tested the example you gave me and works perfectly. My enviroment is AIX 5.3 using XL C/C++ 7. I changed my code to this: try { ofstream ofile("test.xml"); xml_t xml("PAN", "TYPE", 10.50, 9); xml_schema::namespace_infomap map; map[""].name = ""; map[""].schema = "xml1.xsd"; msg(ofile, xml, map); ifstream ifile("test.xml"); auto_ptr xml(msg(ifile, "test.xml")); } catch (const xml_schema::exception& e) { cerr << e << endl; } And it writes down a XML file and reads it back ok. I just can't understand where was the mistake on my previous code, but now it's working. Thanks and best regards. Juan On Sat, Sep 19, 2009 at 1:13 PM, Boris Kolpackov wrote: > Hi Juan, > > Juan Pablo Perez writes: > >> The files are all on the same directory and I don't get any more >> errors or warning that the ones on my previous email. > > Hm, that's getting interesting. Just to make sure that we are > talking about the same code, can you try this test: > > http://www.codesynthesis.com/~boris/tmp/test.tar.gz > > I build it like this: > > $ xsd cxx-tree --generate-serialization xml1.xsd > $ g++ *.cxx -lxerces-c > > If you still get the errors, can you let me know more about > your setup (OS, compiler, Xerces-C++ and their versions) so > that I could try to reproduce this. > > Also can you try to run one of the Xerces-C++ examples on > the output XML, for example: > > $ DOMCount -v=always -n -s -f xml1.xml > > Boris > From bpringle at sympatico.ca Tue Sep 22 23:27:28 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Non-xml data in attributes with xsd:string, xsd:normalizedString In-Reply-To: (Boris Kolpackov's message of "Fri, 26 Jun 2009 21:13:28 +0200") References: <87r61vb2ni.fsf@sympatico.ca> <87bpsye6yz.fsf@sympatico.ca> <87eitgb0qp.fsf@sympatico.ca> Message-ID: <87ljk6uyqn.fsf@sympatico.ca> On 26 Jun 2009, boris@codesynthesis.com wrote: > Bill Pringlemeir writes: >> I guess that Xerces mandates a UTF-? encoding. Does Xereces then >> convert to the specified encoding, for instance 'US-ASCII'. > There are three encoding at play here, the second is normally not > visible to the end-user, except for some situations: > 1. The encoding in the object model. This is by default UTF-8. > 2. The UTF-16 encoding used in Xerces-C++. > 3. The encoding of the resulting XML document. This can be specified > in the serialization function. > Conversion between (1) and (2) is performed by the object model, > between (2) and (3) -- by Xerces-C++. [snip] > I think the simplest way would be to use XSD_USE_LCP and set the > local code page to US-ASCII. But the availability of this approach > depends on the OS(es) you are targeting. Otherwise you will need > to make sure your binary data is properly UTF-8-encoded (i.e., > characters above 0x7F are replaced with two-byte sequences). The XSD_USE_LCP requires setting locales which effects the rest of the application. In layer '1.' above is UTF-8 only due to xsd::cxx::xml::transcode() implementation? For my case, I rewrote this method to simply copy low bit items and escape high bits. There is no need for any exceptions. A 'XSD_USER_TRANSCODE' would be more useful than the XSD_USE_LCP (which is for historical reasons?). This macro would allow a user to over-ride the base transcode() behaviour. That would work on both Windows and *nix and would allow a user to implement arbitrary conversion from std::string (whatever model the user has) and the layer 2. The layer 1 *seems* contrived to me. Is there some sort of tag matching, etc that XSD is doing that would care about the character encoding of data in the model? Of course UTF-8 is a good choice, but it is probably often the case that the user wishes layer 1 and 3 to be the same. It is powerful to allow different encodings [between the model and the resultant XML], but I don't think that a majority of XSD users are using this? Regards, Bill Pringlemeir. -- Keep things as simple as possible, but no simpler. - A. Einstein From boris at codesynthesis.com Thu Sep 24 09:22:49 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Non-xml data in attributes with xsd:string, xsd:normalizedString In-Reply-To: <87ljk6uyqn.fsf@sympatico.ca> References: <87r61vb2ni.fsf@sympatico.ca> <87bpsye6yz.fsf@sympatico.ca> <87eitgb0qp.fsf@sympatico.ca> <87ljk6uyqn.fsf@sympatico.ca> Message-ID: Hi Bill, Bill Pringlemeir writes: > On 26 Jun 2009, boris@codesynthesis.com wrote: > > > 1. The encoding in the object model. This is by default UTF-8. > > > 2. The UTF-16 encoding used in Xerces-C++. > > > 3. The encoding of the resulting XML document. This can be specified > > in the serialization function. > > > In layer '1.' above is UTF-8 only due to xsd::cxx::xml::transcode() > implementation? You need to specify some encoding for the text in object model. Otherwise it is not clear how to convert from/to UTF-16. > This macro would allow a user to over-ride the base transcode() > behaviour. I think it is a good idea to allow something like this. However, it is not clear how to support such an overriding. Currently the transcode and transcode_to_xmlch function are defined in libxsd and used throughout the runtime and generated code. They are function templates so the "global variable that contains the pointer to the transcode function" approach won't work. The only way that I can think of that will work is to completely remove those definitions if, say XSD_USE_CUSTOM_ENCODING, is defined. It will then be the user's responsibility to include the suitable implementations at the beginning of the generated code using, for example, the --hxx-prologue option. There are two problems with this approach: 1. If some libxsd headers are included directly, one will need to remember to include the transcode definitions before that. 2. Element/attribute names in the generated code are in UTF-8. This probably won't be a big deal since 99.9% of such names are in ASCII. However, I have seen schema with enumeration value that contain non-ASCII characters and this can be a problem for some schema. Any thoughts? > It is powerful to allow different encodings [between the model > and the resultant XML], but I don't think that a majority of XSD > users are using this? So far there were a few requests to allow selecting ISO-Latin-1 encoding instead of UTF-8 which we will probably implement for the next release. But since we don't plan to support all possible encodings, I am quite interested in a generic solution like the above. Boris From zszatmary at gmail.com Fri Sep 25 17:01:30 2009 From: zszatmary at gmail.com (Zoltan Szatmary) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] --custom-type-regex bug Message-ID: <2df4c600909251401u1b917093n3df8a72da2cc380c@mail.gmail.com> Dear Developers, it seems to me, that --custom-type-regex does not work as expected when generating C++/Tree. An option given to xsd.exe in the form of --custom-type-regex /Foo(.*)/Bar\1/ yields typedefs explicitly defining a 'Bar\1' type every time a type name starting with 'Foo' in the XSD is matched. I suspect that the cause of this behavior is at the lines 401 and 454 in file {$src_root}\xsd-3.2.0-1\xsd\cxx\tree\elements.cxx Instead of r = i->pat.merge (name, i->type_sub); and r = i->pat.merge (name, i->base_sub); there should be r = i->pat.merge (i->type_sub, name); and r = i->pat.merge (i->base_sub, name); respectively. I may be wrong though, in which case I apologize and ask you for advice on how to use --custom-type-regex properly. Environment: Windows XP, VC++ 8.0, CodeSynthesis XSD 3.2 yours, Zoltan Szatmary-Ban From leonid.gershanovich at 247realmedia.com Mon Sep 28 00:56:45 2009 From: leonid.gershanovich at 247realmedia.com (Gershanovich, Leonid) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] xs:choice representation in C++ Message-ID: Boris, I was wondering if you considered to use something like boost::variant (http://www.boost.org/doc/libs/1_40_0/doc/html/variant.html) for mapping xs:choice to c++. It seems that representing following xsd construct: As typedef string stringEl_type; typedef int intEl_type; boost::variant < stringEl_type , intEl_type > m_choicer; Is little cleaner in terms of expressing intended object model than optional < string > stringEl; optional < int > intEl; Besides this way it will be harder to forget handling a specific choice, as instead of series of statements like: If (stringEl.present()) { ... } If (intEl.present()) { ... } boost:variant will let compiler check if overloads for every type in the choice have been defined, thus developer is less likely to forget to handle a particular "choice". This is especially true for schemas that are under active development. class my_visitor : public boost::static_visitor { public: int operator()(intEl_type i) const { return i; } int operator()(const stringEl_type & str) const { return str.length(); } }; What do you think? Leonid From boris at codesynthesis.com Mon Sep 28 04:00:59 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] --custom-type-regex bug In-Reply-To: <2df4c600909251401u1b917093n3df8a72da2cc380c@mail.gmail.com> References: <2df4c600909251401u1b917093n3df8a72da2cc380c@mail.gmail.com> Message-ID: Hi Zoltan, Zoltan Szatmary writes: > it seems to me, that --custom-type-regex does not work as expected > when generating C++/Tree. An option given to xsd.exe in the form of > > --custom-type-regex /Foo(.*)/Bar\1/ > > yields typedefs explicitly defining a 'Bar\1' type every time a type > name starting with 'Foo' in the XSD is matched. The regex expressions used in XSD are all in the perl notation so you need to use $1 instead of \1 (which is a sed notation). Boris From boris at codesynthesis.com Mon Sep 28 10:11:07 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] xs:choice representation in C++ In-Reply-To: References: Message-ID: Hi Leonid, Gershanovich, Leonid writes: > I was wondering if you considered to use something like boost::variant > (http://www.boost.org/doc/libs/1_40_0/doc/html/variant.html) for mapping > xs:choice to c++. Please see this post for some background on the possible choices when mapping xs:choice (pun intended ;-)) to C++: http://www.codesynthesis.com/pipermail/xsd-users/2007-March/000863.html > It seems that representing following xsd construct: > > > > > > As > typedef string stringEl_type; > typedef int intEl_type; > > boost::variant < stringEl_type , intEl_type > m_choicer; > > Is little cleaner in terms of expressing intended object model than > > optional < string > stringEl; > optional < int > intEl; True, though this approach will only work for some cases. Consider the following: Now the intEl and boolEl elements becomes a single choice arm. They should be present or absent together. To handle this with variant you will need to wrap them into a class. In other words, you will need to start re-creating the compositor structure via C++ classes. Speaking of re-creating the compositor structure, we have used this approach in XSD/e for the C++/Hybrid mapping: http://www.codesynthesis.com/products/xsde/c++/hybrid/ For your original choice example you will get something like this: enum choice_arm_tag { stringEl_tag, intEl_tag }; choice_arm_tag choice_arm () const; void choice_arm (choice_arm_tag); // stringEl // const std::string& stringEl () const; std::string& stringEl (); void stringEl (const std::string&); // intEl // int intEl () const; int& intEl (); void intEl (int); See Section 4.4, "Compositors" in the C++/Hybrid Mapping Getting Started Guide for more information: http://www.codesynthesis.com/projects/xsde/documentation/cxx/hybrid/guide/#4.4 > class my_visitor : public boost::static_visitor > { > public: > int operator()(intEl_type i) const > { > return i; > } > > int operator()(const stringEl_type & str) const > { > return str.length(); > } > }; >From my superficial look at boost::variant I gather that there are two ways to extract the value: the visitor approach (which will be way too heavy-weight for most use-cases) and the boost::get function which doesn't really offer many advantages over what is possible now. It sure is more awkward, thought. BTW, if you are looking for a visitor way of traversing the object model, have you seen the recent discussion on this topic? It starts here: http://www.codesynthesis.com/pipermail/xsd-users/2009-July/002391.html Boris From boris at codesynthesis.com Mon Sep 28 12:49:55 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] --custom-type-regex bug In-Reply-To: <2df4c600909280841v31e31d08s383b55951cd960f@mail.gmail.com> References: <2df4c600909251401u1b917093n3df8a72da2cc380c@mail.gmail.com> <2df4c600909280841v31e31d08s383b55951cd960f@mail.gmail.com> Message-ID: Hi Zoltan, Zoltan Szatmary writes: > Now, I made a custom build of xsd.exe with the changes I suggested in > my previous mail. It works correctly. By the way, it even works > correctly if I use the \1 notation instead of $1. Ah, you were right and I was wrong. This is indeed a bug in XSD. I have committed the fix for the next release. Thanks for reporting this and suggesting the fix! Boris From sun.rise.ma at gmail.com Wed Sep 30 02:11:04 2009 From: sun.rise.ma at gmail.com (sun-rise) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Add element that read from file to C++/Tree Message-ID: <67b106680909292311j4be59fb6s7b7e3c8fd1ddf77@mail.gmail.com> Hi, I want to add a element that read from a file to C++/Tree object model. I tried a simple case. I was created a following schema and generated cxx/hxx code. person.xsd ------------------------------------------------------------ ------------------------------------------------------------ xsd cxx-tree --generate-wildcard --root-element-all --generate-serialization person.xsd And, I was created and serialize an object model as shown in the following code. ------------------------------------------------------------ #include #include #include #include #include #include "person.hxx" using namespace std; using namespace xercesc; DOMDocument* read_xml_file(std::string file_path) { try { XMLPlatformUtils::Initialize(); } catch (const XMLException& toCatch) { char * message = XMLString::transcode(toCatch.getMessage()); cout << "Error during initialization! :\n" << message << endl; XMLString::release(&message); return false; } XercesDOMParser* parser = new XercesDOMParser(); ErrorHandler* err_handler = (ErrorHandler*) new HandlerBase(); parser->setErrorHandler(err_handler); parser->setDoNamespaces(true); DOMDocument* doc; try { parser->parse(file_path.c_str()); doc = parser->getDocument(); } catch(const xercesc::XMLException& xml_exp) { char* message = XMLString::transcode(xml_exp.getMessage()); cout << "Exception message is: \n" << message << endl; XMLString::release(&message); return false; } catch(const xercesc::DOMException& dom_exp) { char* message = XMLString::transcode(dom_exp.getMessage()); cout << "Exception message is: \n" << message << endl; XMLString::release(&message); return false; } catch (...) { cout << "Unexpected Exception" << endl; return false; } return doc; } int main (int argc, char* argv[]) { person::person* pe = new person::person("foo", "bar", 20); DOMDocument* doc = read_xml_file("desc.xml"); person::person::desc_sequence& desc_seq(pe->desc()); person::person::desc_type* desc_type = new person::desc(*(doc->getDocumentElement())); desc_seq.push_back(*desc_type); xml_schema::namespace_infomap map; map[""].name = ""; map[""].schema = ""; person::person_(std::cout, *pe, map); delete pe; return 1; } ------------------------------------------------------------ desc.xml ------------------------------------------------------------ This is a sample description. ------------------------------------------------------------ I expect ------------------------------------------------------------ foo bar 20 This is a sample description. ------------------------------------------------------------ but result ------------------------------------------------------------ foo bar 20 ------------------------------------------------------------ How can I do that? Thanks. -- Yu From leonid.gershanovich at 247realmedia.com Tue Sep 29 00:23:32 2009 From: leonid.gershanovich at 247realmedia.com (Gershanovich, Leonid) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] xs:choice representation in C++ In-Reply-To: References: , Message-ID: Boris, > Please see this post for some background on the possible choices when > mapping xs:choice (pun intended ;-)) to C++: > http://www.codesynthesis.com/pipermail/xsd-users/2007-March/000863.html I read above thread and I would like to comment on following (from above thread): >> It boils down to whether to recreate the schema >> structure with an "unnatural" access API or to "flatten" the >> structure and generate an easy to use but sometimes dangerous >> API. We decided to go with the flat... I do believe that there are two separate scenarios: a. developer is given a schema b. developer designs schema as well as C++ code In first case, I can imagine that, depending on task at hand, developer might either want flatten representation of xsd data model in his c++ or might want to have schema structure recreated. Thus it might be convenient to have a command line parameter to control that. However, in second case, I cannot imagine why developer might want to have flatten representation in c++ code, after all, developer can always make his schema in such a way that c++ code is simpler. In other words - in my opinion, schema is yet another way to express data model/structure, and when I, as a developer, elect to create complicated schema, than I want my c++ data model to mimic that, otherwise I would have created a simpler schema. >> Note how we had to invent a lot of names that are not really found >> in the schema -- they are all candidates for name conflicts True. But, by using nested classes, instead of putting all definitions on a global scope, name conflicts should occur less frequent. But you are right, some names that do not exist in schema would need to be invented. But, as <"Compositors" in the C++/Hybrid Mapping > (http://www.codesynthesis.com/projects/xsde/documentation/cxx/hybrid/guide/#4.4) demonstrates - you have successfully resolved this already, I mean name invention and name conflicts. >> While this API preserve the structure of the content, the flat API is >> probably preferable in this case since all one needs is a list >> of to's, cc's and bcc's. This is not 100% true. By giving such lists you lose order of appearance in original xml, which might be significant. > For your original choice example you will get something like this: > > enum choice_arm_tag > { > stringEl_tag, > intEl_tag > }; > > choice_arm_tag > choice_arm () const; > > void > choice_arm (choice_arm_tag); > > // stringEl > // > const std::string& > stringEl () const; > > std::string& > stringEl (); > > void > stringEl (const std::string&); > > // intEl > // > int > intEl () const; > > int& > intEl (); > > void > intEl (int); > > See Section 4.4, "Compositors" in the C++/Hybrid Mapping Getting Started > Guide for more information: > > http://www.codesynthesis.com/projects/xsde/documentation/cxx/hybrid/guide/#4.4 Such code structure raises few questions: 1. while it is clear that calling "void intEl (int);" should change choice_arm and set int value, what should happen when "int& intEl ();" is called? 2. furthermore, what should happen when "int intEl () const;" is called while choice_arm() is set to stringEl_tag ? It seems that while such structure seems suitable for data retrieval, it seem to allow setting both choice arms in case when I am setting up object for later serialization. Which is not ideal. (boost::variant has cleaner interface in that sense). Also, can you please clarify for me if it is possible to get "Compositors" generated code (nested classes for xs:sequence, xs:choice and xs:all) while using "CodeSynthesis XSD" with "C++/Tree" mode? > From my superficial look at boost::variant I gather that there are > two ways to extract the value: the visitor approach (which will be > way too heavy-weight for most use-cases) and the boost::get function > which doesn't really offer many advantages over what is possible now. > It sure is more awkward, thought. I do agree that using boost::get is very close to what is possible now. But developer would have a choice: either use boost::get ("light" accessor) or "heavier" solution. Right now there are no choice. Also, I just would like to point out that boost::static_visitor is NOT a "visitor pattern" implementation from Gamma & Co book. It is a much simpler construct that relies on compile time function overloading, rather than run time polymorphism. In other words, while it is heavier than boost::get, it is not as heavy as full blown visitor pattern implementations. Thanks Leonid From boris at codesynthesis.com Wed Sep 30 10:24:38 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] xs:choice representation in C++ In-Reply-To: References: Message-ID: Hi Leonid, Gershanovich, Leonid writes: > However, in second case, I cannot imagine why developer might want to have > flatten representation in c++ code, after all, developer can always make > his schema in such a way that c++ code is simpler. In my experience, in situations where flattened API causes problems, generating C++ code from schemas is a secondary concern. The primary concern is usually to make the XML documents have a certain structure and/or to capture all the constraints. > >> While this API preserve the structure of the content, the flat API is > >> probably preferable in this case since all one needs is a list > >> of to's, cc's and bcc's. > > This is not 100% true. By giving such lists you lose order of > appearance in original xml, which might be significant. Well, in this specific case, order for "to", "cc" and "bcc" elements is obviously not important. Most cases that I have seen would fall into this category. > 1. while it is clear that calling "void intEl (int);" should change > choice_arm and set int value, what should happen when "int& intEl ();" > is called? That would be illegal (undefined behavior). We could have thrown an exception but that is an Embedded mapping so we kept it minimal. boost::get() probably also throws an exception if you try to access the wrong variant arm. > 2. furthermore, what should happen when "int intEl () const;" is called > while choice_arm() is set to stringEl_tag ? Ditto. > It seems that while such structure seems suitable for data retrieval, it > seem to allow setting both choice arms in case when I am setting up object > for later serialization. No, it doesn't. Only one choice arm can be effective at any given time. > boost::variant has cleaner interface in that sense How so? > Also, can you please clarify for me if it is possible to get "Compositors" > generated code (nested classes for xs:sequence, xs:choice and xs:all) while > using "CodeSynthesis XSD" with "C++/Tree" mode? No, C++/Tree only supports the flattened mode. The major problem with supporting the structured mode is that you need full-blown validation in the generated code to properly associate elements and attributes to class members during parsing. C++/Tree delegates validation to the underlying XML parser. Maybe we could use PSVI for that though I am not sure there will be enough information. Note also, that while XSD/e if primarily targeted at mobile/embedded systems, nothing prevents you from using it on general-purpose platforms. > I do agree that using boost::get is very close to what is possible now. > But developer would have a choice: either use boost::get ("light" > accessor) or "heavier" solution. Right now there are no choice. I don't believe such an option would be very popular since one has to write a class for each choice and a member function for each choice arm. It is also a partial solution that can only address some choice use- cases, as I showed in my previous email. Boris From leonid.gershanovich at 247realmedia.com Wed Sep 30 11:55:40 2009 From: leonid.gershanovich at 247realmedia.com (Gershanovich, Leonid) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] xs:choice representation in C++ In-Reply-To: References: Message-ID: > In my experience, in situations where flattened API causes problems, > generating C++ code from schemas is a secondary concern. The primary > concern is usually to make the XML documents have a certain structure > and/or to capture all the constraints. But once XML structure is defined and all constraints are properly described in schema would not it be natural to expect in generated code to have a similar structure? > Well, in this specific case, order for "to", "cc" and "bcc" elements is > obviously not important. Most cases that I have seen would fall into > this category. I do agree that in that specific case order is not important, and probably in most cases, as you pointed out, it is not important either, but I did see enough cases where order is significant. > That would be illegal (undefined behavior). We could have thrown an > exception but that is an Embedded mapping so we kept it minimal. > boost::get() probably also throws an exception if you try to access > the wrong variant arm. When I said that interface is not clear, what I meant is that by looking at accessor signature developer might expect: - exception for const reference accessor, when choice_arm points to another variant arm. - and either exception or actually changing variant arm when non const reference accessor is used, after all following two statement semantically almost equivalent: Obj.stringEl(newVal); Obj.stringEl() = newVal; I, as a developer, would not expect "undefined behavior" by looking at method signature. Not at first anyway:) Also, how choice arm is initialized in default ctor? And boost::get() does not need to throw exception, as it returns const pointer, thus it can return NULL when uninitialized arm is requested. > No, C++/Tree only supports the flattened mode. The major problem with > supporting the structured mode is that you need full-blown validation > in the generated code to properly associate elements and attributes > to class members during parsing. C++/Tree delegates validation to the > underlying XML parser. Maybe we could use PSVI for that though I am > not sure there will be enough information. > > Note also, that while XSD/e if primarily targeted at mobile/embedded > systems, nothing prevents you from using it on general-purpose > platforms. Does this mean that "full-blown validation" in XSD/e is equivalent to Xerces validation? As right now I rely on Xerces to do validation, including xs:unique, xs:key constraints. If answer to previous question is yes, then my next question would be - why keep Xerces support? > I don't believe such an option would be very popular since one has to > write a class for each choice and a member function for each choice arm. As long as it is just one of options, developer might choose not use it and go with more straight forward way, like series if else with boost::get(). But, if/when straight forward way is not good fit (consider when you actively develop schema and adding/removing elements to xs:choice) developer can always use heavier, stricter (as compiler would check that every possible choice has a handler) way with overloads. > It is also a partial solution that can only address some choice use- > cases, as I showed in my previous email. I do not exactly understand that do you mean? It seems to me that all use cases from you previous emails can be covered by boost::variant + overloaded accessors. Am I missing something? Leonid From bpringle at sympatico.ca Wed Sep 30 13:53:07 2009 From: bpringle at sympatico.ca (Bill Pringlemeir) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] xs:choice representation in C++ In-Reply-To: (Leonid Gershanovich's message of "Tue, 29 Sep 2009 04:23:32 +0000") References: Message-ID: <873a649v5o.fsf@sympatico.ca> On 28 Sep 2009, leonid.gershanovich@247realmedia.com wrote: > I do believe that there are two separate scenarios: > a. developer is given a schema > b. developer designs schema as well as C++ code [snip] > However, in second case, I cannot imagine why developer might want > to have flatten representation in c++ code, after all, developer can > always make his schema in such a way that c++ code is simpler. In > other words - in my opinion, schema is yet another way to express > data model/structure, and when I, as a developer, elect to create > complicated schema, than I want my c++ data model to mimic that, > otherwise I would have created a simpler schema. If you really like this boost::variant, then you can setup XSD to create custom classes for your schema. The only thing that XSD needs is implementations of, constructors, destructors, _clone, [and possibly a friend serialize()?] You can completely re-write the accessors and implementation as long as you have this API. Obviously this is not automatically generated. However, if you have multiple recurrences of this 'xs:choice', you could wrap it in a base class and/or template for re-use. Consider that many people might not be using boost. This *might* be a nice feature to have for some users. I think that the XSD development is best spent on features that are useful for all users. I have finished using XSD on a project like case b. The upfront analysis of the common data items to create an object repository that includes custom methods for the C++ domain made many things work more smoothly. Writing custom classes means you *dont* have to wait for another release of XSD. I am quite sure you can create a custom class that has the C++ API that you want. It all depends on whether you have a time budget to implement this. For some cases, doing this up front may actually save time. http://wiki.codesynthesis.com/Tree/Customization_guide#Customizing_the_XML_Schema_built-in_types I am sure that Boris can probably give some good guidance on how to achieve this? Fwiw, Bill Pringlemeir. From boris at codesynthesis.com Wed Sep 30 13:36:28 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:34:11 2009 Subject: [xsd-users] Add element that read from file to C++/Tree In-Reply-To: <67b106680909292311j4be59fb6s7b7e3c8fd1ddf77@mail.gmail.com> References: <67b106680909292311j4be59fb6s7b7e3c8fd1ddf77@mail.gmail.com> Message-ID: Hi, sun-rise writes: > > > > > This type has mixed content and the text that may appear between elements is not stored in the object model. There are two ways to handle mixed content in C++/Tree: You can use the DOM association feature to access the data via the DOM interface. Or you can use type customization to implement custom parsing, storage, and serialization of mixed content, depending on your application requirements. The DOM association approach, while simple, does not support serialization. For more information, see the 'mixed' example in the examples/cxx/tree/ directory. The type customization approach requires a bit more work but is much more flexible. Seeing that there were a few similar questions in the past, I created an example based on your use case. It will appear in the next release of XSD and you can also download it separately for 3.2.0: With Linux/UNIX makefile: http://www.codesynthesis.com/~boris/tmp/xsd-3.2.0-custom-mixed.tar.gz With MS VC++ projects/solutions: http://www.codesynthesis.com/~boris/tmp/xsd-3.2.0-custom-mixed.zip Simply unpack the contents of one of these archives into your XSD distribution directory. The example includes the README file and does something very similar to what you are trying to achieve. Let us know if you have any questions or run into any problems. Boris