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

[Bill Pringlemeir]

On 27 Aug 2009, boris at codesynthesis.com wrote:
> Bill Pringlemeir <bpringle at sympatico.ca> writes:

>> 1. You are a North American wishing to write an open source TV capture
>> application.

> I am not sure I follow. Are you saying you don't want to generate 
> the serialization code (already possible)? Or that you would like the
> serialization to a (relational) database instead of XML? Can you
> elaborate a bit?

I was thinking I would move the data to a DB by myself.  Meaning that
the serialization code for many classes is not that useful.  But
perhaps that is distracting from my main point.

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.  There are other objects with-in a
request/response that you would like to be generic.  For this
application that is not that extreme.  However other SOAP services
might have many entry points having full-blown objects for these
ephemeral messages is not useful.  It is useful for the re-useable
data that might be inside of those messages.

We tried to avoid different message types (classes) by using optionals
and enumeration to denote the request type to reduce the code size of
the messaging parts of schemas.  Using attributes as opposed to
elements is also *very* helpful with XSD if you have the latitude to
code your own schema.  However, when you use an off the shelf SOAP
schema, this is not possible.

I guess that some of the constructors are needed for the parser to
construct the object.  However, the application will never construct a
response.  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.

>> 2. You are part of a financial institution that is using the FpML
>> schemas as a standard.  Your application only deals with Mortgages.

> Hm, looks like you and Alan Amano are after the same feature. I just
> replied to his email with some ideas:

I think parts of the versioning discussion are still relevant.  For
example, the 'default' on write does not have to be so complex as a
function/method.  You may always work in USD in the above example.
When specifying a currency type in any message, it might be convenient
to fill it in with USD.

If you were to custom code this (from a DOM), you might throw in
defaults for the currency type, etc and not have this in the object
model.  There seem to be many situations where industry/committee
schemas are used, but only a subset of the information is needed for a
particular application.

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.  Perhaps the versioning issue is the
inverse?

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.  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.  In many ways XSD has some transformation capabilities
with the 'reg-ex' type options, but they are currently limited to the
generated code as opposed to the schemas (with the exceptions of name
spaces).

Having used XSLT with docbook, I wouldn't wish it on anyone!

Fwiw,
Bill Pringlemeir.

-- 
Anyone who trades liberty for security deserves neither liberty nor
	security - Benjamin Franklin