OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Microsoft buys the Swedish vote on OOXML?

Someone should have passed the ImprobableTrivia test by now.  History is
interpretable and the WayBack machine was not a time machine.  It was a 'how
history should have been machine.  A different view:

1.  I agree.  People who have a technical reason to oppose a standard
should.  People who show up late making accusations and formenting chaos as
a means to alter market conditions should be stopped at the door.

2.  SOAP works for what it is designed to do.  The utility of that in many
cases is in doubt.  Like many layered systems such as XML, there are
buggered implementations.  Those who don't like SOAP can roll their own with
REST.  Not really a problem.  Two different standards has created a
competitive market.  Choice is good.

3.  In the case of 2D vector graphics standards, MS brought a good proposal
to the table in the form of VML.  It was rejected.  Someone who was there
can say why but the winner with committee consensus (SVG) seems to be dieing
and the one that was rejected has broad use today despite the buggered
implementation.  Go figure.  The MS proposal for Schemas was simpler and
easier.  Again, MS was turned back by committee consensus.  Today we have
the disasters you list.  Not a great outcome.  Namespaces?  Lay that one at
James' feet.  It appeals to some but it is a difficult spec.  I suspect
alternatives would be as well because naming at scale is a notoriously
difficult problem even if the name is only a label.  Sometimes the smartest
guy is the wrong guy for the job.  It is a noted management problem.

4.  You are right.  "Specification" could have been the best solution given
a credible sponsoring organization and participation agreement.  The problem
as you know is that forces decided to mandate 'standards-only' solutions.
That isn't working to the broad consensus who tend to be owners of Microsoft
products and who will be the victims of that policy if it holds.  

5.  Even if OOXML is turned back, it isn't a permanent condition.  It will
be fixed and resubmitted because a broad consensus of the users and vendors
of it have said they will implement it.  That will frost the competitors of
those vendors, but it will benefit the customers.  Standards aren't a
licensed monopoly either.


a) Historically, blocking a vendor submitted standard at the gate because of
animosity for the vendor hasn't worked out so well for the broader customer

b) Even if the standard or specification is approved, implementation
determines market outcomes.  That is a bare knuckles fight and rightfully

c) Standards in some cases work out well.  Liaisons and participation
agreements determine IP covenants so one really does want to pay attention
to those conditions.  Some doubt the IP conditions for OOXML sufficiently
protect third parties.  IP attorneys should be looking into that but someone
will have to pay them to get a 'clean as a hound's tooth' result.  Other
organizations and vendors such as the W3C/W3DC/ISO have created
participation agreements that are holding up very well.  These tend to be
beneath the radar technologies (eg, 3D on the web) because once they show
promise in the market, large organizations (notably IBM), pick individual
vendors who are not participants and offer to sponsor them as standards.
The net result will be multiple standards if the trend continues but one can
only hope enough IP is already in the clear to keep the market from being
captured in a sub optimum orbit.  Time will tell.

IMO, this comes down to choice.  The pro-ODF forces repeatedly say we need
only one standard.  Experience shows that to be false in many cases.  Is
this an exception?  I don't think so but that is only one analysis.  I do
think Massachusetts took a long hard look and decided it is the wrong thing
to mandate and above the fray and below the ideal, choice is better
preserved than thrown away speculatively.


-----Original Message-----
From: Elliotte Harold [mailto:elharo@metalab.unc.edu] 
Sent: Monday, September 03, 2007 11:35 AM
To: Rick Jelliffe
Cc: XML Developers List
Subject: Re: [xml-dev] Microsoft buys the Swedish vote on OOXML?

Rick Jelliffe wrote:

> 1) Participation is good. The people who should *not* participate in a
> standards effort are the people who don't want that standard and have a
> rival standard of their own:

Um, no, absolutely not. People who don't want a standard most definitely 
should participate in the process and attempt to derail it. Well before 
the current case I've seen far too many examples of standards that were 
pushed through in the face of significant opposition and gone on to 
cause severe problems for many parties who did not participate: SOAP, 
WS-*, W3C Schemas, XML Namespaces, and the list goes on.

The presumption that a standard will be approved is a major flaw in the 
many standards processes. IMO, a standard should only be approved where 
broad consensus exists. Significant opposition among people other than 
those who created a standard should be taken as de facto proof that a 
technology is not ready to be standardized.

There is a difference between a specification and a standard and we need 
to understand. Rejecting something as a standard does not equate to 
preventing people from using it. OOXML could be fully specified (though 
to date it hasn't been, and that alone is reason enough to reject it) 
without approving it as a standard.

*All* the benefits I have seen attributed to approving OOXML as a 
standard are no more than benefits of specifying it. I have yet to read 
one single, plausible argument in favor of *standardization* of this 
format as opposed to mere *specification*.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS