Re: Options for dealing with IDs

On Friday, January 10, 2003, 4:44:33 PM, Jeni wrote:

JT> Hi Chris,

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

JT> You missed the option:

JT>   Add an inline, per subtree multiple ID declaration method
JT>   In the same way that xml:base added a predeclared attribute to the
JT>   existing xml:lang and xml:space attributes, add another one called
JT>   xml:idAttrs. It takes as value a whitespace-separated list of the
JT>   local names of attributes. All attributes with one of those names in
JT>   the per-element partition, on that element and its children become
JT>   of type ID. It can be used on any element. It can also take the
JT>   value "" in which case, no attributes on that element or its
JT>   children are declared to be of type ID (used when composing multiple
JT>   namespaces). An xml:idAttrs on a child completely overrides that on
JT>   its parent.

OK let me think about one. Thanks for suggesting it and formatting it
as the others - I can see that some revision of the options document
will soon be in order, which I sort of comitted to by asking for
contributions and revisions.

JT> Say you had:

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

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

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

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

The latter. I imagined that only one attribute of type ID could be in
scope on an element at a given time. I should revise the description
to make it clearer.

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

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

Uh okay but lets now say that we have a namespace toto where id is an
ID attribute and partnum is CDATA; and another namespace tata where
partnum is an ID and id is CDATA. With your proposal I would be unable
to describe the multi-namespace document

<?xml version="1.0" encoding="UTF-8"?>
<foo xml:idAttr="id partnum">
        <toto id="zeus" partnum="a54321" xmlns="http://toto"/>
        <tata id="hera" partnum="x12345" xmlns="http://tata"/>
</foo>

because it would make both id and partum into IDs on all elements.
This would force uniqueness checking on attributes where it was not
desirable.

This is why option 5 is inflexible; it requires multi-namespace
documents to have all their ID attributes changed to a single name.
Option 6 allows integration of XML snippets from multiple namespaces
without alteration. This seems beneficial in, say, an XSLT context.

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

I will add it for completeness but I don't think it makes them easier;
it seems to make them harder if anything because the list of potential
false positives grows as you add more namespaces. I appreciate the
benefits to the parser of getting a list up front on the root element,
but I think a more scoped solution would have less unintended side
effects.
  
I clearly should have been more specific that option 6 was analogous
to xml:lang and xml: base in that it is scoped and that occurrences of
it push the old value and establish a new value for that element and
its children until overridden in turn.

-- 
 Chris                            mailto:chris@w3.org

Received on Friday, 10 January 2003 11:37:43 UTC