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: [office] RELAX NG and xml:id

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

   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 

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
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
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
xml:id allowance is apparently entirely in service of the RDF metadata, and
so be it.

What I do see is this in the ODF 1.2 draft 9 schema (lines 12684-12695):

    <define name="common-anim-attlist" combine="interleave">
            <attribute name="anim:id">
                <ref name="NCName"/>
    <define name="common-anim-attlist" combine="interleave">
    	 	<ref name="xml-id"/>

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 

Sent: Sunday, February 22, 2009 13:50
To: office@lists.oasis-open.org
Subject: Re: [office] RELAX NG and xml:id

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 02/22/2009 
03:30:50 PM:

> I don't think we are done on the xml:id front.

Do you have a specific proposal?  Or a specific defect to report?  We're 
not "not done" unless we identify a work item we can track.


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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