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


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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

Subject: Re: [office-comment] Ambiguity problems caused by ID/IDREF

Dear Murata-san,

thank you very much for the clarifications. I think they will be very 
helpful when we discuss the topic in the TC.

Best regards


MURATA Makoto (FAMILY Given) wrote:
> Michael,
> Thank you for your thoughtful mail.  I am happy to see that you 
> are serious about bug reports.
>> a) Alex Brown has suggested to use W3C xml:id rather than Relax NG DTD
>> Compatibility:
> snip
>> Would the use of W3C xml:id without using the Relax NG DTD
>> Compatibility Specification in your opinion add ID semantics to the
>> xml:id attribute?
> I think so.  In other words, I do not understand the non-normative 
> appendix "D Validation Technologies" of xml:id.   But you might want 
> to hear the opinion of the editors of xml:id.
>> The W3C XML ID specification in appendix D.2 recommends:
>> "RELAX NG Grammar authors are encouraged to declare attributes named
>> xml:id with the type xs:ID.",
> Yes.  I do not understand why this is encouraged.
>> and the "Guidelines for using W3C XML Schema Datatypes with RELAX NG"
>> state that
>> "The semantics defined by [W3C XML Schema Datatypes] for the ID, IDREF
>> and IDREFS datatypes are purely lexical and do not include the
>> cross-reference semantics of the corresponding [XML 1.0] datatypes."
>> This sounds to me like that using W3C xml:id without Relax NG DTD
>> Compatibility does not specify ID semantics for xml:id.
> In my understanding, the xml:id processor should provide ID semantics
> for xml:id.
>> On the other hand, the W3C xml:id specification also states that:
>> "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."
>> so at least the uniqueness of the IDs may have to be checked. However,
>> the semantics of IDREF attributes seem to remain purely lexical unless
>> the the Relax NG DTD Compatibility Specification is used. Is my
>> understanding correct?
> I think that you are right.  I do not know why the xml:id spec does not 
> provide xml:idref as well.
>> Is my understanding correct that a specification that uses Relax NG
>> (like ODF) may require conformance with only one, or two of the three
>> features defined by Relax NG Compatibility. In particular, is it
>> possible to request conformance with the attribute default value
>> feature, but not with ID/IDREF feature? Or vice versa, could a
>> specification request conformance with the ID/IDREF feature only?
> Strictly speaking, the DTD compatibility spec defines conformance 
> of application programs but do not define conformance of schemas.  
> It rather defines compatibility of schemas.  A schema may be compatible 
> with the ID/IDREF/IDREFS feature without being comptible with the attribute 
> default values feature.
>> In other words: Is your suggestion to claim conformance to the ID/IDREF
>> feature in the future, but to not claim conformance to the attribute
>> default value and documentation features? Or is your suggestion to
>> claim conformance to the full DTD Compatibility specification, but to
>> not define any a:defaultValue attributes or a:documentation elements in
>> the schema, so that all that what is said about these features in the
>> Relax NG DTD Compatibility specification simply is not applicable to the 
>> ODF schema.
> The latter.  But I do not think a:documentation elements should be 
> prohibited.
>> And is it in your opinion permitted that the ODF specification currently
>> makes only use of the default value feature without claiming conformance
>> to the ID/IDREF or documentation feature?
> The ODF schema is NOT compatible with the default value feature.  
> It is NOT compatible with the ID/IDREF feature.  Since it does not 
> have any occurrences of a:documentation elements, it is compatible 
> with the documentation feature.
> Hope this helps.
> Cheers,

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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]