Action: Rewrite para 4 of 4.10.4.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The paragraph in question is:

  It is common practice to assume that when an element has an
  attribute that is declared in a DTD to be of type ID, then the
  fragment identifier #abc identifies the element which has an
  attribute of that type whose value is "abc". However, there is no
  normative support for this assumption and it is problematic in
  practice, since the only defined way to establish that an attribute
  is of type ID is via a DTD, which may not exist or may not be
  available.

I've "rewritten" it as shown below, replacing not only paragraph 4,
but all of the remainder of section 4.10.4. I'm not sure this is a
"plug and play" replacement for the existing paragraph, nor am I sure
that it's a level of detail that's appropriate in 4.10.4. But I submit
it anyway for your consideration.

Speaking informally, most people assume that the interpretation of a
fragment identifier of the form #abc on an XML document is that it
identifies the element in the document with the ID "abc".

Unfortunately, there are a number of open issues associated with
finding the element with the ID "abc" in an XML document. In XML, the
quality of "being an ID" is associated with the type of the attribute,
not it's name, so it is not self-evident from only the elements and
attributes of a document. Consider the following fragment:

  <section name="foo">

Does that section have the ID "foo"? There's no way to tell from just
that element and its attributes. Finding the IDs in a document
requires some additional processing.

  1. Processing the document with a processor that recognizes DTD
     attribute list declarations (in the external or internal subset)
     might reveal a declaration that identifies the name attribute as
     an ID.

     Note that this processing is not necessarily part of validation.
     A non-validating, DTD-aware processor can perform ID assignment.

  2. Processing the document with a W3C XML Schema might reveal
     an element declaration that identifies the name attribute as an
     xs:ID.

  3. In practice, processing the document with another schema language,
     such as RELAX NG, might reveal the attributes of type ID. Many
     modern specifications begin processing XML at the infoset level
     and do not specify normatively how an infoset is constructed.
     For those specifications, any process that establishes the ID type
     in the infoset (and/or PSVI) will successfully identify the
     attributes of type ID.

There is some added technical complication in the fact that DTDs
establish the ID type in the infoset whereas W3C XML Schema produces a
PSVI but does not modify the original infoset. This leaves open the
possibility that a processor might exist which looks only in the
infoset and consequently does not recognize schema-assigned IDs.

Finally, if this weren't complicated enough, the XML Core WG is
currently investigating a solution that could provide ID values in
well formed documents that have no associated schema through a
reserved attribute, xml:id.

For further background on this issue, and an exploration of the
various alternatives that might logically be pursued, please see TAG
finding "How should the problem of identifying ID semantics in XML
formats be addressed in the absence of a DTD?" and the issue that
generated it, TAG issue xmlIDSemantics-32: How should the problem of
identifying ID semantics in XML formats be addressed in the absence of
a DTD?

TAG issue fragmentInXML-28: Do fragment identifiers refer to a
syntactic element (at least for XML content), or can they refer to
abstractions? See TAG issue.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | Convictions are more dangerous enemies of
XML Standards Architect | truth than lies.--Nietzsche
Web Tech. and Standards |
Sun Microsystems, Inc.  | 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQE/VkRzOyltUcwYWjsRAnWOAJ9/mHE8jIEWq2B4xfYxAK0QXCRgCQCdGyH3
uz4aOA+Yfi8sg7dW6H00Ulw=
=4fOT
-----END PGP SIGNATURE-----

Received on Wednesday, 3 September 2003 15:44:25 UTC