W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: Options for dealing with IDs

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 10 Jan 2003 15:44:33 +0000
Message-ID: <6323183095.20030110154433@jenitennison.com>
To: Chris Lilley <chris@w3.org>
CC: www-tag@w3.org

Hi Chris,

> If I have omitted a solution, or omitted significant advantages or
> disadvantages, I would be glad to hear them.

You missed the option:

  Add an inline, per subtree multiple ID declaration method
  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:idAttrs. It takes as value a whitespace-separated list of the
  local names of attributes. All attributes with one of those names in
  the per-element partition, on that element and its children become
  of type ID. It can be used on any element. It can also take the
  value "" in which case, no attributes on that element or its
  children are declared to be of type ID (used when composing multiple
  namespaces). An xml:idAttrs on a child completely overrides that on
  its parent.

Say you had:

    <bar id="fred" />
    <baz ID="barney" />

and both id and ID are IDs. With xml:idAttr you could do:

  <foo xml:idAttr="id">
    <bar id="fred" />
    <baz xml:idAttr="ID" ID="barney" />

As I understand it, if <baz> had an id attribute then that would also
be counted as an ID. Is that correct, or is your intention that there
is only ever be one attribute in scope as an ID attribute at any one

xml:idAttrs would allow multiple attributes to be labelled as ID
attributes; in this example you could do:

  <foo xml:idAttrs="id ID">
    <bar id="fred" />
    <baz ID="barney" />

I'm not sure this would be my favoured option, but I think it should
be added for completeness. It has the advantage that it makes altering
documents with mixed namespaces (and with different names for ID
attributes in those namespaces) easier than xml:idAttr.


Jeni Tennison
Received on Friday, 10 January 2003 10:45:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:56 UTC