The EU Prosecutors are Wrong. on 30 Jan 2007

[Frederic Parrenin]

Miguel,

I think you missed an important issue in your long post: OOXML is an
open format, not an open standard.
With ODF, the format is decided by a formal group which is not tied to
a particular company. This is not the case with OOXML.
It makes for me a big difference. At any time, microsoft can change
the standard and implement it in its own office suite to have an
advantage with respect to competitive products. The standard is not
driven by the users, it is driven by the interests of a particular
company.

[Miguel de Icaza]

Hello,

> I think you missed an important issue in your long post: OOXML is an
> open format, not an open standard.

OOXML is an open standard as well, at least per Wikipedia's and the EU
definition:

http://en.wikipedia.org/wiki/Open_standard

I know, its Wikipedia.

> With ODF, the format is decided by a formal group which is not tied to
> a particular company. This is not the case with OOXML.
> It makes for me a big difference. At any time, microsoft can change
> the standard and implement it in its own office suite to have an
> advantage with respect to competitive products. The standard is not
> driven by the users, it is driven by the interests of a particular
> company.

Well, experts, academics, companies and guests of any of the previous
three can participate in the ECMA process.

Am not sure that once a standard becomes part of ISO anyone can just
contribute. Most likely only the members of ISO. So its not the
most open of the standard bodies. For users to make changes to the
standard they would have to go through some influential bodies, they
cant just "contribute" to ISO.

It is true that people can modify and built upon a standard, this is
not limited to Microsoft. Anyone could improve and extend the format
to include more stuff (in OOXML there is a whole section that
discusses how third parties can augment the format without breaking
it).

Miguel.

[paco.m...@gmail.com]

Very elaborate analysis of the topic. Thanks Miguel.

[gabrie...@gmail.com]

Hi Miguel,

I think your criticism of ODF's lack of spreadsheet/formula specifics
might have been historically accurate, but the OpenFormula
specification (http://www.oasis-open.org/committees/tc_home.php?
wg_abbrev=office-formula) appears to fill this gap very well: 371
pages incorporating the best features from OpenOffice.org and other
apps. I think it makes a lot of sense to have the formula
specification be separate from ODF so it can be reused more easily.

I also think OOXML's inclusion of un-documented compatibility shims
looks nuts - requiring full-implementors to have intimate knowledge of
the inner workings of Word Perfect and Word 95.

Thanks,

Gabriel

[Miguel de Icaza]

Hello,

> I think your criticism of ODF's lack of spreadsheet/formula specifics
> might have been historically accurate, but the OpenFormula
> specification (http://www.oasis-open.org/committees/tc_home.php?
> wg_abbrev=office-formula) appears to fill this gap very well: 371
> pages incorporating the best features from OpenOffice.org and other
> apps. I think it makes a lot of sense to have the formula
> specification be separate from ODF so it can be reused more easily.

I was not actually trying to criticize ODF, am too pragmatic and am
willing to give the ODF group the benefit of the doubt. They
probably had their reasons, deadlines to meet and processes to follow
that made that hard.

What matters here is that ODF is not a complete standard and that some
of the arguments put out by ODF proponents are bogus. Arguments like
"It would duplicate an existing standard", sure an incomplete,
existing standard.

Finally, OpenFormula is not a standard, it is a great effort, but it
is not part of ODF at this point.

> I also think OOXML's inclusion of un-documented compatibility shims
> looks nuts - requiring full-implementors to have intimate knowledge of
> the inner workings of Word Perfect and Word 95.

You are not required to implement them, you can ignore it safely.

Lets consider Mono: the fact that something is documented does not
mean that we have to implement it or that we will implement it.

We tend to do so, but having a usable product does not mean that you
have to have 100% coverage.

Miguel.

[Andrew Arnott]

Miguel, you have a knack for terrific constructive criticism of the
community you serve. You are a credit to the open source community.
Keep up the great work.

[p.v...@gmail.com]

Miguel,

Don't forget that for ODF to become a true standard, it needs multiple
implementations.

I'm irritated by some OpenOffice developers bragging how OOo is the
only product which completely supports ODF.

That's bad for ODF. In order to fully take off, ODF needs multiple
implementations.

