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

[marbux]

On 5/29/07, Alex Hudson <alex at stratagia.co.uk> wrote:
>
> Marbux,
>
> marbux wrote:
> > >>>
> >
> > 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. In the
> > same vein an implementation which does include a particular option
> > MUST be prepared *to interoperate* with another implementation which
> > does not include the option (except, of course, for the feature the
> > option provides.)
> >
> > <<<
> >
> > "May" is used as the level of requirement for each discussion of the
> > foreign elements in Section 1.5, the conformance section. As I
> > interpret that definition of "may," StarOffice and OOo would be
> > required to preserve foreign elements and attributes enclosing content
> > needed for interoperability purposes even if those apps do not
> > themselves implement the foreign element and attribute features, e.g.,
> > for interoperability with the Foundation's MS Office plug-in. But the
> > definition would not require the preservation of such elements and
> > attributes or their contents to the extent that preservation was not
> > required for interoperability purposes.
>
> That's an incorrect interpretation. The word "interoperate" above is in
> the context of the implementation (of the standard). Under no
> interpretation of that RFC does any feature listed as "MAY" become an
> implementation requirement, and it doesn't mean "optional unless the
> feature is used for interoperability purposes" - since obviously the
> implementation has no idea whether or not the feature is being used in
> that manner or not, that cannot be the right interpretation since it
> effectively turns it into a MUST.


No, the definition clearly distinguishes between feature "support" and the
interoperability requirement. I have no problems with saying that the
foreign elements and attributes sections of the ODF spec were never
developed to the point they need to be. E.g., if nothing else, it doesn't
even require that applications use the same name for identifying foreign
elements and attributes. E.g., one app might use <foreign>, another <alien>,
another <unknown>, and another <burgerandfries>. The spec needs interop
generics for such purposes and to nail down whether the element or attribute
is required for interop purposes.

But the point you argue depends on the difficulty of preserving metadata
rather than on what the RFC 2119 definition of "MAY" actually requires.  I.e.,
your argument goes to a bug in the ODF spec, not to the meaning of the
definition.


What it means is: "You don't have to implement this. However, you MUST
> expect that other people will implement it, and deal with such
> situations". So, you cannot decide that ODF files with foreign metadata
> are not ODF and refuse to open them - however, you're also not under any
> obligation to implement the feature (it is "TRULY OPTIONAL").


Agreed, although that phrase, "deal with such situations" is substituted for
the actual requirement which is to interoperate with other conformant apps
that support the specification. But that still does not address the need of
preserving foreign elements and attributes (or non-foreign elements and
attributes) required for interoperability purposes.


> If you still don't see it, look at it the other way: RFC 2119 states "In
> the same vein an implementation which does include a particular option
> MUST be prepared to interoperate with another implementation which does
> not include the option". That means the Foundation's plugin MUST
> interoperate with OpenOffice.org, which does not include the feature. If
> it cannot, it is not implementing OpenDocument correctly.


You just went out the window there, I think.  "Interoperate" means two-way,
as in Interstate Highway or international border station. E.g., <
http://www.ntia.doc.gov/ntiahome/ntiageneral/ipv6/draft/draftglossary.htm>
IPv6 Discussion Draft - Glossary ("Interoperability:  The ability of
software and hardware on different machines from different vendors to
*share* data") (emphasis added); see also <
http://www.sutor.com/newsite/blog-open/?p=1260> (Bob Sutor of IBM,
distinguishing between *interoperability* and *intraoperability*).
Interoperability is not a one-way street.

What you argue in effect is that the Foundation's plug-in may allowably wrap
MSWord metadata that can't be mapped to ODF within foreign elements and
attributes, but that OOo when it receives the file is free to destroy the
metadata required for the document to be translated back to MS Word format
because OOo has scant support for the foreign elements and attributes. Now
the Foundation's plugin gets the file back from OOo and needs to open it in
MS Office, but the metadata needed to preserve the MS formatting is gone.

What's wrong with this picture? Under the ISO definition of "MAY," nothing.
Under the RFC 2119 definition, OOo has just violated its requirement to
interoperate with the Foundation plug-in/MS Word even though OOo does not
support the foreign element and attribute features.

I suspect you are working with a definition of interoperability that depends
on complete mapping of supported features, i.e., that the only way to
achieve interoperability is for two apps to use the same file format AND
implement precisely the same feature set. But the RFC 2119 definition
bluntly addresses the situation of less and more featureful applications
interoperability and says that both the more and less featureful
applications must interoperate.

That means you must get into the mechanics of how the more featureful and
the less featureful can interoperate. I know of only two methods: [i] agreed
interoperability profiles/subsets of a specification with compatibility
modes in the interoperable apps  (an artificially imposed feature match); or
[ii] preservation of elements and attributes required for interoperability
purposes by apps that do not support a given feature. I.e., OOo could send a
document to Google Docs for editing and GD would not destroy the elements
and attributes OOo needs to render the document faithfully. Google Docs may
be unable to render the document the same, but it would not destroy the
metadata and processing instructions needed by the more featureful OOo.

I think before you can make much headway, you will need to come up with a
way office productivity apps can interoperate that does not depend on either
of the methods described above. Both depend on preservation of metadata and
processing instructions.

You discuss the difficulties of interoperability but you seem to offer no
solution. I.e., what do you see as the mechanics of the RFC 21119 modal
MAY-MUST interoperability requirements? How do you see interoperability
happening without preservation of  the metadata and processing instructions
required for interoperability, particularly bearing in mind the fact that
the MUST clauses apply specifically to less featureful-more featureful
application interactions? And please think a bit about the practical
problems with round-tripping XSL transformations if such data is not
preserved at both ends.

The raw truth is that ODF is not designed for interoperability and has few
interoperability features. ODF's key interoperability requirements for
interop with non-conformant apps went out the window when the RFC 2119
definitions were toggled to ISO.

I wish I could get some help on this issue rather than flack. As the Sun and
IBM-backed ECIS website says:

>>>

Interoperability is a cornerstone of the ICT industry. In today's networked
ICT environments, devices do not function purely on their own, but must
interact with other programs and devices. A device that cannot interoperate
with the other products with which consumers expect it to interoperate *is
essentially worthless.* It is interoperability that drives competition on
the merits and innovation. The ability of different computer products to
interoperate allows consumers to choose among them. Because consumers can
choose among them, interoperable products must compete with one another, and
it is this competition that has driven innovation in the software industry.

<http://www.e-c-i-s.org/inter/index.html>

<<<

Right now, less featureful apps can't interoperate with OOo.
Right now OOo can't interoperate with less featureful apps.
 Right now, ODF apps can't interoperate with MS Office. Right now, ODF, in
the words of Sun and IBM's representative, "is essentially worthless."

The question is whether it will stay that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20070601/e6fec438/attachment-0001.htm