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

[Daniel]

Huh?

I'm not aware of any strawman or sweeping generalities when I argued 
that the requirement you wish to add to the ODF spec is unachievable by 
implementors. I believe that my position is very sound and I do expect 
you to take it seriously. I'm sad that you feel insulted, but I will not 
pretend that I agree with your reading of RFC 2119 and I will not 
pretend that the change you desire for the ODF spec is a reasonable 
requirement; I believe that it is unachievable as stated, and gave examples.

Others in the list are free to judge the weight of my argument and yours.

Kind regards,
Daniel.

marbux wrote:
> Daniel,  I am not going to respond to your post quoted below. I am too busy
> right now to deal with swatting down your straw man argumentation, to
> respond to your unsupportable sweeping generalities, to respond to silly
> arguments unsupported by citations, and to critique your decision to not
> hold yourself to the same standard of specificity and conciseness you
> *ordered* me to use. Respect is a two-way street. Please do not insult my
> intelligence by asking me to take your post seriously.
> 
> Best regards,
> 
> Marbux (who would rather be your friend than your sparring partner)
> 
> 
> On 5/28/07, Daniel <daniel.carrera at zmsl.com> wrote:
>>
>> 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.
>> _______________________________________________
>> odf-discuss mailing list
>> odf-discuss at opendocumentfellowship.org
>> http://lists.opendocumentfellowship.org/mailman/listinfo/odf-discuss
>>
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> odf-discuss mailing list
> odf-discuss at opendocumentfellowship.org
> http://lists.opendocumentfellowship.org/mailman/listinfo/odf-discuss