If we have only one program implementing it completely, than we are no
different from Microsoft.

[albert.Z...@gmail.com]

Allthough a lot of critisism is about OOXML not using ISO 8601 dates
it seems that this is mainly the case in spreadsheets cells where
OOXML uses either the date1900 or date1904 formats.
These are very simple formats that represent dates in a numeric form.
I am not exactly sure how ODF support dates in spreadsheets but it is
very unlikely that they will support ISO 8601 without restrictions.
The ISO date standard is way to complex for use in spreadsheets.
Even w3c standards in general only use a simplefied version of ISO
8601 which is actually simular to what OOXML does with dates in OOXML
that are not in the spreadsheet cells. As far as I can tell, looking
at the spec OOXML, on date fields uses the standard validation from
the w3c XML schema which is as I said only a subset of ISO 8601.

[bda...@gmail.com]

On Jan 30, 6:31 pm, "Miguel de Icaza" <miguel.de.ic...@gmail.com>
wrote:

...

> Well, experts, academics, companies and guests of any of the previous
> three can participate in the ECMA process.

Really? I'm an expert in bibliographic software and standards; a user
wtih a scratch-my-own-itch need to have good, interperable, citation
support in word-processing software.

I submitted a detailed list of suggested changes for the citation
support in OOXML. Effectively all of them were rejected, and the only
reason I could discern from the response was that the MS project team
implementing the new functionality in Word 2007 couldn't be bothered
to make any code changes. It was very clear that the spec was driven
by MS's internal needs.

Meanwhille, at the ODF TC, I co-wrote the new citation field and am
heavily involved in the metadata SC.

Bruce

[Miguel de Icaza]

Hello,

> > Well, experts, academics, companies and guests of any of the previous
> > three can participate in the ECMA process.
>
> Really? I'm an expert in bibliographic software and standards; a user
> wtih a scratch-my-own-itch need to have good, interperable, citation
> support in word-processing software.

Yes, really.

Before we were acquired by Ximian we participated as IBM guests and
later as invited experts in ECMA TC39 TG2 and TG3.

> I submitted a detailed list of suggested changes for the citation
> support in OOXML. Effectively all of them were rejected, and the only
> reason I could discern from the response was that the MS project team
> implementing the new functionality in Word 2007 couldn't be bothered
> to make any code changes. It was very clear that the spec was driven
> by MS's internal needs.
>
> Meanwhille, at the ODF TC, I co-wrote the new citation field and am
> heavily involved in the metadata SC.

ECMA standardizes existing practice, which means that it creates a
specification out of a working product. The specification is designed
to allow interoperability. This is done by documenting the input/
output.

In a few occasions changes are made to the specification and to the
product, I do not know to what extent the folks in ECMA TC45
influenced the final result of the product, and its worth asking those
involved.

But let me ask you something: once you got the specification for the
new citation field, how long did it take to actually get that into a
working product. Which products currently support it? Has
OpenOffice been modified to support it?

The best way of influencing something like OOXML is to have a new
implementation, and influence the new iteration of the format.

Miguel

[stephane....@gmail.com]

Miguel,

I am an independent vendor and sell the most advanced third-party
Excel 2007 generator to this date. This with a number of years reverse
engineering BIFF records, OLE, ... (http://xlsgen.arstdesign.com)

The specs you are willing to give the benefit of the doubt, namely
OOXML, is so bad and so lame that I had to develop a diffing tool in
order to make progress in my development of said product. (http://
diffopc.arstdesign.com)

You won't convince me that the specs is a real specs.

With that, two more points :

1) it does not matter if the ODF specs is smaller. Quality is not a
matter of size. What matters is that, if we are talking about XML as a
modern way to serialize stuff, then the XML we are talking about must
be 1) discoverable and 2) modular. None of those two apply to OOXML in
practice.

2) you cannot instantiate a business word or excel spreadsheet just by
implementing the OOXML specs. Why? because those documents contain VBA
macros and other "legacy" stuff which are not even mentioned in the
specs. Much less documented. If you are ready to call a standard
something you cannot even instantiate meaningful stuff with, then your
next toilet paper is a standard too.

Regards

[stephane....@gmail.com]

Miguel,

