Clarification/Elaboration of XML Schema requirements
Henry S. Thompson

14 November 1998

1. A4: Define relationship of schemata to XML document instances

The group requested clarification

2. Anew: Identifier renaming

SGML/(XML) architectural forms provide a number of facilities, including various forms of content model subsetting and element and attribute renaming. All these are really application-side requirements, and are perhaps not quite the same as A12, which are in my view author-side.

3. B5: [Enable applications to use schemata to filter input documents]
4. B6: [Switch between expression as attribute and expression as sub-element]

In writing several DTDs for schema languages, I have observed that the ElementType element type and the AttributeType element type were very similar. Perhaps schemata would be easier to write and maintain if this similarity was exploited. There are three ways one could imagine doing this:

  1. Point this out, and exploit it by defining parameter entities in the Schema DTD for the common parts;
  2. Actually abandon the two different element types in favour of, say, ComponentType, and in the content model make clear which sub-components were to be expressed in instances as attributes and which as sub-elements;
  3. As (2), but actually change the data model so that instead of Element and Attribute nodes, in what a schema processor presents to applications we actually have Component nodes, with sub-components which are only incidently differentiated between attribute-expressed and sub-element-expressed. This has at least three sub-cases:
    1. You still have to make explicit in a schema for each sub-compenent whether it is to be expressed as attribute or sub-element;
    2. You can leave this specification out if the datatype precludes attribute expression;
    3. Unless the datatype precludes this, you can specify that instances can choose on a case-by-case basis which expression to use (RDF allows this).
5. B7: Validation of documents across links

Stipulate that XML Link provides a way of expressing one or more varieties of transclusion (find my content over there; replace me with what's over there; . . .).

6. C2 (and D2?): Element Subclassing and Inheritance

The group requested subdivision, against a background of the observation that the balance between requirements language and implementation language was skewed too far towards the implementation style.

Accordingly, there follow hereafter a number of new candidate requirements.

6.1. Goal C2a:
6.2. Goal C2b:
6.3. Goal C2c:

I thought there was something else here, but I can't reconstruct it. Arguably something which attempts to reconstruct what SOX is doing with parameterised declarations belongs here.

7. D3: Support incomplete constraints on element content models
8. D6: Support for alternate encodings of numeric values