[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=22262#action_22262 ]
Michael Brauer commented on OFFICE-3026:
----------------------------------------
Andreas:
Re (1): If we agree that the need application settings, but store them as foreign elements, the result is that nearly all documents will be ODF extended documents. We then can safely remove the the "conforming" classes, and are exactly where we are today. So, I don't think this solves the issues. Regarding namespaces. We have them. 19.3 config:name states: "For <config:config-item-set> elements that are children of <office:settings> elements, the name should begin with a namespace prefix followed by a ":" (U+003A, COLON). The XML namespace bound to the prefix identifies the implementation that defines the name of a setting."
Re (2): We have identified a piece if information (the table color) that is currently stored as application setting by one application, and where we disagree whether this is a valid use of application settings. Please let us discuss this issue separately instead of trying to resolve it indirectly by forbidding certain information in application settings. I'm sure we find a solution for this.
Re (4): They are namespaced.
Re (5): I don't know there the concern that applications may store extensions in application settings comes from. We may disagree on some application settings, but the root cause is not application settings have been intentionally used instead of foreign elements, but that we have here and there different opinions what is "just as setting" and what is "already an extension". We best solve that by looking at the application settings in question, but also at the extensions, individually, and by deciding for each of them what the best way to store it is. This, and only this, improves interoperability. If we just move application settings to foreign elements, we may decrease the number of conforming documents, but we still do not have definition of the settings themselves. BTW: Most application settings we have in documents did already exist in ODF 1.1 times, where we did not have a distinction between conforming and extended conforming documents. So, the assumption that application settings have been used in order to keep documents conforming is wrong.
Dennis:
I think you are wrong the the assumption that application settings are used to avoid extensions. See my comment "re (5)" to Andreas.
> 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, Needs Discussion, 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]