[odf-discuss] OOXML: The next step

[robert_weir at us.ibm.com]

> I will close by asking whether you see a benefit to be gained in 
> continuing this conversation? My perception of your position (and 
> please tell me if I have this wrong) is that ODF 1.2 under your 
> leadership: [i] will grant conformant status to vendor-specific 
> extensions; [ii] will grant conformant status to editors that do not
> support the complete schema for a given application type; [iii] will
> not clearly and unambiguously specify the conformity requirements 
> essential to achieve the interoperability; [iv] will not require 
> that implementations claiming conformity demonstrate the 
> interoperability; and [v] will not specify all characteristics of 
> the ODF file formats in mandatory terms. 
>

A standard does not grant conformance.  That is not the job of an SDO like 
OASIS or of JTC1 or ISO.  We do not evaluate implementations, rate them, 
score them, accredit them, label them as conformant or not.  That is not 
what a standard does.  What you are talking about here is a conformity 
assessment methodology, of which the standard is one part, but which also 
typically comprises other documents, test suites, etc., and which is 
administered by a 3rd party. 

Note as well that the primary conformance class for ODF is that of a 
conformant document.  We can define a conformant document without regard 
to any software application.  You won't find an analogue to this in any of 
your WTO text talking about physical standards, but this is a reality of 
IT standards.  Similarly, we can have a standard that describes the codec 
for a DVD, while not describing the physical requirements of the disc, or 
without describing the rutime requirements of the player.  Why?  Because 
the overall ecosystem around DVD includes encoders, duplicators and many 
other such functions that are invoked in production of DVD's before they 
ever reach the consumer. 

In other words, ODF is a document interchange format, not a standard for a 
word processor.

Similarly, for ODF there are UI-less server-based applications that scan, 
index, generate reports from, convert, pack/unpack into a relational 
database, etc. ODF documents without ever needing to display or render an 
ODF document.  For them, the detailed description of the ODF schema given 
in the standard is complete and unambiguous, described in a formal schema 
definition language, RELAX NG. 

I think you are still missing the point on demonstrable versus 
demonstrated.  There is nothing in JTC1 that requires a pre-existing 
implementation of a standard, let alone two different implementations that 
can demonstrate interoperability.  Certainly this is a best practice.  But 
it isn't a requirement.  So JTC1 cannot then require an actual 
demonstration of interoperability.   Demonstrable interoperability is 
based on whether the requirements of the standard are testable or not.  If 
I say in the standard, "The widget shall be big" then this is not 
testable.  But if I say 'The widget shall be 30cm +/- 1%", then this is 
testable.  Where conformity is defined in terms of testable requirements, 
then interoperability is demonstrable.  Note that with ODF, even vendor 
extensions have requirements, such as being in a different namespace, and 
these requirements are testable.

I'm not sure I see the applicability of an asbestos case to ODF, but 
certainly ODF has and will continue to have optional as well as mandatory 
parts.  For example, it would be silly of us to require that AbiWord 
implement spreadsheet functionality as well as the word processor 
functionality.  And we should be happy to see an ODF to DAISY talking book 
convertor be called conformant even if it doesn't display presentation 
animations visually in the way that OpenOffice does. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20080415/8398d6fc/attachment.htm