- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Mon, 23 Jan 2006 10:49:46 +1100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: www-svg@w3.org
On Jan 02, 2006, at 10:24, Bjoern Hoehrmann wrote:
> My reading of the xml:id Recommendation is that the attribute values
> must be unique as opposed to uniquely identify an element, so keeping
> them in sync would actually trigger xml:id errors.
This constraint is a "should" in xml:id: "An xml:id processor should
assure that the following constraint holds:
The values of all attributes of type “ID” (which includes all xml:id
attributes) within a document are unique."
I posit that:
a) handling a transition from legacy id attributes that cause
problems with scripts in the absence of a DTD
b) the fact that there is no DTD in 1.2
c) the constraint that the two ID attributes are on the same element
constitute good reasons for go against that "should". The alternative
is to make 'id' not be of type ID in SVG 1.2. That would be okay by
me but I'm not convinced it's the best approach. I much prefer the
former. Your feedback is welcome as to which approach you prefer.
> The new text notes
>
> when both 'id' and 'xml:id' are specified on the same element but
> with different values, the resulting behaviour is unspecified and
> implementation-dependent. It is however recommended that whenever
> possible, implementations should give precendence to the 'xml:id'
> attribute.
>
> I don't really understand what this means, e.g., which behavior is
> referred to here or what giving precedence to the xml:id attribute
> would mean. The intent might be to say that the SVGElement::id
> attribute must return either the value of the id or the xml:id
> attribute and should return the value of the xml:id attribute.
That is the intent, and the text has been clarified by indicating
that this is indeed what is being referred to.
Please let us shortly how your concerns would be best addressed for
the former, and if the latter addresses the remainder of them,
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
Received on Sunday, 22 January 2006 23:50:02 UTC