[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=22035#action_22035 ]
Robert Weir commented on OFFICE-3026:
--------------------------------------
Dennis., I disagree with your interpretation of your formulation. I think that shows that it is not unambiguous.
To review, your proposal was: "The application settings in the <office:settings> element of of any class of OpenDocument Document (section 2.1) shall not alter the semantics defined for any element or attribute by this specification."
1) table:formula is an attribute with semantics defined by this specification.
2) Adding an application setting that specifies numeric precision would alter the behavior (the semantics) of the application based on that application setting, since the calculation could yield different results based on the presence or absence of the setting.
3) This application would not be conformant, since you say application setting shall not be used to alter semantics of an element or attribute defined in the specification.
I also showed above that your statement can be read to be meaningless and to not disallow any uses of config items. So if the same constraint can be read to prohibit no, all or just some uses, then the statement needs some work,
Maybe it would help if you gave some more examples of what kinds of things should be prohibited? Andreas suggested tab coloring. I agree that this is more naturally done as a style extension. That fits better with the overall design of ODF. Application settings are best used for settings that apply to the document overall, as with a global mode or setting. You would really need to do odd things to get it to apply only to specific content elements. For example, if you had individual settings for tab-color-1, tab-color-2, tab-color-3, etc., that would a poor design.
On the other hand I am not sure that a standard can effectively legislate good taste or good designs. We provide the means for doing features like this in better way. But it may end up that we are not able to craft language that permits only good designs.
To move this discussion forward, can someone give me a few examples of application settings (they don't need to be actual ones; could be hypothetical) that would be conformant under the existing definitions, but which they believe should be prohibited under a new rule. Maybe that will lead to a rule that we can specify that clearly distinguishes them.
For example, what is "bad" about tab coloring? Is it that the setting would be for a specific content element instance, not for a class of elements? In other words, would the spreadsheet precision example become a "bad" setting if it said, "use extended precision on tab 1" rather than applied globally? Is that the distinction we're trying to make?
Or is the point that precision is called out as implementation-defined, but tab color is not discussed at all? In other words, tab color is implicitly rather than explicitly implementation-dependent. (We can take it as axiomatic that anything not explicitly defined, including explicitly defined as implementation-defined, is implicitly implementation dependent). So is the rule that application settings can only influence things that are explicitly defined? But what about printer settings, which the public comment said should be done in application settings? There is nothing in the spec about printing? So print behavior is implicitly application-dependent.
So I need some help to understand exactly how you are trying to draw the line here.
> 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]