[odf-discuss] OOXML: The next step

[robert_weir at us.ibm.com]

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 
extensions."

An example of such documentation is what the GNU gcc compiler provides: 
http://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html

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 
"implementation-defined".

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.

-Rob

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. <
> http://lxr.go-oo.org/source/sw/sw/source/ui/uno/SwXDocumentSettings.cxx
> >.   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...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20080404/f30d56ab/attachment.htm