OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: ODF 1.2 RDF Metadata, xml:id, and ID deprecation - PROBLEM


Dennis,

On 01/11/09 23:05, Dennis E. Hamilton wrote:
> I recommend that this analysis be double-checked carefully.
> 
> I believe there is a serious defect in the way xml:id is introduced in ODF 1.2 and in how other uses of attributes having ID type are being deprecated.
> 
> Because this is relevant to the way the ODF 1.2 Metadata proposal is introduced (and it is partly what led to this research), I believe this topic needs to be given urgent attention.
> 
> 1. The problem is with the statements of this kind (here from 18.7 on 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.1278.
>       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.
> 
> There are several difficulties:  
> 
>    1.1 The proper rules for identifying XML elements as targets of fragment references (including via IDREF and IDREFS) has to do with the type of the attribute, not its name, whether or not the name is xml:id ( or has "id" in it, although there is a widespread practice of using attributes with "id" as their local name as names of ID valued attributes).
> 
>    1.2 [XML 1.0] forbids (as valid XML) elements having more than one attribute of type ID and any two attributes of type ID having the same value in the same XML document (accessing fragments in a different XML document being a separate matter usually handled with a URI).

This is correct, and this is exactly the reason why my proposal also 
changed the type of anim:id, etc. from ID to NCNAME. See

http://wiki.oasis-open.org/office/proposal%3Axml-id

It states:

"The datatype of the following attributes will be changed to NCName:

anim:id (all occurrences)

draw:id, where listed above

text:id, where listed above

form:id (all occurrences)"

> 
>    1.3 The [XML Names] specification preserves that rule but further constrains attributes of type ID to have values that are lexical NCNames rather than Names (that is, no ":" characters in the values for attributes of type ID).

ODF 1.1 amd 1.2 use NCName and ID for these attributes. I therefore 
don't see why this should be an issue.


> 
>    1.4 The [xml:id 1.0] specification very carefully preserves the [XML 1.0] requirement.  There is a place that can be read as relaxing the [XML 1.0] rule, but that is not about the validity of the document but about a requirement on processors.
> 
>    1.5 The only language that I can find that proposes two attributes taking the same value, one of them being of type ID, is when the others are *not* of type ID.  [This, by the way, is a better way to deprecate those ID-valued attributes from ODF 1.1 so that they don't clash with use of xml:id -- change them to have values of type NCName rather than ID in a way that ODF 1.1 usage remains upward compatible but there is no collision with an xml:id on the same element.]  An example of such language is in [XHTML 1.0] section C8:
>
I think this is exactly what we did. Or what did I oversee?

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]