[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] RELAX NG and xml:id
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]