I am an independent vendor and sell the most advanced third-party
Excel 2007 generator to this date. This with a number of years reverse
engineering BIFF records, OLE, ... (http://xlsgen.arstdesign.com)

The specs you are willing to give the benefit of the doubt, namely
OOXML, is so bad and so lame that I had to develop a diffing tool in
order to make progress in my development of said product. (http://
diffopc.arstdesign.com)

You won't convince me that the specs is a real specs.

With that, two more points :

1) it does not matter if the ODF specs is smaller. Quality is not a
matter of size. What matters is that, if we are talking about XML as a
modern way to serialize stuff, then the XML we are talking about must
be 1) discoverable and 2) modular. None of those two apply to OOXML in
practice.

2) you cannot instantiate a business word or excel spreadsheet just by
implementing the OOXML specs. Why? because those documents contain VBA
macros and other "legacy" stuff which are not even mentioned in the
specs. Much less documented. If you are ready to call a standard
something you cannot even instantiate meaningful stuff with, then your
next toilet paper is a standard too.

Regards

[Miguel de Icaza]

Hello Stephane,

> The specs you are willing to give the benefit of the doubt, namely
> OOXML, is so bad and so lame that I had to develop a diffing tool in
> order to make progress in my development of said product. (http://
> diffopc.arstdesign.com)

Without more details, I would argue that XML is a pain to deal with
when you are coping with machine generated code ;-)

> You won't convince me that the specs is a real specs.

Well, a "specification" is defined as:

"A document that prescribes, in a complete, precise, verifiable
manner, the requirements, design, behavior, or characteristics of a
system or system component. [IEEE 93b]"

Whether you like the spec or not is a different matter than the spec
being real or not ;-)

I am in no position to judge what is missing and what is not on OOXML,
it would take someone with deeper knowledge to answer that than me.

> 1) it does not matter if the ODF specs is smaller. Quality is not a
> matter of size. What matters is that, if we are talking about XML as a
> modern way to serialize stuff, then the XML we are talking about must
> be 1) discoverable and 2) modular. None of those two apply to OOXML in
> practice.

I think this is a matter of opinion, I have read the pro/con arguments
of both markups and they were as exciting to watch as waiting for the
water to boil. I know some people feel strongly about this (and it
seems like you do), but its just not that important.

And this is what I mentioned when I talked about Relax NG vs XML
Schema. In those two cases there is a *significant* fundamental
difference in the two markups to describe XML.

In the OOXML vs ODF markup debate it seems like we are debating Linux
kernel coding style vs GNU kernel coding style; Or Emacs vs VI.

Not worth loosing sleep over.

> 2) you cannot instantiate a business word or excel spreadsheet just by
> implementing the OOXML specs. Why? because those documents contain VBA
> macros and other "legacy" stuff which are not even mentioned in the
> specs. Much less documented. If you are ready to call a standard
> something you cannot even instantiate meaningful stuff with, then your
> next toilet paper is a standard too.

In one hand, I think it would be good to have VBA as used by Office
fully specified.

On the other hand, I do not like VBA, so am kind of glad that VBA is
not part of it.

And finally, you can build a lot of stuff without ever using VBA.

You seem to be upset that the stuff is not documented or that you cant
create real docs, am wondering what is it that you propose?

Miguel.

[bda...@gmail.com]

On Jan 31, 10:57 am, "Miguel de Icaza" <miguel.de.ic...@gmail.com>
wrote:

...

> But let me ask you something: once you got the specification for the

> new citation field, how long did it take to actually get that into a
> working product. Which products currently support it? Has
> OpenOffice been modified to support it?

That *is* a good question, and the answer is that it hasn't. For one
thing, it's not yet *in* the spec (should be in 1.2). Once it is, I
expect it to be supported in OOo. The KOffice guys have also expressed
interest recently.

But that's a separate issue.

> The best way of influencing something like OOXML is to have a new
> implementation, and influence the new iteration of the format.

You act as if the comments I made were some radical design
modifications.. They were not, and in some cases simply involved
changing some strings in the schema for clarity. See:

<http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/05/
feedback-to-tc45>

