RE: [ubl-cmsc] XSD Derivation

[Matthew Gertner <matthew.gertner@schemantix.com>]

Let me throw in my 2 cents in response to the excellent points raised by
Bill, Eduardo and Eve:

*** How is schema polymorphism handled? ***

I don't claim to have all the answers on this, but here are two examples
that might get people thinking:

1) Commerce XDK and the like. These systems take XML Schema and map it
directly into Java or C++ classes. The classes know how to consume and
produce the appropriate XML in order to populate and serialize themselves.
They also offer methods to get at the underlying data programmatically
(getters and setters). Schema derivation maps into OO derivation, so the
MyPrice class is derived from Price (to continue with this example) and all
the principles of dynamic binding outlined by Bill hold when programming to
the class. In other words, a program designed to work with Prices just
ignores the extra stuff in MyPrice *but* the object always remains a MyPrice
when stored and forwarded.

2) Schema adjuncts (annotations). This is one we use extensively. Metadata
for application semantics is attached using XPath to element types. This
metadata can be used for determining how a document is presented, how the
value for a given element is calculated, how data is read out of a
persistent store, etc. If an element type is extended, all of the metadata
from the base type is retained unless explicitly overridden. So if my
processing application uses the schema adjuncts, it can usefully process a
derived type using the metadata attached to the base type. This sort of
covers the need for virtual methods that isn't covered by 1).

I totally agree that the use cases will be very helpful in determining
whether there are cases not handled by these methods (believe it or not, I'm
guessing that they cover everything).

*** Tool support for XSD ***

Your point (Eduardo's and Eve's) is well-taken. I can't resist pointing out
that whereas SGML was filled with all kinds of gunk appealing to various
freaks (e.g. rumor has it that Arofan is partial to SHORTTAG :-), derivation
is a core feature of XSD. Saying that we don't expect tool vendors to
support this is a bit like not using general entities in DocBook. These are
very early days, but if vendors don't provide support for extension then XSD
is going to fail miserably, right?

*** Extensions not supported by XSD ***

Like Eduardo, I like to play devil's advocate, and I remember arguing back
in the very early days of XML schema that it would be useful and quite easy
to design a derivation mechanism that would enable extension in places other
than the end of the content model. (I even thought that early versions of
SOX supported this, but when I went to www.sox.org to find out I found a
site flogging pantyhose... :-)

Anyway, this suggestion got shot down, and I've never seen a single viable
use case where this would be necessary.

*** Polymorphic behavior ***

Eduardo's comment about the extended MyPrice with tax information stumped me
initially. I can't say whether this kind of thing occurs in the real world
(UCWBH). It could be solved by defining a field in the element type to hold
the final, calculated price, and using schema annotations to provide the
correct formula, as I outlined above. Let me know if you want me to provide
a more extensive example of this. Or we could just say that extensions that
break processors written for the base type are in error.

In any case, how would your putative ad hoc extension mechanism solve this?

Matt