OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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=22036#action_22036 ] 

Dennis Hamilton commented on OFFICE-3026:
-----------------------------------------

I'm going to stick with this

""" 
In Section 3.10.1, add the following paragraph after the only paragraph currently there (in CD05): 

"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." 
""" 

If there is a problem with "class of OpenDocument (section 2.1)", I can be specific once we agree on how Conformance Targets are named in ODF 1.2 (or I can simply refer to the appropriate conformance clauses in the Overview).

I think "semantics defined for" is good enough, and if you want "semantics explicitly defined for" I'll give you that.

With regard to the various objections, I think the examples are very interesting.

 1. Andreas mentioning using configuration settings to color tabs in a spreadsheet document presentation is an interesting one.

     1.1 This raises what may better be dealt with as a separate issue.  We tend to assume that default styles, the ones that are impementation-dependent, are always styles that could have been specified explicitly.  We even say, the thing to do is for a producer to set the styles that it employed by default in presenting the document as a consumer (or words to that effect). 

     1.2 The loophole might be the missing requirement that the default shall not provide any styling that cannot be explicitly specified in accordance with this standard.  (Note, rewriting user-specified styles so defaults are never exercised is actually quite tricky, because of style chaining and inheritance when there is a named style on an element.  We want it to be possible without necessarily requiring it.)

     1.3 I don't know what that does for tab coloring, though.


 2. With regard to those places where we allow an attribute value to have its initial content be a namespace prefix followed by a colon, where the namespace binding determines the syntax and the semantics of the remainder of the attribute value in connection with the specified purpose of the attribute, I see no problem.  
    2,1 That condition prevails.  In this case, if there are discretionary provisions in that specified syntax and semantics, I don't know why there could not be applicable configuration settings, identified in such a way that they might be applicable.  
    2.2 I think it would be unacceptable if such an usage required configuration settings, but a producer might be able to make a strong case for doing that.  The syntax and semantics of the namespaced attribute value might depend on global parameters or something like that, and since configuration options have namespace-prefixed names too, there is certainly a way to define setting of such global parameters.  If the particular usage of such an allowed feature as a macro, formula, script, or other places where such things are allowed, and the syntax and semantics is defined as configurable, I suppose it can have configuration settings defined for it.  Of course, if a consumer does not support the particular binding on the attribute value, it doesn't matter whether there are related configuration settings.  Whether a consumer that does support the binding on the attribute value also recognizes relevant configuration settings is something on which we can rightly be silent.
   2.3 Likewise, in the case of foreign elements, attributes, and values, they might be configurable in like manner (2.2), tied to the non-ODF namespaces that are employed.  It would seem that developers of foreign elements, attributes, and values would find better ways to do that, but I see no reason why configuration settings could not be applicable, whether honored or not by a consumer that does recognize and interpret particular foreign elements, attributes, and values.

3. I think there is always going to be room for judgment on some of these, and it will depend on the community, procurement policies (and profiling of ODF for procurement purposes) that will be needed for grey cases.

4. Rob, so what is an existing use of configuration settings that you think this provision would exclude that you don't find acceptable, when there are of course perfectly good ways, maybe better ways, to introduce implementation defined extensions instead?  I do claim that this provision does not interfere with the introduction of foreign elements, attributes, and values at all.

> 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]