[odf-discuss] A bit more detailed explanation of the AFNOR
damon at corigo.com
Tue Sep 25 14:38:17 EDT 2007
Thanks for that Marbux.
On Wed, 26 Sep 2007 00:15:44 +0700, marbux <marbux at gmail.com> wrote:
> On 9/25/07, Lars Noodén <lars at umich.edu> wrote:
>> marbux wrote:
>> > ...
>> > I distinguish between DIS 29500 (Ecma 376) and Microsoft's OOXML.
>> > ...
>> I don't. They are, of course all different specs, but they share the
>> common characteristics that they are not fully published, have licensing
>> problems and are generally unimplementable by third parties. Sharing
>> these common characteristics is enough for me to lump them together.
> I agree so far as you go, but the fact that there is no reference editor
> an important issue at ISO. What's a standard without implementations
>> > ODF in its present condition is generally a non-starter for
>> > has no interop framework whatsoever and no interop conformance
>> > requiremements...
>> Please describe this in a sentence or two. I feel that I am being
>> obtuse in that I am unable to see such shortcomings.
> It would perhaps be most easily illustrated were you to compare the ODF
> conformance section with that of the W3C's Compound Document by Reference
> Framework's conformance section. <
> http://develop.opendocumentfellowship.org/spec/?page=1#1.5> and <
> http://www.w3.org/TR/2007/CR-CDR-20070718/#conformance>; e.g.:
>> User Agent Conformance
>> > 1.
>> > User agents must allow the child DOM to access the parent DOM.
>> > 2.
>> > User agents must allow the parent DOM to access any child DOM. The
>> > contentDocument attribute must represent the child document.
>> > 3.
>> > A conformant user agent of a superset profile specification must
>> > process subset profile content as if it were the superset profile
>> > That is only an excerpt; there is more to the section. But CDF has an
> interop framework and conformance requirements that require non-lossy
> round-tripping of documents between less and more featureful
> ODF does not. ODF has virtually no conformance requirements beyond
> validation and allows implementations to destroy metadata created by
> implementations, discretion that Sun has fully exploited in StarOffice
> OOo to ensure that its apps remain the center of the ODF universe.
> For the larger context of the component CDF specifications, see <
> http://www.w3.org/2004/CDF/>. Profiles are not the only way to enable and
> require interop; I raise CDF only as an example, one we are implementing.
>> ... ODF is non-interoperable without lossiness, even among ODF
>> > apps ...
>> That appears from where I sit to be shortcoming in the applications not
>> the format. Is there something else that we should know about there?
>> Random non-compliant tags, tagsets and metadata do not count.
> Application-level interop hacks work for the developers who have agreed
> implement it. But it is an approach that has never worked in the office
> productivity software market and is the worst choice for an open standard
> that many apps use. E.U. eGovernment, for example, was quite clear that
> wants the interop at the file format level, not at the application level.
> If you do not have an interop framework in the standard itself, what you
> wind up with is what we have now; documents that cannot be round-tripped
> among all ODF apps polluting the digital landscape and only OOo and
> StarOffice able to handle whatever one ODF app might throw at another ODF
> Likewise, if there is no framework for interop with non-ODF apps like MS
> Office, then only 1:1 feature mappings between MS Office and a given ODF
> can achieve lossless round-tripping of documents. And on the OOXML side
> the interop barrier, the lack of an interop framework and interop
> conformance requirements for OOXML means only MS Office can handle
> one OOXML app might throw at another OOXML app.
> Both ODF and OOXML are designed to cement in place the monopoly market
> of their respective market leaders by excluding non-lossy round trip
> both with each other and among apps that support the respective
> But I disagree strongly on one thing you said.
> Random non-compliant tags, tagsets and metadata *do* count when it comes
> non-lossy round-trip interop unless apps are required to preserve unknown
> metadata within the context of an interoperability framework that spells
> what to do with unknown metadata. E.g., the WordPerfect interop framework
> that wraps unrecognized metadata in <unknown> tags and rendering their
> contents as text, then removes the <unknown> tags if the document is
> in a later version that recognizes the metadata.
>> ... let alone with MS Office.
>> MS has todate never complied with an open format, specification or
>> protocol. MS will *NEVER* willingly give up an open format for MS
>> Office, given that its current claims to profitability are based
>> *entirely* on income from MS Office and MS Windows. Any full-fidelity
>> interoperability in the Office area, loosens vendor lock-in on Office,
>> which in turn loosens the lock-in on the desktop. Most nations agree
>> that would be a step towards a free market in computing and this would
>> be good.
> Agreed. But no one is working on it. The big vendors talk the interop
> but they don't walk the interop walk. And they proactively thwart
> Any interop with MS Office is going to have to come the same way
>> accessibility software comes: via third parties and *in spite of* the
>> best efforts of MS to stop it.
> Agreed. But a nearly identical problem exists with ODF.
> Our emphasis, and that of nations wishing to retain sovereignity, should
>> be to focus on ODF apps.
> Only if the ODF community suddenly develops some concern about what the
> foxes in the ODF henhouse have been doing. ODF will never be a threat to
> Microsoft's hegemony before it acquires an interop framework and interop
> conformance requirements. And never before the interop barrier with MS
> Office is cracked. We solved the Microsoft side of the problem but
> solve the ODF side of the problem.
> Clues: Sun Microsystems has the chairmanship of the ODF TC and a
> majority of
> the votes there. Sun has been conspicuously absent from the battle over
> 376, voted at INCITS for Ecma 376 approval at ISO, is developing Ecma 376
> native support for StarOffice/OOo with Novell and Microsoft, and both
> and Sun have agreements with Microsoft that provide patent protection for
> StarOffice and Novell proprietary OOo, but no patent protection for free
> and pay patent royalties to Microsoft for their proprietary office
> Microsoft's recent announcement that it is leaning on enterprise users of
> free OOo to pay royalties I think fills in the last large piece of the
> puzzle. <
> The set of agreements among Microsoft, Sun, and Novell and their
> overt acts raise the appearance that the players deliberately decided:
> *not* to supply what is a clear market requirement of high fidelity
> interoperability, [ii] to maintain competing and non-interoperable sets
> file formats; and [iii] to allocate the market for office suites, with
> non-conspirators to be driven from the market with Microsoft's software
> patent club. See Palmer v. BRG of Georgia, Inc., 498 U.S. 46, 50 (1990)
> (per curiam) ("[s]uch agreements are anticompetitive regardless of
> the parties split a market within which both do business or whether they
> merely reserve one market for one and another for the other"); NCAA v.
> of Regents of Univ. of Okla., 468 U.S. 85, 103 (1984) (a finding that a
> Sherman Act restraint of trade is unreasonable may be "based either (1)
> the nature or character of the contracts, or (2) on surrounding
> circumstances giving rise to the inference or presumption that they were
> intended to restrain trade and enhance prices"), quoting National
> Society of
> Professional Engineers v. United States, 435 U.S. 679, 692 (1978).
> And of course, a few other Linux distributors have joined since then,
> shipping Novell OOo with their distributions after having reached
> with Microsoft.
> Microsoft is not the only fox threatening the ODF henhouse. There are a
> couple of others already inside. Until ODF supporters wake up to that
> and deal with it effectively by getting an interop framework and
> requirements into ODF, both for interop among ODF apps and for interop
> MS Office, Microsoft keeps its vendor lock on the crucial enterprise
> The lessons of Massachusetts decision to approve OOXML, the successful
> opposition to ODF mandate legislation in five U.S. states by state IT
> officials, and the IDABC Open Document Exchange Formats 2007 Workshop
> pronouncement that neither ODF nor DIS 29500 are acceptable formats
> of interop warts have simply not registered with ODF advocates, who
> committed to a black hat/white hat evaluation of the issues. But it is a
> black hat/black hat situation instead.
> Open and interoperable are not synonyms. They are quite distinct
> ODF is open, but it is not a set of formats designed for interop. That
> requires an interop framework and interop conformance requirements. ODF
> neither and supplying the interop framework and conformance requirements
> only at the application level allows Sun to retain control over who is
> entitled to non-lossy round-trip interoperability with its products.
> ODF is not a Microsoft Office killer. It's not even a contender.
> Best regards,
> BUCK "MARBUX" MARTIN
> Director of Legal Affairs
> OpenDocument Foundation
> -- Universal Interop Now!
Damon Anderson, Managing Director
Corigo Việt Nam
391B Lý Thường Kiệt
P.9, Q. Tân Bình
Hồ Chí Minh City, Vietnam
Mobile: +84 90 834-2421
Email: damon at corigo.com
More information about the odf-discuss