[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (OFFICE-3026) Public Comment: Part1 3.10.2 <config:config-item-set> too loose
[ http://tools.oasis-open.org/issues/browse/OFFICE-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22025#action_22025 ]
Dennis Hamilton commented on OFFICE-3026:
-----------------------------------------
-1 on proposed resolution.
Rob, there is only one class of Conforming Consumer. It is defined here in the Overview document:
"(C13) A Conforming OpenDocument Consumer shall meet the requirements defined in part 1 section 2.2 and chapters 3 to 20 for OpenDocument consumers."
By the way, the reference to section 2.2 is incorrect. The correct section in Part 1 is 2.3.
Here is all that Part 1 Section 2.3 provides:
"""
An OpenDocument consumer is a program that can parse and interpret OpenDocument documents according to the semantics defined by this specification, and that meets the following additional requirements:
A) It shall be able to parse and interpret OpenDocument documents of one or more of the document types defined by this specification (see 3.3) any of which are represented in packages, but it need not interpret the semantics of all elements, attributes and attribute values.
B) It may be able to parse and interpret OpenDocument documents stored as single XML document, but it need not interpret the semantics of all elements, attributes and attribute values.
C) It shall interpret those elements and attributes it does interpret consistent with the semantics defined for the element or attribute by this specification.
D) It should be able to parse and interpret conforming OpenDocument extended documents, but it need not interpret the semantics of all elements, attributes and attribute values.
E) The XML parser used to parse the files contained in a package listed in 2.1.1, item A2) or the single document listed in 2.1.1, item 3) meets the following requirements:
E.1) It shall be a non validating XML processor with regard to the XML 1.0 specification [XML1.0].
E.2) It shall be and be a conforming processor with regard to the XML Namespaces specification [xml-names].
E.3) It shall conform to the xml-id specification [XML-ID].
"""
It seems to me that by virtue of 2.3(C), we have all we will get on the matter and it is up to us to say in 3.10 what that interpretation is. It does not appear to have anything to do with classes of conforming consumer.
I thought at first that the wording you offer would be better if it was worded in terms of consuming the documents as the class of conforming document the document is. However, that does not seem to matter. There is nothing different about 3.10 for different classes of conforming documents, it seems to me, beyond the prospect of foreign elements attributes and attribute values in <config:item-set> separate from the places where <config:item-set> allows arbitrary content as an explicit provision. That does not appear to be of material importance, although one would expect that foreign elements, attributes, and values would be subject to the same constraints on the scope of what 3.10 items are permitted to affect.
[Aside: It is an odd consequence of the 3.10 provisions, however, that occurrence of foreign elements, attributes or values in the way I note in the preceding paragraph impacts the conformance level of the document, whereas the allowed uses of arbitrary markup in 3.10 do not. So I do not expect the foreign element case to even arise in configuration settings except as a mistake on the part of a producer.]
NEXT STEPS
I think Section 2.3 establishes the basic constraints. The question is how we indicate that 3.10 usage shall not change what Section 2.3 says is required of conformant consumers. However, I would say the real constraint on 3.10 is on either (1) the document or (2) producers, implementations that establish the interpretation of their emitted 3.10 material. Since these items appear to be implementation-dependent on the part of producers, we need to say within what scope any implementation-dependent configuration items are to be confined with regard to conformance provision CD05-1 2.3(C).
POSSIBLE ALTERNATIVE
Maybe all we have to say is that
"""
Configuration items shall not alter the semantics defined for any element or attribute by this specification.
"""
That seems to dovetail nicely with the existing conformance clauses. (It leaves a loophole concerning foreign elements, and we can close that if we think it is important.)
It also seems to resolve the concern expressed in the Public Comment.
> Public Comment: Part 1 3.10.2 <config:config-item-set> too loose
> ----------------------------------------------------------------
>
> Key: OFFICE-3026
> URL: http://tools.oasis-open.org/issues/browse/OFFICE-3026
> Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
> Issue Type: Sub-task
> Components: General, Public Review
> Affects Versions: ODF 1.2 CD 05
> Reporter: Dennis Hamilton
> Assignee: Robert Weir
> Fix For: ODF 1.2 CD 06
>
>
> The description is in the first attachment in the public comment posted at
> <http://lists.oasis-open.org/archives/office/201006/msg00071.html>
> The complete posted comment:
> <quote>
> The text describing the usage of config-item-sets has changed from ODF 1.1 to ODF 1.2 . It used to give examples of data to store in the config-item-sets, but these examples have been removed.
> Problem:
> In ODF 1.1 it was clear that the <config-item-set>-element was intended to be used to store application specific information such as zoom level and printer settings. So the element should be used to store settings that did not impact document layout nor document functionality. I would imagine that the reason for this element was to allow applications to store their individual settings as printer choice etc in the document - while still making sure that interoperability was not hurt (since these settings did not affect the document itself).
> However - this intention has somewhat failed, since not all vendors use this element exclusively for this purpose and several strategies for extending ODF has since emerged
> An example of "improper" extension of ODF (usage of <config-item-set>-element):
> OpenOffice.org stores a large number of settings that directly affect the document layout. These settings include (but are not limited to) "UseFormerLineSpacing", "AddParaTableSpacingAtStart",
> "IsKernAsianPunctuation", "CharacterCompressionType" etc. This is not the intended usage of the <config-item-set>-element since it directly affects the content of the document.
> An example of "proper" extension of ODF (usage of ODF extension mechanisms):
> Gnumeric defines a list of extensions to (primarily) ODF spreadsheets using the extension mechanisms of ODF. These include (but are not limited to) "gnm:GnmVAlign", "gnm:diagonal-bl-tr-line-style", "gnm:format-magic" etc. These are extensions to the functionality of ODF documents and they correctly use the extension mechanisms of ODF to do so.
> Further, ODF 1.2 introduces the notion of "extended documents" and this makes it even more important to be able to distinguish between documents that are extended and those that are not.
> Proposed solution:
> I propose to add the following to the specification:
> To 3.10.2 <config:config-item-set>:
> Add the following text:
> "The setting elements SHALL not contain settings that directly impact document functionality and SHALL not contain settings that impact document layout. Application settings that impact document functionality or impact document layout SHALL use the machanisms described in 21
> "Document Processing".
> Alternatively, add normatory, explanatory text to section 22.3.2 "OpenDocument Extended producers" clearly saying that any application using the <config:config-item-set>-element to store settings that affect document layout or functionality SHALL be labelled as an "Extended producer".
> Alternatively, add normatory, explanatory text to section 22.2.2 and 22.3.2:
> Documents using config-item-sets SHALL be of conformance class "OpenDocument extended documents" and Applications creating documents using config-item-sets SHALL be of conformance class "OpenDocument extended producers".
> </quote>
--
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]