Re: Options for dealing with IDs (introducing 4a)

I have been trying to sort through this tangle for a long while, and
would like to propose a very practical variant on #4.

> 4) Add a predeclared id attribute to the xml namespace
>   In the same way that xml:base added a predeclared attribute to the
>   existing xml:lang and xml:space attributes, add another one called
>   xml:id. It is of type ID. It may cannot be declared (or redeclared)
>   and thus its type cannot be changed. It can be used wherever you
>   want an reliable, interoperable identifier
> 
>   Advantages
>   - easy to explain
>   - easy to use
>   - easy to change content to use the new syntax
>   - no clash with DTDs or Schemas

BTW: I don't buy that this is true.

>   - existing content not inadvertently affected
> 
>   Disadvantages
>   - requires a (small) change to XML spec and XML parsers

This is the killer.  My proposal eliminates this disadvantage.

>   - no help for (all existing) content that uses a different
>     name for its IDs
>   - requires revision in any content specs that want to make use of it

4a) Add an attribute named "id" to the xml namespace.  To type the 
    attribute as ID or xs:ID, it must be declared appropriately in a DTD

    or Schema, or use a suitable minimally-conforming Schema processor.

Rationale:

First, DTD IDs and xs:ID are two separate solutions to the ID problem,
that don't work well together.  The gyrations of the XPointer Framework
in accommodating both demonstrate this point.  Rationalizing and
unifying these two mechanisms would require revision of both the XML
Infoset and XML Schema.  This is not practical in the short term.

An xml:id that leveraged the [attribute type] property (DTD-based ID)
would require a revision of the XML Infoset, which is also impractical,
and doesn't provide any help for processors that are relying on the
xs:ID mechanism to identify IDs.  An ideal solution requires NO changes
to XML, XML parsers, or the XML Infoset.

It appears to me, however, that simply spelling "id" the same way
(universally across namespaces) solves perhaps 50% of the problem, at
virtually no cost.

The xml:id attribute would act as an ID in a document validated against
a DTD that declared xml:id as an ID.  We would of course strongly
encourage people not to shoot themselves in the foot by foolishly
declaring xml:id as some other type.  Since xml:id does not invent a new
parallel mechanism, all issues about how xml:id and other ID-typed
attributes interact disappear.

The xml:id attribute would act as an xs:ID in a document validated
against a Schema that declared xml:id as an xs:ID.  We would encourage
this by updating the W3C Schema for the xml namespace.  Again, any
issues about interaction with other xs:ID-typed attributes/elements are
already handled by schema disappear.

A processor not validating against a DTD or a Schema, but still wishing
to identify xml:id as an ID, would build in a simple mechanism for
validating just the xml:ID attributes as unique identifiers.
Conceptually, we can model this as a minimally-conforming schema
processor operating on a schema for only the xml namespace, or even just
for the xml:id attribute itself.  There are no prohibitions against
_any_ processor applying such a schema.  Leveraging schema validation
guarantees uniqueness and lexical validity, eliminating many issues from
the definition of xml:id.
 
From the author's perspective, while he cannot guarantee that the
recipient will perform DTD, full Schema, or minimal Schema validation,
he can have confidence that any non-legacy application willing to look
for IDs will be able to recognize xml:id.

As xml:id gains widespread deployment, we could consider automatic
typing of the attribute in a rev of XML.  But I suspect it won't matter
much by that time.

Received on Friday, 7 February 2003 13:32:37 UTC