[odf-discuss] Fwd: Demo Flow for OpenXML Demo

[marbux]

If you create a word processing table with more than 63 columns the
translators/converters should fail. ODT supports 8012 columns,
WordProcessingML only 63. I'm not sure how Novell OOo handles that issue,
but you might try creating a table in ODT that has more than 63 columns,
then ask Microsoft to convert the document from ODT to WordProcessingML
using Novell OOo or other translators/converters and then display it in
Word. There would have to be an error message and/or loss of data somewhere
along the line.

A plausible document might be a vacation/days off scheduling table, A
366-day 2008 Julian calendar with one date per column should do the trick
along with additional columns for staff member names, their contact
information, job titles, and departments.

That would produce some plausibly useful sorts by table row. I've seen such
tables in use by some fairly large organizations that have embraced
role-based management.

The excuse from Microsoft will be that such tasks are better performed using
a spreadsheet or relational database application. But that excuse blinks
past the fact that far more users are familiar with word processing tables
than have taken the deep dive into full-blown spreadsheet apps or RDBMS.

British Standards Institute in its comments requested that Ecma agree to
change DIS-29500 WordprocessingML from a 63-column maximum in word
processing tables to 8012 columns, in order to harmonize DIS-29500 with
ISO/IEC:26300-2006. Ecma declined to do so, arguing that the JTC 1 should
proceed before any harmonization work is initiated.

Changing topics somewhat, it is misleading in the extreme for Microsoft to
portray the Mindjet application as a model of interoperability enabled by
OOXML. As Microsoft OOXML evangelist Doug Mahugh makes clear in this
article, <http://blogs.msdn.com/dmahugh/archive/2006/09/16/758090.aspx>, the
interop established using Mindjet is highly dependent on features of
Microsoft Officer that are not specified in OOXML, e.g., VBA macros, custom
schemas, icons, custom semantics, custom metadata, and the actual definition
of the mindmap itself.

This is application-level interoperability, not standards-based
interoperability. It only works when exchanging data with one vendor's
implementation. The Mahugh article, viewed most charitably, is a compelling
admission that OOXML is rather massively underspecified in its
interoperability aspects.

The means the Mindjet developers were forced to use to establish
interoperability with MS Word using OOXML as the container testify
irrebuttably that OOXML does not specify a "standardised interface" for
interoperability purposes and "conformity requirements essential to achieve
the interoperability" as required by ISO/IEC JTC 1 Directives, 5th ed., v.
3.0, p. 145 (PDF), <http://www.jtc1sc34.org/repository/0856rev.pdf>. Also
note the requirement that the interoperability be "demonstrable." See also
ibid, pg. 11:

These Directives shall be complied with in all respects and no deviations
can be made without the consent of the Secretaries-General.

...

A purpose of IT standardization is to ensure that products available in the
marketplace have characteristics of interoperability, portability and
cultural and linguistic adaptability. Therefore, standards which are
developed *shall*  reflect the requirements of the following Common
Strategic Characteristics:


   - Interoperability;
   - Portability;
   - Cultural and linguistic adaptability.

To the best of my knowledge, the Secretaries-General of ISO and IEC have not
given their consent for DIS-29500 to be exempted from those requirements.
Although one might torture language on  Directives page 145 granting JTC 1
authority to "clarify" applicability of interoperability requirements for
particular standards, to do so requires reading the unambiguous requirement
of  consent by the Secretaries-General on page 11 as a nullity. "Clarify"
and "consent" are not synonyms.  E.g., compare  <
http://wordnet.princeton.edu/perl/webwn?s=clarify> with  <
http://wordnet.princeton.edu/perl/webwn?s=consent>.

The power to "clarify" what "should" be is not the power to "consent" to
what will be. Moreover, even were one to ignore such distinctions and decide
that pg. 145 nullifies the consent requirement, that does not relieve JTC 1
of the various "responsibilities" identified on page 145.  JTC 1 would still
be required to make findings that fulfill the responsibilities relevant to
interoperability identified on that page.

The importance here is two-fold: [i] JTC 1 lacks discretion to produce a
standard that does not fulfill the interoperability requirements on page 145
without first receiving consent from the Secretaries-General or
alternatively, without first making certain findings as to interoperability;
and [ii] NBs have a right to lodge an appeal with the Secretariats from
*any* action or inaction by JTC 1 that in the NB's view violates the
Directives or is not in the best interests of international trade and
commerce. JTC 1 Directives, supra, section 11, pp. 52-53.

JTC 1 completing a ballot resolution meeting without fulfilling its
responsibilities as to interoperability is, in my opinion, suitable grounds
for appeal, providing a request has been clearly made that JTC 1
satisfactorily address the Directives' interoperability requirements at the
BRM.

I quote and emphasize relevant extracts from the Directives below:

11.1.2 A P-member of JTC 1 or an SC may appeal *against any action, or
inaction, on the part of JTC 1* or an SC *when the P-member considers that
such action or inaction is:*

• *Not in accordance with these directives; or*

• *Not in the best interests of international trade and commerce*, or such
public factors as safety, health or
environment.

11.1.3 Matters under appeal may be either technical or administrative in
nature. *Appeals on decisions*
*concerning* NPs, CDs and *DISs* *are only eligible for consideration if:*

*• Questions of principle are involved;*

*• The contents of a draft may be detrimental to the reputation of IEC or
ISO; or*

• The point giving rise to objection was not known to JTC 1 or SC during
earlier discussions.

The use of the disjunctive "or" in two critical places is called to the
reader's attention.

Filing such an appeal immediately after the BRM is over would appear to
provide a fallback method for invalidating a final ballot tally that adopts
DIS-29500.

There are two levels of appeal that may be taken, with the second being
decided by the Secretaries-General themselves.

If any NB member is interested in pursuing this, please feel free to contact
me for further information. There is a wealth of law reading on the subject
of interoperability, not the least of which is Microsoft's recent loss in
the European Community Court of First Instance, which rejected Microsoft's
argument that "interoperability" has a 1-way meaning and required that the
level of specificity  in Microsoft's disclosure of communications protocol
specifications must be sufficient to enable the same quality of
interoperability that Microsoft achieves among its own software products.

The JTC 1 definition of interoperability differs from the definition at
issue in the Microsoft case only by being more specific, e.g., by requiring
specification of a "standardised interface" for interoperability purposes.
Both definitions share the critical "mutual use" phrase that compelled a
conclusion that "interoperability" has a 2-way meaning.

It could hardly be argued with a straight face that the compatibility
framework specified in DIS-29500 Part 5 is a "standardised interface"
sufficiently specified for 2-way interoperability of the quality Microsoft
achieves, e.g., between MS Office and Sharepoint Server.

Consider, for example, just this single sentence from the framework's
Overview, pg. 8:

A markup producer can produce markup documents that exploit new features
defined by versions and extensions, yet remain interoperable with markup
consumers thats [sic] are unaware of those versions and extensions.

If anyone can parse that sentence in a technically sound manner that defines
interoperability as 2-way and of the same quality achieved by Microsoft
among its own applications, I'm all ears. :-) The sad part is that the
sentence is descriptive of the framework specified in Part 2. It is a
standardised (but poorly specified) interface for 1-way compatibility, not
for 2-way interoperability. There is a reason that the European Commission's
DG Competition is knocking on Microsoft's door to talk about OOXML and
Microsoft's efforts to achieve international standard status for it.

Best regards,

Paul Merrell ("Marbux")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20080217/6e6e7835/attachment-0001.htm