Dennis,
On 02/23/09 03:43, Dennis E. Hamilton wrote:
> My smoke test (stumbled-upon previously when we were in the middle of the
> RDF Metadata proposal), is this sort of thing (cd01 p.334, the first of
> several):
>
> 18.7 anim:id
>
> The anim:id attribute assigns an ID to an animation element.
>
> The anim:id attribute is deprecated in favor of xml:id. See 18.920.
>
> Applications that read documents shall ignore this attribute if there
> is an xml:id attribute existing for the same element. If no xml:id
> attribute is existing for the same element, then the anim:id attribute
> should be processed as it were an xml:id attribute.
>
> Applications that write documents may still write anim:id attributes
> in addition to xml:id attributes. An element shall not have an anim:id
> attribute if there is no xml:id attribute existing for the same element.
> The value of the anim:id attribute shall equal the value of the xml:id
> attribute.
>
> My suspicion is that this and statements like it are inaccurate, possibly a
> violation of the xml:id specification, and perhaps even unnecessary. If the
> last paragraph is intended to support downward compatibility, I think it
> doesn't work (unless down-level processors think xml:id is an ignorable
> foreign element!?). As far as I can tell, it is illegal for two attributes
> of type ID to have the same value anywhere in an XML document, including on
If both attributes would have the type "ID", then you would be correct.
But as you notice yourself below. One is of type ID, and one is of type
NCName. So, they may have the same value. Otherwise there would have to
be a constrain that an value that is used as value of an attribute of
type ID must not be used as value of a NCName. This constrain does not
exist.
> the same element, which is the down-level situation if both are present. In
> 1.2, anim:id is not of type ID (so the first paragraph of 18.7 is
> incorrect), and the penultimate paragraph is intended to turn one into an ID
This depends on whether one assumes whether "ID" is just an abbreviation
of "identifer" or the "W3C ID datatype".
> to satisfy any existing IDREFs to it from a down-level document.
>
> What I haven't resolved, using anim:id in particular, is where an element is
> validly referenced by an anim:id value that has been assigned to it. Until
> I have figured that out, I can't tell exactly how severe the problem is and
> what problem we think this language is solving. If, on the other hand,
> there is no defined way to refer to an anim:id in ODF documents, we should
> simply change it to an NCName as we are doing and deprecate it, period. the
We have changed it to an NCName. We have deprecated it. That we use the
term "ID" in the description may be confusing, but that would be easy to
resolve, wouldn't it?
Best regards
Michael
--
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH Nagelsweg 55
D-20097 Hamburg, Germany michael.brauer@sun.com
http://sun.com/staroffice +49 40 23646 500
http://blogs.sun.com/GullFOSS
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering