[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=22015#action_22015 ] 

Robert Weir  commented on OFFICE-3026:
--------------------------------------

I think going down the wrong road if we say things that are worded like that are requirements on what markup may express.  We should always be stating  requirements in terms of Consumers and Producers.  Markup has no behavior that we can set constraints on.  It only has syntax and a few referential integrity constraints.  Everything else needs to be worded as a constraint on a Consumer or Producer.

So something like "This element SHALL not contain settings that directly impact document functionality" is better said like "A conforming Consumer shall not..."

Now, of course you could say say things like, "A conformant consumer shall not use the presence or absence of a configuration setting to exhibit behavior that contradicts this specification".  But that is not very useful either.  A consumer should not be contradicting the standard anywhere, not only because of configuration settings.

For what it is worth, OOXML comes at this general issue from a different angle.  The have this in their conformance definition:

"A conforming application shall treat the information in Office Open XML documents in a manner
consistent with the semantic definitions given in ISO/IEC 29500. An application's intended behavior
need not require that application to process all of the information in an Office Open XML document.
However, the information that it does process shall be processed in a manner that is consistent with the
semantic definitions given in ISO/IEC 29500."

and then later:

"The documentation should highlight any behaviors that would, without that documentation, appear to violate the semantics of document XML elements"

But I'm not entirely satisfied by that,  "semantic consistency" is not defined.

In the end here is the problem.  If you have interoperability problems caused in the first place by the lack of testable requirements in a particular area, say layout, then you cannot possibly fix that by layering on even more nebulous requirements about violating consistency with the original vague requirements.  That is just a "house of cards".  I think the Danish comment leads us in the wrong direction.    What we need to do is improve definitions in other areas.  (And we've done a great deal of that in ODF 1.2 already).  Once we've done that, then we don't need to say anything about configuration 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, Public Review
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Dennis Hamilton
>             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