[odf-discuss] What is actually necessary and found only in OpenXML?

[Daniel]

marbux wrote:
>> 1. Exactly where does it say that applications are required to preserve
>> foreign elements? Be concise and specific.
> 
> The difference is in the switch of definitions of keywords for levels of
> requirements between ODF 1.0 and 1.1, a switch in the definition of "may."

1) I should note that the change from RFC 2119 to ISO/IEC Directives 
terminology was a specific request from ISO while they were deciding on 
whether to grant ISO status to OpenDocument. The tone of your email, to 
me, seems to suggest some attempt to weaken ODF for Sun's convenience.

2) Second, the use of "may" in RFC 2110 and the ISO/IEC Directives is 
intended to be equivalent. In particular, I strongly disagree with your 
interpretation of "may":

> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is truly
> optional.  One vendor may choose to include the item because a particular
> marketplace requires it or because the vendor feels that it enhances the
> product while another vendor may omit the same item. An implementation 
> which does not include a particular option MUST be prepared *to interoperate* 
> with another implementation which does include the option, though perhaps with
> reduced functionality.

"interoperate" does NOT mean "it must be able to preserve unknown 
foreign elements that are not part of this specification", that's crazy 
(I gave an example in my previous email). In the context of ODF, the 
implementation must be able to read documents that contain foreign 
elements provided that they follow the rules in section 1.5, which among 
other things, says that if you remove all the non-ODF tags the result 
must be a valid ODF document.

I think you are making a lot of unreasonable leaps in logic. You 
over-stretch any reasonable interpretation of "must be prepared to 
interoperate with programs that include unknown elements" and then make 
another jump at implying that the change to ISO terminology was 
unreasonable (in truth, it was a requirement and quite a minor one).

I also get the feeling from your emails that you believe this was a Sun 
initiative and that they were trying to weaken ODF's interoperability. I 
hope everyone on this list now realizes that this couldn't be further 
from the truth. The change from RFC to ISO terms was a request from ISO, 
and the two sets of terms are intended to be equivalent. In both cases, 
the word "may" means that xyz is permitted but is not required and 
therefore no application should require that other implementations do 
xyz or fail to do xyz.

> For that reason, I have asked that the entire specification be reviewed to
> determine if there are any other sections where the toggled definition of
> "may" has worked its mischief. No one on the TC responded to my discussion
> of the problem the switch created in the conformance section.

I disagree with your perceived problem and I do not plan to respond to 
it on the TC list. Your expectation that applications be required to 
preserve all foreign elements does not look reasonable based on a 
cursory evaluation. There may be an additional restriction that makes 
the request more reasonable (e.g. "preserve elements in <meta> tags").

> I do not suggest that all foreign elements and attributes and their 
> contents
> should be preserved. But those necessary for interoperability purposes
> should be.

And how the heck is an implementation supposed to know whether or not 
the tag foo:baz="345" is important for interoperability with some 
application that Bob wrote last night?

I also disagree with the notion that inserting unknown elements not 
defined in the spec is a good way to achieve "interoperability" with 
anyone. Unknown elements do *nothin* for interoperability, we've had 
this discussion before. At best they serve for round-tripping. Let's get 
these definitions clear:

* Interoperability:  BobOffice and AliceOffice can successfully read 
each other's documents.

* Round tripping: If Bob sends a file to Alice who edits it and sends it 
back to Bob, Bob doesn't perceive any data loss.

If BobOffice adds a foreign element that AliceOffice doesn't understand 
there is a loss in interoperability, and asking AliceOffice to preserve 
it does not improve interoperability.


> Marbux says:
>> >> That is a significant barrier to interoperability ...
>>
>> That's like saying that OOo's inability to read .doc files perfectly is
>> a significant barrier to interoperability.
> 
> Both are significant barriers to interoperability,

And neither can be blamed on OOo.


> Lossy interop among ODF applications is another bug, e.g., 
> between OOWriter and Google Docs.

If Google Docs writes a document with foreign elements not defined in 
the ODF spec, we can't blame OOoWriter for not being able to read them. 
It is Google Docs' responsibility to use tags and attributes defined in 
the spec.

The whole idea of a standard is "if we all agree to use the same 
language then we'll understand each other". If I make up new words you 
wouldn't blame yourself for not understanding them. That would be 
schündégölych, because then byxoüngich would wexytick yuztilch.

> Thus far, the TC has been unwilling to tackle either of those bugs in ODF
> 1.2. I am sure Microsoft appreciates that. :-)

I'm sure Microsoft would be delighted to hear that they can insert a 
binary .doc file inside <office:document> tags, call it ODF, and blame 
OOo if it can't round-trip perfectly.

Daniel.