[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=22023#action_22023 ]
Robert Weir commented on OFFICE-3026:
--------------------------------------
Dennis, when you said "the problem is using configuration settings __as a way to __ fix that for an implementation rather than..." then you are talking about intent rather than application behavior.
Motivate == trigger == cause == specify == exhibit == reveal == "introduce details" (as you have it)
The problem with your proposals (IMHO) is they are nebulous on what the requirement is on, whether the document, the producer or the consumer. The sentences have the subject as "nothing" or "<office:settings> which I think confuses the point.
I think your 2nd formulation of it is better, if you could restate it as a requirement on a conformance product (document, consumer or producer).
For example, I had "An ODF Consumer may use the contents of <config:config-item-set> elements to motivate application behaviors within the range of variability allowed in this specification." I think that covers it, if we can agree on an alternative to "motivate". Maybe just say "to behave within the range of variability...".
I see no reason to say "shall not alter the specified interpretation" since there is nothing anywhere in the spec that suggests that it does. The default rule is "to conform to the spec, conform to the spec", and so long as we give no rules that suggest otherwise, then we're fine. But once we start giving redundant notes about what conformance means in one place, the reader may get confused that we don't say the same thing in other places, such as with package extensions, or with metadata. I think we should just stick to the conformance statement, since it is clear and already covers this.
Andreas, the point about extended versus non-extended is different. Extended documents are outside of the schema defined by ODF. So processing them by several classes of applications is much harder. For example, anyone doing XML-to-relational DB mapping of documents. Or toolkits like ODFDOM that have code generated directly from the schema. Generally any app that assumes a fixed schema as defined by the standard could be broken by extended documents, or at the very least have difficulties round-tripping the extensions. The config settings are not schema extensions, so they don't introduce this additional complexity.
> 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
> 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]