[OASIS Issue Tracker] Commented: (OFFICE-3026) Public Comment: Part1 3.10.2 <config:config-item-set> too loose

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22194#action_22194 ] 

Michael Brauer commented on OFFICE-3026:
----------------------------------------

A couple of comments:

1. Most if not all applications have a set of settings that somehow influence how documents behave. Some of these settings are global, that is, they apply to all documents. Others can be controlled on a per document basis. These need to be stored in documents, and that is what application settings are for. Foreign elements are not an appropriate place for these settings, because if we would take these, most if not all documents would become extended conforming documents only. I think we all agree on this.

2. We have discussed some settings, and we see different opinions whether these are "just settings" or "already features". That's okay, because the topic is indeed complex. For instance, the color of sheet tabs: Do these tabs belong to the document and its presentation? Or are the tabs already part of the user interface? One probably could take both positions. We therefore should not take this example or any other to influence the definition of applications settings. Instead, if we change something, we should amend the descriptions of application settings so that it gets clearer what they are for.

3. In addition, we should take the individual settings in questions, and discuss for ODF-Next whether these should remain settings or turned into ODF attributes and elements. I recommend that we do the same for foreign elements and attributes we get aware of. The objective should be that if there is information that is valuable and understandable by more than one application, that it then should be standardized. Whether it will become a (standardized) setting or an element or attribute is a secondary question. I think this is a much better approach than trying to forbid certain things in application settings, because it will result in definitions in ODF that are understood by multiple applications. Just forbidding things may result in more foreign elements or attributes. But since these are also not standardized, that would have a lower value than getting standardized definitions for those things that are worth being standardized, regardless whether these are application settings or foreign elements and attributes.

4. It is in the nature of application settings that these are specific to applications. It therefore will be extremely difficult to find some normative language to cover them.

5. I still think that adding the language we had in ODF 1.1 at least is a step in the right direction. If we can provide more guidance even better. But again: If we think that a certain application setting better should be stored as ODF markup, we should discuss that setting like we discuss any other enhancement to ODF, but we should not try to solve this "issue" based on the definition of application settings.

> 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