[OpenISO] OOXML goal statement

[Seth Johnson]

I think the acronym OOXML can be targetted all by itself -- just
recommend that it be changed to read well.  Acknowledge that there
might be an attempt not to take any shine off of Open Office, but
having the modifier "Open" second is just klunky, and the only way it
scans with any reasonability is if "Office" is meant to refer to some
particular product -- as in "Open XML" for some product called
"Office."

But if "Office" in "Office Open XML" is meant as a generic modifier,
as in "Open XML [format] for Office [applications]" then at the least
the acronym should be changed to OAOXML.  Or OXMLOA.

Add to this the fact that portions of the "standard" directly present
it as geared toward a specific product from a specific vendor.

I'd just join in with anybody who wanted to pick on this very
reasonable quibble, and actually begin a discourse that would drive
toward cleaning up and streamlining it so it's actually something that
would merit the term "standard."

It may seem a minor point, but it actually is a point you can stand
on, and can use as a key for redirecting the discourse.


Seth Johnson


-- 

I reserve no rights restricting copying, modification or distribution
of this incidentally recorded communication.  Original authorship
should be attributed reasonably, but only so far as such an
expectation might hold for usual practice in ordinary social discourse
to which one holds no claim of exclusive rights.


Janet Hawtin wrote:
> 
> Yes. It is hard to see how the standards bodies can process something
> like this with a straight face or with an appreciation of what it
> means for their brand.
> j
> 
> On Dec 31, 2007 8:49 PM, Norbert Bollow <nb at bollow.ch> wrote:
> > Someone has posted a textual contribution for the "problem report"
> > document as an "Anonymous Coward" /. comment:
> > http://slashdot.org/comments.pl?sid=400652&threshold=1&commentsort=0&mode=thread&cid=21848810
> >
> > --snip------------------------------------------------------------
> >
> > I won't join your site, but I have a problem with the Introduction and its restatement later in the Goals section. Feel free to quote, copy, take credit for, or in any other way use, disuse, or fail to use, the following as it is now in the public domain.
> >
> >     Introduction
> >     The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and
> >     platforms, fostering interoperability across office productivity applications and line-of-business systems, as well
> >     as to support and strengthen document archival and preservation, all in a way that is fully compatible with the
> >     large existing investments in Microsoft Office documents.
> >
> >
> >
> > The stated goal is to create a standard compatible with a single vendor's single product. I'd say that alone disqualifies it as a standard. Even if they change the wording, they would have to explain why they included this verbiage in the first place. Note the rewording under the Goal:
> >
> >     2.1 Goal
> >     The goal of this clause is to define conformance, and to provide interoperability guidelines in a way that fosters
> >     broad and innovative use of the Office Open XML file format, while maximizing interoperability and preserving
> >     investment in existing files and applications (4). By meeting this goal, this Standard benefits the following
> >     audiences:
> >
> >         * Developers that design, implement, or maintain Office Open XML applications.
> >         * Developers that interact programmatically with Office Open XML applications.
> >         * Governmental or commercial entities that procure Office Open XML applications.
> >         * Testing organizations that verify conformance of specific Office Open XML applications to this
> >           Standard. (Note that this Standard does not include a test suite.)
> >         * Educators and authors who teach about Office Open XML applications.
> >
> >
> >
> > Two things. The goal mentioned in the introduction is reworded from "existing investments in Microsoft Office documents" to "existing files and applications", which sounds more interoperable but it really isn't. Also, by meeting this goal, this standard benefits.... drumroll... people who are forced to use Open XML. This goal could be achieved simply by using the standard proposal as documentation of the file format, and forgo the whole OOXML standard because its stated goal has already been achieved.
> >
> > To summarize: unless there are other unstated (hidden) goals, which most likely would benefit Microsoft, there is no outside benefit to having this be a standard. If there are other, more beneficial goals, they should be discovered and listed.
> >
> > If the goal truly is to "support and strengthen document archival and preservation", it would make more sense not to just deprecate AutoSpaceLikeWord95 or the other black box definitions, but to actually create definitions which specify the exact behavior, as has been noted elsewhere. Otherwise the standard does not meet its own stated goal. And an added benefit would be to wrap this spacing definition in some sort of grouping to show that these measurements and behaviors are all one entity - in other words, if you remove or ignore this spacing information, you should do it as a group, not just ignoring one part of it because your application does not implement that section. There is simply no way to "support and strengthen document archival and preservation" by leaving such definitions undefined. That is exactly the opposite of its stated goal.
> >
> > One other part that bothers me is "in a way that fosters broad and innovative use of the Office Open XML file format". Not for convenience or clarity, but to make more people use the Microsoft format. In other words lock-in, or the transition between embrace and extend.
> >
> > The only reason that ODF cannot be a direct replacement for OOXML, and why ODF cannot serve to achieve the stated goals for OOXML, is that ODF does not support some of the features of Office documents. This could easily be rectified of course, more easily than having two standards, one of which is a single-vendor, single-product compatibility layer.
> > http://odf-converter.sourceforge.net/features.html [sourceforge.net]
> >
> > I will sign this as "b4dc0d3r" if you prefer to make attribution but that is extremely unspecific, intentionally so.