xml:id [was: Prototype XHTML 2.0 DTD with partial XLink support (was Re: What are the advantages of using XLink?)]

[This message from Chris Lilley to the XML CG (and others) was
forwarded to the Blueberry comment list by Paul Grosso.]

Steven Pemberton wrote:
> 
> > Another headache is fragment identifiers.  Mozilla / Netscape 6 treat
> > IDs in XML documents as fragment identifiers, on the other hand,
> > since they don't fetch external DTDs, they don't know which attribute
> > is of type ID :-<  So, in general, fragment identifiers are defunct
> > in XML documents.

Well, they are not exactly defunct, but they do work differently in
different implementations. Its not that they don't work at all; rather
that they work enough to raise false hope ;-)

> Aargh! This is something that the XML community is going to have deal with
> fast: this is a major architectural disaster!

I agree, but apparently the fix is that although legacy browsers would
not agree to fetch small DTDs they will however agree to fetch large XML
Schemas. I see a flaw in this reasoning, particularly since the
attendees at the XML Processing workshop exhibited a deep reluctance to
prescribe any paticular order or requirement for the increasing layers
of XML processing that come under (or seem to me to come under) the
broad heading of parsing (which includes Schema processing, XInclude,
and so forth).

Having decided to make fetching the internal DTD subset optional, in my
view the original XML WG should have defined an  xml:id which would join
xml:lang and xml:space (and now xml:base) in being pre-defined without
any schema for the XML namespace needing to be fetched.

Documents which needed reliable processing of attributes of type ID
would then have the option of using the reserved, predefined atribute
xml:id and this would avoid, or at least reduce, the circumlocutions
employed by for example the XML DOm which seems to say that
implementations can use knowledge of the namespace, the phase of the
moon, etc to divine whether a particular attribute is of type ID or not.
CSS has similar wording, which Steven has already objected to. 

The root of the problem, though, was that the XML WG did not see that
there was a third class of XML processing besides well-formed-only and
full-DTD-validation - and that this, which has been called full-infoset
processing, is the most common sort of processing desired in practice.
Whereby the external DTD subset is fetched, and the DTD is not
necessarily complete for validation, but instead is merely used to
declare attribute types and to provide defaulted attribute values,
without having to lumber each XML instance with this stuff in the
internal DTD subset.

It is particularly annoying to have to have 50 or so <!ATTLIST whatever
id ID #IMPLIED> where whatever is replaced by every element in the
current namespace, given that it is common practice to allow an ID on
anything.

So given that the apparent solution employed in XML 1.0 - just define it
in the internal DTD subset which has to be parsed anyway - does not seem
to be either popular or practical, I would like to see xml:id added to
XML Blueberry since it would still serve a very useful purpose. 

It would not prevent people having an attribute caled foo of type ID and
would not prevent them from having an attribute called id which is not
of type ID; it would remove pressure to have things which are looking
for IDs (#foo in CSS, or getElementById(foo) in DOM) to just blindly
assume that anything in any namespace called id is of type ID. It would
fix esisting problems and prevent some new ones.

Copied to the XML CG since IMHO the problem can only be fixed by the XML
Core WG.

-- 
Chris

Received on Thursday, 19 July 2001 10:21:28 UTC