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

[Bill Pringlemeir]

On 18 Aug 2009, eric at boostpro.com wrote:

> First, the problem: My tool allows users to create instance documents
> that match a particular schema, say schema1.xsd. Now, I release a new
> version of the tool and a new schema, say schema2.xsd, that adds
> elements to certain schema types. To keep the old instance documents
> readable, I make these new elements optional. This results in a schema
> that is looser than I would like; if I can read instance documents
> with the missing elements, I can also write them, and I don't want
> that. I want to express an asymmetry: it's ok for an element to be
> missing on read, but not on write.

I was considering a similar problem/issue.  You are delivered an
'Enterprise' or 'Industry' schema but your application only needs a
subset of the data to operate on.  A straight transformation produces
a lot of code that will not be needed.

I was thinking of something like XSLT (metaphorically, not exactly)
that would transform a schema from one version to another.  The PCCTS
has a program called sorcerer which has a language for transforming
trees.  I think that a similar type of activity could automate this
transformation.

Ie, given an input schema different types would be qualified as not
applicable, read-only, write-only and read-write; XSLT referenced
above is an analog to this transformation syntax.  Elements could be
specified to have defaults (not present in the original) that would
need to ful-fill the input schema's document model.  The code could
then output a schema that would comply with the input schema, but have
a reduced document model.  When this was feed to a data binding tool
like XSD, the generated source would be much smaller.

... but that is all fantasy.  I vaguely remember someone posting
something that sounded like this on the xsd-user list.  It sounds like
you are trying to do something like this by hand.

Fwiw,
Bill Pringlemeir.