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-2759) 3.17 ForeignElements and Attributes - last two sentences of last paragraph in section -Unclear what is meant.

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=20353#action_20353 ] 

Dennis Hamilton commented on OFFICE-2759:

It would appear that this is dealing with a case where (1) a future version of the specification introduces more values, (2) a producer is introducing additional values not provided for under the OpenDocument specification (in which case it would appear that rejecting the document is also an option), or (3) a producer uses a defined extension mechanism for introducing externally-defined values into the attribute AND the consumer does not recognize that extension.  Note that if the consumer does recognize such a value, the recommended behavior is inappropriate.  Even If the consumer is limiting what it accepts to conforming documents, that is one thing, but if it recognizes specific foreign cases, it can behave in a variety of ways, including supporting the case or reducing to a conformant interpretation of the document in a more-flexible way.

I don't see how (1) applies, since the consumer will presumably be able to detect that a document created under a different version than the consumer is designed for and its fall-back behavior is outside the scope of the current specification (as should be noted under the office:version description).  [It would be great if we had a general mechanism to aid down-level consumers when an up-level producer relies on a breaking change between levels, but that is a different topic.]

I think we did entertain (2) as a prospect in writing this part of the specification and considering foreign elements, attributes, and attribute values.  I don't think we thought through the differentiation between cases (2-3) along with the difference between consumer-recognized and non-consumer-recognized situations -- I know I didn't -- especially for an attribute that is required in a given situation or according to the schema. 

 Ideally, these cases should only arise for attributes that are optional and either have defaults or do not.  I think we should rule out case (2), because there is no way to manage against collisions among foreign-value creating producers and future versions of the specification all using the same value in incompatible ways and we are tolerating a mess.  Case (3) seems tolerable, in that it provides a decentralized mechanism (via namespace prefixes presumably) to avoid collisions.  Producers that make use of Case (3) will, if well-designed, reflect anticipation of what consumers that do not recognize/support an extended value will have to do to be able to consume the document successfully. 

BIGGER ISSUE: We have not imposed any conformance or implementation-defined provisions on those cases where we allow extension of attribute values, usually by prefixed NCNames.  Basically, the specification makes such provisions admissable for Conforming OpenDocument Documents and allows a Conforming Consumer to non-support provisions in relatively arbitrary ways (in my reading).  

EDGE CASE: a producer may not be implemented by someone having authority over the namespace used for an extension, but I think that implementation-defined then means the producer implementation must still identify the authority and any provisions as part of satisfying the implementation-defined requirement.  

SOAP BOX: If we leave cases (3) implementation-dependent instead of implementation-defined, we have avoided confusion of extended attribute values but taken no stand on the need for interoperable definitions in Conforming OpenDocument Documents whatsoever.  I don't think we should be pre-endorsing private use as conforming.  Private use should not be anything we need to enshrine, it can just happen privately among grown-ups.  Responsible private users can also adopt private MIME types and protect interoperable OpenDocument usage from leakage of private documents into public places in many responsible ways.

> 3.17 Foreign Elements and Attributes - last two sentences of last paragraph in section - Unclear what is meant.
> ---------------------------------------------------------------------------------------------------------------
>                 Key: OFFICE-2759
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2759
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>            Reporter: Patrick Durusau
> The entire paragraph reads:
> "OpenDocument consumers should be able to parse and interpret documents that contain attribute values not defined by the OpenDocument schema. If an attribute which has such a non defined value has a default value, then a conforming consumer should assume that the attribute has this value. Otherwise, a conforming consumer should ignore the attribute."
> OK, fix non defined -> non-defined. 
> But, how does "parse and interpret documents that contain attributes values not defined by the OpenDocument schema" square with:
> 1) If attribute has a non-defined value, but has a default, use the default value, or
> 2) Ignore the attribute altogether. 
> Shouldn't this read:
> A conforming consumer that encounters an OpenDocument defined attribute that has a value that is not defined by OpenDocument, then it should:
> 1) If the attribute has a specified default value, use its default value, or
> 2) If the attribute does not have a specified default value, ignore the attribute.

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]