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