MPEG-7 Description Definition Language (DDL)
XML Schema Problem Issues 
Response to Last Call for Review 12 May 2000

This list has been compiled through an evaluation of the XML Schema Language's ability to satisfy MPEG-7. It is based on the following W3C April 7, 2000 WDs:

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. 

1. Datatypes Issue

MPEG-7 requires both arrays and matrices. We would prefer to have built-in array (1D) and matrix (2D, 3D) datatypes, instead of simply the 'derivedBy = list' mechanism.

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 name="MatrixOfInteger" base="ArrayOfInteger" derivedBy="list"/>
   <length value="4"/>
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"/>

2. Extensibility Issue

MPEG-7 requires clarification of:

3. Parameterization of Array and Matrix Sizes

We would like to define the size of lists (arrays and matrices) at the time of instantiation. In the example below we suggest a valuePar construct which gives the name of the attribute whose value will be used for the facet. The attribute data type must match the facet data type. This example is currently problematic because facets only apply to simple types and attributes can only be added to complex types. The other issue  is whether VectorI  is being restricted or extended?
<simpleType name="listOfInteger" base="integer" derivedBy="list">

<complexType name="VectorI" base="listOfInteger" derivedBy="extension">
    <length valuePar="Size"/>
    <attribute name="Size" type="nonNegativeInteger" use="required" />

4. Typed References

MPEG-7 requires 'typed references' or the ability to constrain IDs and IDREFs to particular (named top-level or exemplar) elements:
<element name="SummaryDS">

<attribute name="SummaryDSRef" type="IDREF" refType="SummaryDS"/>

5. Derivation Issues

5.1 Simplified Derivation By Restriction

 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"/>
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"/> <
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">
            <element name="C" type="string" minOccurs="0"
    <element name="D" type="integer" />

<complexType name="E" base="A" derivedBy="both">
    <element name="C" type="string" minOccurs="1" />
    <element name="F" type="integer" />
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"/>
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 name="restrictedB" base="BType" derivedBy="restriction">
<!-- derivation by restriction -->

<complexType name="restrictedA" base="A" derivedBy="restriction">
    <element name="B" type="restrictedB"/>
<complexType name="extendedB" base="BType" derivedBy="extension">
<!-- derivation by extension -->

<complexType name="extendedA" base="A" derivedBy="extension">
    <element name="B" type="extendedB"/>

6. Inconsistencies in Occurrence Constraints

In the current working draft there are inconsistencies between the specification of occurrence constraints for elements and attributes e.g. default="37" vs. use="default" value="37". It would be much better if the same attributes are used.
<element name="myElement" type="integer" minOccurs="0" maxOccurs="1" default="37" />

<attribute name="myAttribute" type="integer" use="default" value="37"/>

7. Element-specific Importation and Exportation

It would be useful to be able to specify the importation of specific individual elements, types, attributes or groups rather than only complete schemas.

We would also like to be able to specify which particular components (elements, types, attributes, groups etc.) of a schema are exportable.

8. Enabling Derivation by Restriction on Text-only Complex Types

The current XML Schema grammar does not allow the content type of a textOnly complex type to be further restricted. For instance, if
    <complexType name="A" base="integer" derivedBy="extension">
	<attribute name="attributeOfA" type="string"/>

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" 

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.

List compiled by Jane Hunter,
(Based on MPEG-7 schema encodings and feedback from other MPEG-7 groups)
Send queries to MPEG-7 DDL AHG
Date: 2000/05/11