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: Re: [office] Re: [office-metadata] Suggested Changes on the Metadata proposal




On 7/1/07, robert_weir@us.ibm.com <robert_weir@us.ibm.com> wrote:

I think you're reading too much into the IETF's definition of MAY.  It explicitly says that a vendor is permitted to omit the item, though it must accommodate itself and degrade functionality as necessary.  What is not permitted is that the application utterly crash when presented with an item it does not understand.   At least that is the way it works for the IETF standards I'm familiar with.

We live in a world of ambiguities. :-) I can't testify to customary practice, but what you describe is hard to square with the specific language of the definition. E.g., it's hard for me to equate "not crashing" with "interoperate."
 

Although intuitively we want to say, "Preserve metadata unless the user explicitly intended otherwise," I don't see how to express this in standards terms.  We can't have a conformance depend on "user intent".  And reference to a user doesn't help. Documents can be processed by automation, and I think we would equally be unhappy if metadata were arbitrarily stripped there.  In any case, I think we need to work along the lines of "shall be capable of" or "shall allow at least one mode of operation where" or something like that.   That would be testable.  

The XML 1.0 standard takes this approach, referring back to the RFC 2119 definition of "may" and "optional:"
at user option

[Definition: Conforming software MAY or MUST (depending on the modal verb in the sentence) behave as described; if it does, it MUST provide users a means to enable or disable the behavior described.]

<http://www.w3.org/TR/REC-xml/#sec-terminology>. The "at user option" phrase is heavily used in that specification.
 

So taking a first cut at some language for the conformance section (not a proposal, just for discussio purposes), we might do something like this:

Conformant applications MAY preserve meta information and processing instructions, including but not limited to foreign elements and attributes but SHALL do so to the extent needed for lossless round trip interoperability with all other conformant applications. However, the application must provide users with the means to disable the preservation of such information. This section shall not be interpreted as meaning that an application or routine designed expressly to strip meta information at the users' option.


You suggested that a devious implementation might makes this mode of operation hard to find in order to hurt interoperability.   But then I could also suggest a devious user who arbitrarily deletes metadata in order to hurt interoperabiity.  I'm not sure a document format standard can prevent either.  

Me either. But a standard can deny such an app the right to be branded as conformant, which should result in ineligibilty for software procurement tenders. And my Easter Egg example was intended as an extreme example, a caricature if you will of MS Office setting MOOXML as the default file save format. How many users will ever bother to change that setting? And how many MOOXML files wind up in circulation because of it.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]