[odf-discuss] OOXML: The next step
robert_weir at us.ibm.com
robert_weir at us.ibm.com
Fri Apr 4 10:56:19 EDT 2008
You can certainly define conformance in a way that accounts for
extensions. For example, ISO C Programming Language (ISO/IEC 9899:1999)
has a statement in their conformance clause that reads:
"An implementation shall be accompanied by a document that defines all
implementation-defined and locale-specific characteristics and all
An example of such documentation is what the GNU gcc compiler provides:
I'm going to push for a statement like that to be added to ODF 1.2. The
phrase "implementation-defined" should not be a meaningless statement. You
need that conformance requirement to put teeth behind the phrase
I don't think you'll ever eliminate vendor extensions. Customers like
them. It is the way applications evolve their functionality. Today's
vendor extension may be tomorrow's ODF 1.3 feature. But we do need a way
to reduce the embrace and extend risk.
In my opinion the big risk is not extensions. If you use extensions you
know you will not be interoperable. The bigger problem is divergent
behavior among implementations. That is what the big problem with
Internet Explorer has been. It isn't their extensions to HTML. We ended
up with the mess of quirks mode versus standards mode because of
divergent interpretations (or bugs) in the core documented parts of CSS2.
So I think there is value in having an assessment procedure (a test suite)
for the core parts of ODF, just to ensure we don't end up in the mess we
have with HTML. It is still early enough to prevent that.
marbux <marbux at gmail.com> wrote on 04/03/2008 10:18:51 AM:
> It's impossible to create a valid conformity assessment procedure
> for OOXML, or for ODF for that matter. Both standards allow
> implementations using app- and vendor-specific extensions the status
> of conformance. E.g., OOo uses some 150 app-specific extensions to
> ODF. For example, see lines 169-211 on this OOo source code page. <
> >. OOXML (at least the pre-vote version submitted by Ecma)
> includes 573 "future" extension points identified in Part 4 (the
> schema) by the exLst attribute that have no specifications for
> functionality whatsoever.
> Ecma 376 literally had zero conformance requirements. Its
> conformance section (in Part 1) was simply a lengthy essay on why
> conformance requirements were undesirable. I understand from a
> couple of press reports that ISO requirements keywords were added to
> the Ecma spec at the BRM, but we won't be able to assess the impact
> of that change until we see the completed spec. But judging from the
> Ecma Responses to NB comments and the fact that very few other
> changes were made to the spec, I strongly suspect that in terms of
> being able to develop a conformity assessment procedure, the
> situation is unchanged.
> Short story here: push for a conformity assessment procedure for
> OOXML and you'll immediately be pushed back to provide a link to the
> conformity assessment procedure is for ODF. You'll be left flat-
> footed, because there is none.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the odf-discuss