OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

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


Subject: Re: [opendocument-users] Adding tables to ODP files


On Sat, Oct 31, 2009 at 5:31 AM,  <robert_weir@us.ibm.com> wrote:
> marbux <marbux@gmail.com> wrote on 10/31/2009 12:53:09 AM:
> That was the thought, that this Appendix would be beefed up and made into
> a profile standard or set of such standards. Obviously, getting consensus
> around what exactly constitutes the core functionality of a presentation
> will require additional substantial discussion.  It is something worth
> doing, I think.

Of critical importance if ODF is ever to become more than a standard
in name only. But it's been on the back burner for over seven years on
the ODF TC.

 But what was in the appendix was not accurate for any
> implementation, not even OpenOffice.  So it was removed.

Wasn't I just reading something by someone whose premise was that
implementations should conform to standards rather than the other way
around? Right, here it is.
<http://www.robweir.com/blog/2009/10/final-ooxml-update-part-iii.html>


> In the ODF Toolkit Union we need to think about what a profile like that
> would mean for ODFDOM.  As written today, ODFDOM allows everything
> supported by the ODF 1.2 schema, regardless of whether an implementation
> actually can render that particular combination of features.  So the
> programmer needs to know the limitations of whatever app they are
> targeting.

I don't have much interest in the app-to-app interop work in lieu of a
fully-specified standard. Standards development necessitates work on a
standard rather than diverting the focus of discussion to
application-level interoperability work. See
<http://www.universal-interop-council.org/glossary/term/2>.  You
recognized that yourself in regard to Ecma 376 OOXML:

"But the qualities of the format were set the day the standard was
approved by Ecma. The standard does not gain capabilities by Microsoft
writing code. Microsoft applications may gain capabilities, but the
standard is what it is, and is as compatible as it is going to get the
day it was standardized."

<http://www.robweir.com/blog/2007/03/compatibility-according-to-humpty.html>
(in comments section).

Why is the situation materially different when it's OASIS and ODF
under discussion? Is there a double standard at work here?

It would certainly be nice to have a mode where you set what
> your target app is, or pick a profile to maximize interoperability, and
> have the ODFDOM library adapt, but I'm not sure how that would work.  You
> can certainly code it so a runtime exception is called whenever a
> non-supported function is called.  But that sucks, because it will not
> find all bugs unless you have 100% path coverage in your test cases.  What
> you want is for any violations to be statically testable.  So that in
> practice means agreeing on a schema of specific subset of ODF that is
> applicable for a given use.

So let's send ODF 1.2 to JTC 1 without specifying "clearly and
unambiguously the conformity requirements that are essential to
achieve the interoerability," eh?

The problem is that we've had over seven years of the ODF TC treating
interop specs as a mere optional feature that can be delayed to a
later release of the specification. And users continue to be denied
the benefits of an open and fully-specified standard, such as the
ability to exchange documents with users of other conforming
implementations without danger of data loss.

When does the ODF TC get around to beginning its work on making the
ODF Interop Myth come true? E.g.,

"The merits of ODF have already been established by its wide industry
adoption. As noted above, numerous PPA vendors have implemented
support for it in their products both on Windows and on other
operating systems. Such widespread adoption is only possible because
ODF is fully disclosed and created to allow for document
interoperability by making it easy for various applications to
exchange documents with full fidelity, i.e., without any loss of data
or formatting of the document."

European Committee for Interoperable Systems, "Open Document Formats
As An Enabler of Interoperability: Comparison of the Oasis
Opendocument Format and Microsoft Office Open XML" (undated but file
stamped July 2, 2007), pg. 2, formerly available at
http://www.ecis.eu/inter/documents/ECIS_ODF_OOXML_comparison.pdf and
at http://osacademy.hosting.amaze.nl:8060/repository/resources/white-papers/ecis_paper_on_odf_ooxml_final.pdf/view.

Or closer to home:

"... We need to continue the fight, to ensure that users of document
editors, you and I, get the full interoperability benefits of ODF.
Other standards, like HTML, CSS, EcmaScript, etc., all went through
this phase. Now it is our turn.

"With an open standard, like ODF, I own my document. I choose what
application I use to author that document. But when I send that
document to you, or post it on my web site, I do so knowing that you
have the same right to choose as I had, and you may choose to use a
different application and a different platform than I used. That is
the power of ODF."

<http://www.robweir.com/blog/2009/05/battle-for-odf-interoperability.html>.

When do we users get that choice and power, Rob? ODF 11?

Best regards,

Paul

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>


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