XML Schema Part 0: Primer
W3C Working Draft
XML Schema Part 1: Structures
W3C Working Draft
XML Schema Part 2: Datatypes
W3C Working Draft
The list is roughly in order of priority with regard to MPEG-7's requirements.
If these cannot be provided then the alternative is to use lists. In the current WD, you can only create lists from atomic data types and since a list is not an atomic data type then you cannot create matrices using 'lists of lists' e.g.:
<simpleType name="ArrayOfInteger" base="integer" derivedBy="list"/> <length value="2"/> </simpleType> <simpleType name="MatrixOfInteger" base="ArrayOfInteger" derivedBy="list"/> <length value="4"/> </simpleType>Alternatively we can simply convert matrices to flattened lists which can be 1D, 2D or 3D and use a dim facet to lists to specify multi-dimensionality:
<simpleType name="MatrixOfInteger" base="ArrayOfInteger"/> <dim value="2 4"/> </simpleType>
<simpleType name="listOfInteger" base="integer" derivedBy="list"> <complexType name="VectorI" base="listOfInteger" derivedBy="extension"> <length valuePar="Size"/> <attribute name="Size" type="nonNegativeInteger" use="required" /> </complexType>
<element name="SummaryDS"> <complexType>.....</complexType> </element> <attribute name="SummaryDSRef" type="IDREF" refType="SummaryDS"/>
The current XML Schema WD requires a complex type derived by restriction to repeat all the declarations it inherited from its base. This becomes tedious and hard to manage as the inheritance hierarchy grows deeper. It would be preferable if only the declarations that are further constrained in the derived type needed to be specified. Its possible that in a deeply nested structure, such repetition might be the only practical way to specify restrictions to the structure without causing ambiguity.
5.2 Combined Restriction and Extension in One Step
The current XML Schema WD allows a new complex type to be derived from an existing one either by restriction or extension but not both at the same time. Nevertheless, it is quite common for a new type to both restrict and extend a base type. The constraint imposed by the current XML Schema WD means that such type derivation has to go through two steps: a restriction followed by an extension or vice versa. This will create a large number of dummy types. For example:
<complexType name="A"> <element name="B" type="string" minOccurs="0" maxOccurs="unbounded"/> <element name="C" type="string"/> </complexType>We then define "D" which restricts B to a single occurrence and adds a new element E. We would like to do this in one step (not two):
<complexType name="D" base="A" derivedBy="both"> <element name="B" type="string" minOccurs="1"/> <element name="E" type="integer"/> < </complexType>5.3 Unambiguous derivation of nested elements
If we allow derivation by both restriction and extension in a single step then there needs to be a mechanism for specifying the exact path of element derivations. This is required to avoid ambiguity when there are anonymous embedded type definitions. For example:
<complexType name="A"> <element name="B"> <complexType> <element name="C" type="string" minOccurs="0" maxOccurs="unbounded"/> </complexType> </element> <element name="D" type="integer" /> </complexType> <complexType name="E" base="A" derivedBy="both"> <element name="C" type="string" minOccurs="1" /> <element name="F" type="integer" /> </complexType>Is "C" an extension (that is, a new element) or a restriction of "B.C"? If the latter, then it would be better to use a path specification such as B.C. :
<complexType name="E" base="A" derivedBy="both"> <element name="B.C" type="string" minOccurs="1"/> <element name="F" type="integer"/> </complexType>5.4 Derivation by Restriction/Extension using Derived Complex Type
We would like to be able to do the following kinds of derivation by restriction/extension based on an existing restricted/extended complex type:
<complexType name="A"> <element name="B" type="BType"/> </complexType> <complexType name="restrictedB" base="BType" derivedBy="restriction"> <!-- derivation by restriction --> </complexType> <complexType name="restrictedA" base="A" derivedBy="restriction"> <element name="B" type="restrictedB"/> </complexType>
<complexType name="extendedB" base="BType" derivedBy="extension"> <!-- derivation by extension --> </complexType> <complexType name="extendedA" base="A" derivedBy="extension"> <element name="B" type="extendedB"/> </complexType>
<element name="myElement" type="integer" minOccurs="0" maxOccurs="1" default="37" /> <attribute name="myAttribute" type="integer" use="default" value="37"/>
We would also like to be able to specify which particular components (elements, types, attributes, groups etc.) of a schema are exportable.
<complexType name="A" base="integer" derivedBy="extension">
<attribute name="attributeOfA" type="string"/>
</complexType>
then it is not possible to derive from "A" a (textOnly) complex type "B" that further restricts the content type to say "nonNegativeInteger":
<complexType name="B" base="A" derivedBy="restriction">
<!-- there is no way to specify that the content type should
be further restricted to the type "nonNegativeInteger"
-->
</complexType>
This is the case despite the fact that item 1.5 of "Constraint on
Schemas: Derivation Valid (Restriction, Complex)" of Section 5.11 of
the "XML Schema Part 1: Structures" working draft states that:
1.5 the {content type} of the complex type definition is a
simple type definition and either
1.5.1 the {content type} of the {base type definition} is a
simple type definition of which the {content type} is
a valid restriction as defined in Derivation Valid
(Restriction, Simple) (§5.12) or ...
which seems to suggest that further restriction of the simple type of
a textOnly complex type should be allowed.