Henry S. Thompson
17 September 2000

1.   Problem and proposed resolution

In XML 1.0, the attribute NOTATION type is an enumerated type with a special semantics, namely that each name corresponds to the name of a declared NOTATION:

<!DOCTYPE root [
<!NOTATION foo PUBLIC "a.b">
<!NOTATION bar PUBLIC "c.b">
<!ATTLIST root nn NOTATION (foo|bar) #IMPLIED>
<root nn="bar">alskj</root>

We don't come close to reconstructing this at the moment.

The minimal fix in my view is to change NOTATION to be an abstract* derived primitive type, whose base is QName, and to require one or more enumeration facets in any declaration of a simple type derived from it, with a modified side-condition that each enumerated value must refer to a declared notation.

This puts minimal stress on our system, but extends XML 1.0 in that NOTATIONs are now QNames, not NCNames. This is necessary to avoid introducing what otherwise does not currently exist, namely a top-level named schema component not in any namespace.

Finally, to make this any use, we need to add PSVI properties [notation public] and [notation system] to record what is meant, e.g. on the EII for <root> above, we'd have [notation public]=='c.b'

* abstract: This re-inforces my feeling that

We could of course switch to calling most things 'concrete', and make complex types now described as abstract='true' be concrete='false'.

Then all the new abstarct types would be non-concrete by definition, but not all non-concrete types would be abstract.

2.   Another problem

Researching this reminded me of something else which is broken, namely the ENTITY and ENTITIES simple types: as it stands there is no way to legally use them!

I'd recommend a similar solution: derive ENTITY from QName, and add a named Entity component and a top-level <entity name="" system="" public="" notation=""/> to structures.