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

[marbux]

I should have added that it might be comedic to see how well the
translators/converters handle a Mindjet file. :-) It should tell the OOXML
interop story fairly well.

On Feb 17, 2008 4:19 AM, marbux <marbux at gmail.com> wrote:

>
>
> 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/00f43c7b/attachment-0001.html