Hey All
During todays PSI meeting, the issue of toolkit support for the union
construct in schema definitions came up. In general, one of our goals for
the PSI spec is to provide a specification that has a high probability of
interoperatibility between different vendors.
There are three options available to address the union construct:
1) Leave it as it is, and deal with the toolkits lack of support on a case
by case basis. This has the advantage of keeping the specification "pure",
but has the dis-advantage of near term interop problems.
2) For the interim, modify the Common Semantic Model to not utilize the
union construct. As the toolkits add support, eventually roll the union
construct back into the semantic model. This gets us better interop in the
near term, but may add turmoil when we re-introduce the union construce.
3) In PSI, duplicate the object defnintions that contain the element
refences to the types that are defined by union, and define them directly as
an NMTOKEN. In otherwords, create a PSI_DocumentDescription.xsd that has:
<xsd:element name="DocumentFormat" type="xsd:NMTOKEN">
instead of:
<xsd:element ref="DocumentFormat" minOccurs="0" />
This has the advantage of keeping the semantic model "pure", but has the
dis-advantage of duplicated container object definitions..
Thoughts / Opinions?
Dave