[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-1354) Public Comment: Re:[office-comment] ODF schema is faulty (ODF all versions)
[ http://tools.oasis-open.org/issues/browse/OFFICE-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14862#action_14862 ]
Dennis Hamilton commented on OFFICE-1354:
-----------------------------------------
I disagree that this is a trivial issue.
I am aligned with the notion that xml:id be defined to have type ID. That makes it valid for reference in fragment identifiers in IRIs, such as those used in RDFa and the RDF Metadata extension introduced in ODF 1.2. [xml-names] is not going away. Only the W3C gets to say what the rules are for use of xml:* forms of names and the implicit XML namespace they are bound to.
CAUTION: There is an important rule in [xml-names] that must be honored, however.
It is permissable for the same element to have multiple attributes (of different name) with type ID. However, they may not have the same values. In fact, duplicate values are not permissible for attributes of type ID anywhere in the same XML document, regardless of the name of the attribute.
This is an important matter where there are ODF 1.1-and-prior attributes that have been changed from type ID to type NCName. In particular, these are no longer referenceable via attributes of type IDREF. Instead, they can be reference by attributes of type NCName. It is appropriate to make this change since the defining occurrence is often in a different XML document of the same package (that is, it is a non-IRI reference from one package XML document to a fragment of another XML document in the same package and part of the ODF-specific structure).
The problem with the change to NCName is that all of the semantics regarding which occurrences are the defining occurence (akin to ID) and which are referencing occurrences (akin to IDREF) must be spelled out in the ODF specification and the rules for integrity of the structure must also be established. (I.e., whether a document is ODF-valid even when there are references not satisfied by defining occurrences, when there are duplicate defining occurrences, etc.)
In addition, there are uses of "name"-type attributes in this way but the attributes are specified to have values of type string. Reverting to NCName has much more conceptual integrity, but it it probably a breaking change and there may need to be a deprecation cycle to work our way out of that.
In some cases, it is not clear whether some naming-usage attributes that are part of the structural connection among XML documents of a package are meant to be user specifiable and are required to be user-presentable. The domain of uniqueness is also unclear in that regard. (For xml:id the domain of uniqueness is the XML document but that is insufficient for these names that are defined and referenced in different XML documents of a package. However, these could have distinct domains, such as table names versus chart names versus drawing names where uniqueness is only required to be preserved within such domains. It is very unclear what the requirement is for ODF and how users are to understand it when given the opportunity to choose the value of the name string.)
RECOMMENDATION FOR CONSIDERATION
It is these considerations that lead me to recommend that xml:id be the only attribute of type ID, ad that there be no attributes of type IDREF in the ODF structure itself. This would leave xml:id for establishing fragment identifiers that are used only via IRIs and could be used by RDFa and the RDF metadata and any other special purpose without concern for interfering with the ODF-required document structure. So long as an element is preserved in editing and other processing that leads to a derived document, any xml:id should be preserved.
I also believe that xml:id should be allowed on any element and that processors that rely on xml:id in some way will be able to sort out which ones matter for its processes and which ones are immaterial but will be preserved (so long as validity requirements of xml:id typing are maintained).
> Public Comment: Re: [office-comment] ODF schema is faulty (ODF all versions)
> ----------------------------------------------------------------------------
>
> Key: OFFICE-1354
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-1354
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Bug
> Components: Schema
> Affects Versions: ODF 1.0
> Reporter: Robert Weir
> Assignee: Michael Brauer
> Priority: Trivial
> Fix For: ODF 1.2
>
>
> Copied from office-comment list
> Original author: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
> Original date: 6 Mar 2009 11:43:53 -0000
> Original URL: http://lists.oasis-open.org/archives/office-comment/200903/msg00078.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]