[xsd-users] import, include, namespaces, restriction and schema versioning

[Boris Kolpackov]

Hi Bill,

Bill Pringlemeir <bpringle at sympatico.ca> 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 (<xs:any
> minOccurs="0"/>).  Perhaps for the output, <xs:element fixed="USD">
> 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