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 you comments and suggestion regarding the ODF
schema.

I have a couple of questions regarding your suggestions and other
suggestion that were made where I would like to know your opinion:

a) Alex Brown has suggested to use W3C xml:id rather than Relax NG DTD
Compatibility:

"In fact I think that (ideally) the schema should be re-written so that
its dependency on DTD-compatibility features is removed, and the
standard can then remove the reference to this troublesome spec. But
that is obviously quite a change.

If this were done, the ID semantics (currently declared using
DTD-compatibility) could be supplied, in the modern manner, by using W3C
xml:id [1]."

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?

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.",

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.

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?

b) The Relax NG DTD Compatibility specification states in section 2 that

"Conformance is defined separately for each feature. A conformant
implementation can support any combination of features."

and

"A conformant implementation may support different features at different
levels."

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?

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.

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?

Thanks and best regards

Michael


MURATA Makoto (FAMILY Given) wrote:
> Dear colleagues,
> 
> The RNG schema for ODF 1.0 is "correct" (as defined in ISO/IEC
> 197575-2), but is it not compatible (as defined in  "RELAX NG DTD
> Compatibility"), as Alex correctly pointed out.
> 
> For example, consider the form:id attribute.  It is defined as
> ID. After schema normalization (as defined in ISO/IEC 197575-2), this
> attribute will occur in the define element for <form:text>. That
> define element competes with the definition of anyElements.  However,
> the definition of anyElements does not specify the attribute form:id
> as an ID.  Therefore, the condition in the last bullet of the first
> itemized list of Section 3 of "RELAX NG DTD Compatibility" is not
> satisfied.
> 
> One way to solve this problem is to replace
> 
> mathMarkup =
>   (attribute * { text }
>    | text
>    | element * { mathMarkup })*
> 
> 
> by 
> 
> mathMarkup =
>   (attribute * -  (anim:id
>               | draw:control
>               | draw:end-shape
>               | draw:id
>               | draw:shape-id
>               | draw:start-shape
>               | form:id
>               | presentation:master-element
>               | smil:targetElement
>               | text:change-id
>               | text:id)  { text }
>    | attribute anim:id { ID }
>    | attribute draw:control { IDREF }
>    | attribute draw:end-shape { IDREF }
>    | attribute draw:id { ID }
>    | attribute draw:shape-id { IDREF }
>    | attribute draw:start-shape { IDREF }
>    | attribute form:id { ID }
>    | attribute presentation:master-element { IDREF }
>    | attribute smil:targetElement { IDREF }
>    | attribute text:change-id { IDREF }
>    | attribute text:id { ID }
>    | text
>    | element * { mathMarkup })*
> 
> and replace 
> 
> anyAttListOrElements =
>   attribute * { text }*,
>   anyElements
> 
> by
> 
> anyAttListOrElements =
>   attribute * -  (anim:id
>       | draw:control
>       | draw:end-shape
>       | draw:id
>       | draw:shape-id
>       | draw:start-shape
>       | form:id
>       | presentation:master-element
>       | smil:targetElement
>       | text:change-id
>       | text:id) { text }*,
>   (attribute anim:id { ID }
>    | attribute draw:control { IDREF }
>    | attribute draw:end-shape { IDREF }
>    | attribute draw:id { ID }
>    | attribute draw:shape-id { IDREF }
>    | attribute draw:start-shape { IDREF }
>    | attribute form:id { ID }
>    | attribute presentation:master-element { IDREF }
>    | attribute smil:targetElement { IDREF }
>    | attribute text:change-id { IDREF }
>    | attribute text:id { ID })*,
>   anyElements
> 
> After this change, jing does not complain.  (But remember that jing
> does not check a:defaultValue.)
> 
> You might want to be more specific.  For example, the definition of
> mathMarkup can be:
> 
> mathMarkup =
>   attribute local:*  { text }
>    | attribute xlink:href { text }
>    | attribute xlink:type { text }
>    | text
>    | element mml:* { mathMarkup })*
> 
> where 
> 
> namespace local = ""
> namespace mml = "http://www.w3.org/1998/Math/MathML";
> 
> 
> 


-- 
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]