CR-14 value space of entities, notations, IDREFs

Dear James -

As you are aware, the W3C XML Schema Working Group has spent the
last several weeks working through the comments received from the
public on the Candidate Recommendation (CR) of the XML Schema specification.
We thank you for the numerous comments you made on our specification during
our CR comment period, and want to make sure you know that all
comments received during the CR comment period have been recorded
in our CR issues list (http://www.w3.org/2000/12/xmlschema-crcomments.html).

Among several others, you raised the point registered as issue
CR-14 Value space of entities, notations, IDREFs (and QNames).

Arguing by analogy with the treatment of QName, which 'resolves'
the prefix which appears in the lexical form by mapping it to the
associated namespace name, you suggest that the types ENTITY,
NOTATION, and IDREF should similarly 'resolve' their lexical
value and have, as their value, not the name of the object but
the associated component on the abstract level.

Since components are in fact abstract descriptions of certain
quantities of information, and there is no requirement that
there be an 'object' in the interface to point at, a stream-oriented
interface (e.g. one similar to that of sgmls) might well do precisely
the same thing no matter what we say:  providing a unique name by
which something may be looked up is the same, in terms of
abstract information content, as providing an in-memory pointer
to a data structure which also contains the name.

Upon consideration, therefore, the WG concluded that for
practical purposes the two ways of describing these types
delimit the same set of conforming processors.  In general, many
members of the WG (possibly the majority) preferred the formulation
you proposed:  saying that the value of an IDREF is the associated
element information item seems to convey the point of the exercise
much more effectively than saying that it's a name.  Since
the two formulations seem to define the same set of conforming
implementations, the additional clarity seems wholly advantageous.

As the WG was upon the point of instructing the editors to make
the appropriate change, however, it was observed that we are
required by charter to define our simple types in such a way that
they can be used in applications other than XML Schema.  And in
other applications are not guaranteed to have any notion of XML
Schema components or element information items -- for such
applications, changing the definition of the value space would
appear to make the type either incomprehensible or unusable.

And so, with some regret (at least on my part), the WG concluded
that we could not adopt your proposal after all.

It would be helpful to us to know whether you are satisfied with the
decision taken by the WG on this issue, or wish your dissent from the
WG's decision to be recorded for consideration by the Director of
the W3C.

Regards

Michael Sperberg-McQueen
XML Schema Working Group

Received on Wednesday, 7 March 2001 13:21:21 UTC