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=22038#action_22038 ] 

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

The reason I have not surrendered my counter-proposal is because 

"""
"An ODF Consumer shall use <config:config-item-set> elements to alter application behavior only within the dimensions of variability permitted by this standard" 
"""

Is ridiculous. Consumers don't record <office:settings>, they are found in documents and producers put them there.   Furthermore, as we have seen, the provisions of section Part 1 Section 2.3(C) already delimit this case. 

I have made an effort to say what is an allowable form in an OpenDocument Document, thereby constraining what a producer can introduce into such a document's <office:settings>, no matter what a consumer makes of them.

I think there are two things we want to limit <office:settings> to.  

First choice is provision of information that a producer is recording that has nothing to do with the semantics of the document.  Things like what page was last in view, maybe even an undo stack that can be recovered from a saved document by a compatible consumer (i.e., the same software).  Perhaps even auto-save settings and other details that matter to an implementation but are not material to the document, as such.

Second choice is information that might refine the fixed semantics of elements, attributes, and values within the variability that is left discretionary under the explicit semantics.  Such matters as preference for fast approximations rather than high-quality results in an OpenFormula integration, or maybe even a rule for preventing the starting of a line with certain CJK characters.  I could see identification of the spell-checker and dictionary used with the document, or the hyphenation procedure and its enabling of non-breaking hyphen distinction in the Unicode text strings that are processed for layout.  

None of these cross the line with regard to ODF 1.2, although the CJK-line-start-prohibition is clearly something that might be handled better with a defined style, and that should be considered in ODF-Next perhaps.  

I note that 2.3(C) expresses a consistency condition.  Maybe this ensures there is no loophole in <office:settings>:

This seems a little awkward, but maybe it gives us a better start:

""" 
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 be consistent with the semantics explicitly defined for any element or attribute by this specification." 
""" 

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