I absolutely agree with your point that there needs to be more focus
on open source implementaitons (I've said as much many times), but I
don't see how you can suggest that having two competing ISO formats in
any way facilitates that.

I'm really not religious about this. Personally, I would much rather
see convergence between the two specs, something that Rob Weir has
recently mentioned, and which I've also been saying for quite awhile.

Bruce

[Miguel de Icaza]

Hello Bruce,

> > The best way of influencing something like OOXML is to have a new
> > implementation, and influence the new iteration of the format.
>
> You act as if the comments I made were some radical design
> modifications.. They were not, and in some cases simply involved
> changing some strings in the schema for clarity. See:
>
> <http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/05/
> feedback-to-tc45>

I was not trying to suggest that the changes were radical, I was
pointing out that from my experience with ECMA getting changes to the
spec was proportional to where in the process the specification and
the products were.

As I said somewhere (I cant remember where now) specifications are
just an imperfect snapshot of the industry at some given point, am all
for evolving those.

> I absolutely agree with your point that there needs to be more focus
> on open source implementaitons (I've said as much many times), but I
> don't see how you can suggest that having two competing ISO formats in
> any way facilitates that.

I personally have never cared about the level of rubber stamping that
a particular technology got. As long as we had a decent
specification that we could code against.

I get the feeling that people that care about the ISO standard are
using it in a space that am not connected with, and its probably being
used as a check in a list of features "Can print? check; Can sum
numbers? check; ISO standard? check".

And this is why I do not particularly care: in addition to industry
standards there are "de facto" standards and people will write
software against not only industry standards but against de-facto
standards. For instance, Javascript is wildly adopted, dozens of
idioms exist, and its been embedded everywhere and it is not an ISO
standard, it is merely an ECMA standard.

C# and the CLI are ISO standards, while Java is not, but people still
happily develop against Java. Having one rubber stamped and the
other not might have had some effect on the market place, but I for
sure can not measure it.

I think we will have a similar situation here, OOXML will be adopted
in the wild just because it will be available everywhere, and whether
it is an ISO standard or not will not matter too much. It is all
about interoperability.

I think Microsoft should have played along and adopted ODF. I do not
know what politics went inside the ODF/OOXML split, but it seems like
we have at least a few years ahead of us of an annoying file format
split.

> I'm really not religious about this. Personally, I would much rather
> see convergence between the two specs, something that Rob Weir has
> recently mentioned, and which I've also been saying for quite awhile.

I agree.

Miguel.

[colin....@ntlworld.com]

What utter nonsense! How can you actually promote something that is
6000 pages long, rushed, only had backing of one vendor...etc...etc
and then on the other hand say you support open source!?

I am sorry Miguel but this just will not wash...I admit that ODF has
its complications (and yes the specification is still lacking in
areas) but it is *moving in the right direction* which is something
that I cannot say for any of the MS efforts.

It leaves me asking if your blog entry was for the good of your pocket
or the good of the community? Yet another massive blunder by some one
from Novel (who I thought would be trying to keep their head down at
the minute!?)

[Miguel de Icaza]

Hello Colin,

> What utter nonsense! How can you actually promote something that is
> 6000 pages long, rushed, only had backing of one vendor...etc...etc
> and then on the other hand say you support open source!?

There is a big difference between *promoting* and pointing out that
the majority of the arguments *against* OOXML range from poorly
thought out to hypocritical to fallacious.

> It leaves me asking if your blog entry was for the good of your pocket
> or the good of the community? Yet another massive blunder by some one
> from Novel (who I thought would be trying to keep their head down at
> the minute!?)

My opinions are personal and represent my point of view as stated on
every page in my blog.

Attacking the messenger instead of attacking the actual arguments is a
fallacious construct (google guilt by association)

Miguel.

[troll...@gmail.com]

Prosecutors are not "wrong". They are not "right" either. They
prosecute. It is their *duty*, especially when in doubt. It is up to
the court process to define the outcome.

[Albert Zonneveld]

About standardssize:

>From Rob weir blog:

Miguel has inexplicably ommitted all of the W3C standards that ODF
uses, such as XForms, MathML, SVG, XLink, SMIL, XSLT, CSS2 as well as
IETF standards such as RFC 2045, RFC 2048, RFC 2616, RFC 2898, RFC
3066, RFC 3987. To imply that OOXML follows more standards that ODF is
a foolish statement, unsupported by facts.

Mayby you can add those to you standardssize list ;-)

However I must say that ODF does not fully uses any of these standards
and even not the ones you mention in your article. It seems ODF uses
only very limited part from all of those standards

[yoonkit]

ODF 722 pages
SVG 719
MathML 665
XForms 152 (converted from html using winword, ymmv)
XLink 36 (converted from html using winword, ymmv)
SMIL 537 (converted from html using winword, ymmv)
OpenFormula 371
----
3,202

Now I'm still missing some standards that would add severall hundred
pages and changing line spacing to 1.5 will bring me near the 6000
pages mark I guess. This is not very surprising (at least for me)
since both standards try to solve very similar problems with nearly
equal complexity.

===

Thats a fair comparison to measure the technical coverage. But if this
is done, we will need to compare the complexity of the drafting
process of these standards as well.

Thus we need to tally up the time taken for the drafting process of
each and every one of these standards;

ODF 800+ days
SVG 1000+ days
MathML ??? days
XForms ??? days
XLink ??? days
SMIL ??? days

how long do you think MSOOXML should actually take to review its 6039
page specification?

Already ODF + SVG = 1800 days which is already 5 times longer than the
current MSOOXML drafting time.

a guesstimate would be fine.

would rob weirs' estimate of about 18-20 times longer be accurate?

yk

[Miguel de Icaza]

Hello,

> Thus we need to tally up the time taken for the drafting process of
> each and every one of these standards;

Yup. But "drafting" in some cases meant "designing it" and in some
others it also meant "ram as much as possible down people's
throats" (SVG being a perfect example).

So am not sure that you can compare times for the approach of
"standardize a given input/output" and a draft/design/review process.

> how long do you think MSOOXML should actually take to review its 6039
> page specification?

It has been under review for at least a year at ECMA, and it will be
under review by international bodies for at least six months before it
goes to vote (the meme of "one month" turns out to be wrong; the "one
month" is merely to identify whether its a conflicting standard).

Miguel

[robin....@gmail.com]

By and large I agree with your analysis, but I was surprised enough to
find so many inaccuracies in your section concerning SVG that I
thought I should write in to flag them.

"Referencing SVG would pull virtually every spec that the W3C has
produced (Javascript, check; CSS, check; DOM, check)."

I've heard this argument any number of times, but it only comes from
people who haven't done their homework. First, Javascript is ECMA, not
W3C (but that doesn't matter), and the statement as a whole is
entirely incorrect. CSS is always optional. There are the SVG Tiny
profiles which work on embedded devices -- surely it must be possible
to make that run inside an office suite. Finally, there are enough
conformance levels (IMHO too many in fact) that you can conform to SVG
and not support DOM or SMIL Animation.

"To this date am not aware of a complete open source SVG
implementation"

For all intents and purposes, Batik is complete. KSVG isn't doing too
bad, Firefox has some way to go but the trunk is well advanced.

"Adobe has completely hijacked it"

A common misconception. Adobe was influencial, but they certainly
never hijacked. The complexity in implementing SVG, which is genuine,
largely stems from the fact that the project was started at a time
when it seemed that no matter what W3C did it turned out successful.
Because of that, insufficient scrutiny was given to feature creep.
Hence the subsequent lighter profiles.

"At the time of this comment, Adobe had not yet purchased Macromedia,
and it seemed like Adobe was using the standards group and SVG to
compete against Flash, making SVG unnecessarily complicated."

Competing against Flash, or rather producing an open standard with
comparable functionality, was certainly part of many people's agendas,
but if you stop and think about it a moment making it complicated is
hardly the way to get there...

"Which is why open source applications only support a subset of SVG, a
sensible subset."

Some support a sensible subset, others support really strange subsets
though. I've yet to look real close enough at ODF's use of SVG, but
what little I saw wasn't a sensible subset, in fact it wasn't even a
subset, it was just highjacking the namespace for no obvious reason. I
might have solely found really bad samples, and as I said I've been
meaning to chase this down in the spec, but if what I've seen of SVG
usage in documents produced by OO is the real thing, then I sure won't
blame anyone for using VML!