[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=22042#action_22042 ] 

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

This is an interesting example.

"""
For example: I add a config setting to a document. In App A it does nothing. In App B it contradicts semantics defined in ODF 1.2. Is the document conforming? Only conforming when loaded in App A? Would you agree that it is odd to speak about a document whose conformance depends on the undocumented behaviors of which particular app you load it into? You see the trouble you get into? The problem is not in the document or in the App that writes the document. The problem is in the Consumer, the app that has special behaviors based on the application setting. That is why you need to formulate this as a restriction on a Consumer.
"""

I would say that, App A may be a Conforming Consumer.

I would say that App B is not a Conforming Consumer, because it is not allowed to do that and be a Conforming Consumer.  

In addition producer, C, will have violated the conditions on an OpenDocument Document assuming that the interpretation by App B (which might be C operating as a consumer)  was the one intended as the implementation-dependent one originated or adopted by C.

Although we make implementation-dependent/-defined interpretations that might be viewed as permissions to consumers (e.g., the location of connector points in graphics and a variety of other graphics-related provisions), presumably the production of documents having content that is subject to such provisions is not a harmless act on the part of producers.  Rather, there is no assurance, in the ODF specification, that there will be any congruence between whatever approach is embodied in the producer (and that users can recognize), if any, and what is employed by the consumer (and that users can recognize).  I don't think producers get home free on that any more than consumers do, in many cases.

Of course, how anything implementation-dependent is coordinated among multiple processors is completely by means beyond the reach of the ODF Specifications.  However, there is no prohibition against implementers of producers of an implementation-dependent provision providing *their* definition for that implementation and providing the benefit of it being implementation-defined for others to adopt and have those adoptions be indentifiable as such (e.g., by relying on an agreed namespace).  

This seems to be particularly the case where arbitrary producer-determined namespaces are allowed for in the ODF specification, including in <office:settings>.

I grant that there are cases of implementation-dependent/-defined provisions that are entirely in the lap of consumers, but I don't think the use of <office:settings> is usefully regarded that way.

However, it does point out that implementation-dependent/-defined statements may often benefit from being addressed to specific conformance targets just as other normatively-stated provisions may.

> 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