[xsd-users] Questions on few features.
boris at codesynthesis.com
Tue Jul 17 10:05:11 EDT 2007
Balasubramanyam, Shivakumar <sbalasub at qualcomm.com> writes:
> 1. -extern-xmlschema.
> I have xs:import namespace="http://www.w3.org/XML/1998/namespace"
> schemaLocation="./xml.xsd"/> which generates a #include "xml.hxx" but
> also generates the
> Namespace xml_schema and all the fundamental XML types.
> To avoid this I added -extern-xmlschema="xml.xsd' which also generates
> #include "xml.hxx".
> This is not a problem but I just want to make sure if am using the right
I am not sure what you are trying to achieve. xml.xsd is not a replacement
for the XML Schema build-in types that are generated in the xml_schema
namespace. The --extern-xml-schema option allows you to factor the
xml_schema namespace into a separate file and include it in other
generated files instead of generating the xml_schema namespace in
every file. To achieve this you will first do:
$ xsd cxx-tree --generate-xml-schema xml-schema.xsd
This will generate xml-schema.hxx which contains the xml_schema namespace.
The xml-schema.xsd name is a fake file name which does not have to exist.
It is only used to derive the name of the header file (xml-schema.hxx).
Then you would compile your schemas like so:
$ xsd cxx-tree --extern-xml-schema xml-schema.xsd my-schema1.xsd
$ xsd cxx-tree --extern-xml-schema xml-schema.xsd my-schema2.xsd
$ xsd cxx-tree --extern-xml-schema xml-schema.xsd xml.xsd
This will result in xml-schema.hxx being included in generated
my-schema1.hxx, my-schema2.hxx, and xml.hxx. Again, the
xml-schema.xsd name that is passed to the --extern-xml-schema
option is a fake file name that is used to derive the header
name to include.
> 2. What is the need for -root-element options?
It allows you to specify the real root element(s) for your vocabulary.
Many schemas define a large number of global elements that are not
valid document roots. By default XSD generates a set of parsing and
serialization functions for each global element. By specifying the
root element(s) you make XSD generate those functions only for that
> What are the cost of having of -root-element-all versus just one
> that you *really* want?
You will get a potentially large (if you have many global elements)
chunk of code that is not necessary, slows down compilation, and
bloats your object code.
> 3. I have not seen the implementation of the serialization. Does
> the ostream serialization depend on XERCES?
Serialization to XML depends on Xerces-C++.
> I mean can we disable XERCES dependency but still generate XML
> documents for logging purposes.
No, this is not possible with the C++/Tree mapping.
> 4. This is more to solve above point in a more generic way. Has
> there been any thoughts on decoupling the C++ objects that represent the
> XSD datatypes separate from feature supports like serialization or XML
> parsing etc.
There is a way not to generate pretty much every aspect of the code that
may not be needed. For example you can use the --suppress-parsing option
to get rid of the XML parsing code. In fact if you pass --suppress-parsing
and don't pass --generate-serialization, you will end up with just the
object model that can neither read nor write XML.
However, I am not sure how useful this feature is to you. If I understood
you correctly, you still want to create XML documents but without using
Xerces-C++. It seems to me that what you really want is a way to plug a
different XML serializer instead of Xerces-C++ (BTW, which one would
you prefer?). This is not possible with the C++/Tree mapping but we
are working on another mapping similar to C++/Tree that will allow
changing the underlying XML parser/serializer.
More information about the xsd-users