[xsd-users] Questions on few features.

[Boris Kolpackov]

Hi Shivakumar,

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
> options.

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
element.

> 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.


hth,
-boris