a:attributeType

[James Clark <jjc@jclark.com>]

I've been thinking about Mike's suggestion that we should
xsd:ID/IDREF/IDREFS instead of a:attributeType.  The more I think about this
the more it makes sense from the point of view of the user.  The problem is
how to specify it.

At the moment the RELAX NG spec describes the property of being a correct
RELAX NG schema (which holds of XML documents) and a relationship of being
valid (which holds between a document that is a correct RELAX NG schema and
another document).

To use xsd:ID/IDREF/IDREFS instead of a:attributeType, I think we would need
to introduce another property that may hold of a RELAX NG schema, let's call
it being "ID-compatible".  This property is defined only for correct RELAX
NG schemas.  A RELAX NG schema is ID-compatible if it uses
xsd:ID/IDREF/IDREFS in a way that is compatible with XML 1.0.  More
precisely, define an ID-pattern to be a <data> element with
datatypeLibrary"http://www.w3.org/2001/XMLSchema-datatypes" and local name
"ID", "IDREF" or "IDREFS". Then a RELAX NG schema is ID-compatible if and
only if, after schema simplification, for every ID-pattern:

- the parent is an <attribute> element
- the first child of the <attribute> parent must be a <name> element
- the first child of the <element> ancestor must be a <name> element
- any <attribute> element that competes with its parent <attribute> element
has a <data> child with the same namespace URI and same local name
(competition is as defined in current draft)

An ID-compatible RELAX NG schema implies a mapping from element/attribute
name pairs onto an "ID-type", where an ID-type is ID, IDREF, IDREFS or null,
and hence a mapping from attributes in the instance onto ID-types.

We would also introduce an additional relationship that holds between an
ID-compatible RELAX NG schema an an XML document. Let's call this being
"ID-sound".  An instance is ID-sound wrt to an ID-compatible RELAX NG schema
if and only if

- when the value of each attribute in the instance whose ID-type is not null
is split into a sequence of whitespace-separated tokens, the length of the
sequence is 1 if the ID-type is ID or IDREF and >= 1 if the ID-type is
IDREFS

- no two distinct tokens in attributes of ID-type ID have the same value

- for each token in an attribute of ID-type IDREF or IDREFS, there is a
token in an attribute of ID-type ID with the same value

The conformance requirement on a "compatibility" processor (or whatever we
want to call the thing that implements this) is that

a) for any correct RELAX NG schema, the processor must be able to determine
whether or not it is ID-compatible

b) for any ID-compatible RELAX NG schema and for any instance, the processor
must be able to determine whether it is ID-sound

ID-soundness is independent of validity.  A RELAX NG processor must be able
to determine whether a document is valid with respect to any correct RELAX
NG schema, even if the schema is not ID-compatible or if the document is not
ID-sound wrt the schema.  A compatibility processor must be able to
determine whether a document is ID-sound even if the document is not valid
wrt the schema.

One problem is that this isn't anything to do with annotations, so either we
would have to call our spec something other than "DTD Compatibility
Annotations" (maybe simply "DTD Compatibility") or we would have to move
this feature into a separate spec.

James