urgent ndr rules question/clarification

[Anne.Hendry@Sun.COM]

Regarding rules

[VER 8] a ubl minor version doc schema must import its immediately preceding version document schema.
[VER 9] ... new ... existing ... limited to the use the use of xsd:derivation and xsd:restriction ...

The implication of these rules may be quite drastic in terms of being able to
generate schemas programmatically and are not sure if we can do this with the
spreadsheets we have as we'd need to either include the old ss into the new ss
by adding new columns or import both ss into ef.

For 1.0, since the ss and schemas were not aligned, then there would need to
be a regeneration of 1.0 model within ef from the 1.0 schemas, and any
incompatability there woudl cause a problem.  Or, could generate a schema that
imports the old one and then generate a ss and try to do a diff.

Do we really want these rules?  It's one possible approach to schema versioning,
and if doing schemas by hand may work, but doesn't fit an automatic generation
process such as the one we are persuing.  You also would need a whole host of
additional ndr rules.  For example, how does this rule take into account both
tc and oasis versions?  Need further ndr rules to allow these rules to be kept.

In addition, in [VER 9] what does 'exisiting' or 'new' mean here except that
it is by comparision with the version mentioned in [VER 8]?  The words 'alter'
and 'new' require you to have two versions available of both model and scheams.
Reading behind this, it seems this is an implementation of customization,
and is a nice idea, and has value, but the amount of work from both ssc and
ndr to implement these rules cannot be done in the timeframe we have.

A better way to achieve similar results maybe be to build a test db
of valid examples to test back compatibility.  If the desire is to demonstrate
customization methodology with these rules then we have a larger problem for 1.1.


- SSC