[xsd-users] error processing multiple schemas at once

[Eric Broadbent]

Hi Boris, thanks to your previous advice I am now parsing the schemas that I need to, using the printf version of the "pimpl" code.
This is great, I'm impressed with the overall implementation.  Someday I'll figure out how to write C++ template code... for now I remain in awe of it's power in the hands of people smarter than I am.

I have a bunch of work to do now to wire up to this code to construct the in-memory data model, but this is a manageable task.

What I don't know how to do is separate the generated code from the built-in library interface, so that I can call the Expat parser myself.
The software system I'm working within (a large multipurpose data transformation system) already has Expat being used in another part of it, so I'm somewhat familiar with the Expat interface.  The reason that I couldn't just use it as before is that we now need to process a much more complex schema than the existing implementation could handle, so I decided to try XSD instead of our previous schema-handling solution.

The generated pskel and pimpl code works well, but the standalone executable is almost 15MB (I built with validation on) and of course it brings in std:: versions of utilities that already exist in the software environment that I want to plug the parser into.   One example is simply malloc - we have our own system-wide malloc, and other services, and we call XML_ParserCreate_MMR to be able to utilize it.

Here's the stack when the Expat XML parser is created - in the generated driver executable:

Breakpoint 10, 0x00007fff8939287f in XML_ParserCreateNS ()
(gdb) bt
#0  0x00007fff8939287f in XML_ParserCreateNS ()
#1  0x000000010003b652 in xsd::cxx::parser::expat::document<char>::parse (this=0x7fff5fbfc4d0, is=@0x7fff5fbed480, system_id=0x7fff5fbfec90, public_id=0x0, eh=@0x7fff5fbfc510) at elements.txx:281
#2  0x000000010003b986 in xsd::cxx::parser::expat::document<char>::parse (this=0x7fff5fbfc4d0, is=@0x7fff5fbed480, system_id=@0x7fff5fbfec90) at elements.txx:134
#3  0x000000010003ba32 in xsd::cxx::parser::expat::document<char>::parse (this=0x7fff5fbfc4d0, file=@0x7fff5fbfec90) at elements.txx:96
#4  0x0000000100007470 in main (argc=2, argv=0x7fff5fbfede8) at sub-driver.cxx:1884

What I'd like to do is be able to set up and if possible even invoke the Expat interface from my code - of course complying with all requirements XSD and Expat, instead of from within the xsd::cxx::parser::expat:: template-derived code.

Is this possible?  Am I misunderstanding how this all has to hang together?  Does the generated code require stuff in xsd:: or xsd::cxx:: or any of the other parts of the XSD library that I cannot substitute with entrypoints in my existing software?

The main(...) entrypoint in the generated driver code sets up all the parsers and then processes the document with code like this:
- - - - - - - - - - - - - - - - - - - - - - - - - - - 
    // Parse the XML document.
    //
    ::xml_schema::document doc_p (
      CT_Top_p,
      "http://repository.schemas/xdata",
      "top");

    CT_Top_p.pre ();
    doc_p.parse (argv[1]);
    CT_Top_p.post_CT_Top ();
  }
- - - - - - - - - - - - - - - - - - - - - - - - - - - 
Instead of this, I wonder if it is possible to call XML_Parse myself, after setting the element handler to the top-level object (CT_Top_p).
The question is whether I can then automagically cascade through the elements - something that is taken care of so nicely in XSD.
The current Expat code in our software application suite has a list of valid elements attached to each element and does a linear search through them to find each subsequent element provided by Expat - but that is likely not a method one would want to try to use in conjunction with the XSD-generated code.

Interested to hear your thoughts, and I very much appreciate your help.

-Eric B.


On Nov 2, 2011, at 3:27 PM, Boris Kolpackov wrote:

> Hi Eric,
> 
> Eric Broadbent <Eric.Broadbent at csr.com> writes:
> 
>> So I tried running XSD with multiple schemas: (same command as I used 
>> originally but just added the other schemas on the end)
>> 
>> 	xsd cxx-parser --show-sloc --force-overwrite --show-anonymous 
>> --root-element subset_root --generate-test-driver --generate-print-impl 
>> --generate-validation --xml-parser expat subset_schema.xsd shared-types.xsd 
>> shared-resources xsd 
>> 
>> This time, it didn't appear to accept the "--root-element" option"
>> 
>> 	xsd: error: unable to generate the test driver without a global
>> element (document root)
> 
> When you specify --generate-test-driver, XSD will try to generate a
> driver for each schema you passed. If there is no global element in
> any of them, then you will get the above error. The solution to this
> is to compile the "included/imported" schemas without this option and
> then compile the "root" schema (the one that defines the global element)
> separately with this option:
> 
> xsd cxx-parser --show-sloc --force-overwrite --show-anonymous 
> --generate-print-impl  --generate-validation --xml-parser expat 
> shared-types.xsd shared-resources.xsd 
> 
> xsd cxx-parser --show-sloc --force-overwrite --show-anonymous 
> --root-element subset_root --generate-test-driver --generate-print-impl 
> --generate-validation --xml-parser expat subset_schema.xsd
> 
> Boris
> 
> 
> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== .



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog