RE: [xml-dev] Results of Open XML balloting at INCITS

[Len Bullard <len.bullard@uai.com>]

Hi Jim:

I get it.  I'm not sure it matters past the contracts department.

<shortForm>
If ISO passes it this year or next year, OOXML will pass.  A two standard
world isn't going to change much that isn't already changing.  Both of the
competitors are obsolete.  We are in a post-growth market for WYSIWYG and
spreadsheets.  Pre-growth analogies don't apply.  If ISO rebuffed OOXML, MS
would be able to claim it tried to open up but was turned away.  ISO would
be right back where it was when it was claimed it was too slow to create
standards for the web given Internet Time and the W3C would still have rigor
mortis given poisoning by gluttony.  

Weird how that works out.  Everyone loses but Microsoft.

Meanwhile current legal information is being entered into gridviews and tied
by stored procedures to variant SQL databases to be displayed as HTML with
CSS.  So much for page fidelity.   No one loses but 3M and loggers.

Makes one wonder what this fuss is buying us except endorphin highs.
</shortForm>

<longform>
deleted in the short term interest of balance of trade with China
</longform>

len


From: Jim Melton [mailto:jim.melton@acm.org] 
 
Len,

Some wise person (the identity seems to vary with the teller of the 
story) is alleged to have once said that "The nice thing about 
standards is that there are so many of them".  When that line is 
quoted, it seems most often to be in the context of "There are 
multiple conflicting standards that could be chosen as the basis for 
my application -- how on earth am I supposed to figure out which one 
is 'better' in my situation?"

The relational database industry, of which I have been a part 
for...ummm...a long time, is an $N-billion industry today (N 
somewhere between 20 and 250, depending on exactly how wide one casts 
one's net).  It grew from $0.00 to that largish number in less than 
25 years, most of the explosive growth occurring between the fifth 
and 15th years.

When the standards agency that first promulgates the SQL standard in 
late 1986, that pretty much settled the question of "What language 
should I use for writing my database code?" and the industry took off 
with a shot.  But, if that agency had chosen to (which it was 
strongly encouraged to) promulgate two, three, or more standards for 
various database languages (e.g., the arguably "better" QUEL from 
Ingres), I think that confusion would have continued to reign and 
that the marketplace would have taken off much more slowly.  It is 
possible that we would still be mired in the quagmire of having 
different vendors promoting different "standard" database languages 
and locking their customers in on that basis.  (Oops...the many 
implementation variants of SQL have a similar effect, arguably a good 
reason for standardizing even earlier.)

There are environments in which international standardization is 
extremely relevant for a variety of reasons (e.g., marketing high 
technology products in China because of a government mandate) and 
there are environments where it is not (e.g., in a dyed-in-the-wool 
Microsoft or Apple shop).  When standards are important -- mandatory 
or merely corporate policy -- it's nice to have one good standard 
from which to choose; minimally, there "must" be clear criteria for 
making the choice between multiple, overlapping or conflicting, 
standards.  In the case before us today, the only obvious criterion 
that I see is "vendor neutral vs proprietary" (most decision makers 
will not understand, or even perceive, the technical 
distinctions).  That criterion isn't very helpful, because there are 
environments in which vendor neutrality is vital and others where a 
single-vendor solution is acceptable or even desirable.

Why, then, would the owner of the proprietary spec care whether or 
not that spec becomes an international standard?  It's simple: To be 
able to persuade customers who want a truly neutral standard that 
will keep them out of vendor lock-in to believe that their 
proprietary spec satisfies that need so the customers will buy 
products built to that "proprietary-standard" spec instead of the 
more neutral one.  It is, of course, a long-standing tradition in the 
standards world of a particular party hoping to get its specs 
anointed as a "standard" while that party's competitors try to have 
that spec altered sufficiently that everybody -- including the 
original party -- gets to share the pain of conforming to it in 
approximately equal measure.

I'll grant you this: that's a politico-economic argument rather than 
a technical one.  But politics and economics are ultimately how most 
of us manage to get paid a salary.  If my competitor gains 
significant market advantage by having his specs anointed in a manner 
that moves customers from my products to his, then I've got a 
problem.  Sure, I'd like to do that to him, but a much more palatable 
approach to the many fleas on the elephants (so to speak) is to have 
vendor-neutral specs on which even the fleas have had some direct influence.

Sigh...that got longer than I'd planned, but (another wise person): 
I'm sorry this is so long, but I didn't have time to make it shorter.

Hope this helps,
    Jim


At 8/12/2007 08:31 PM, Len Bullard wrote:
>The problem would still be policy that states standards are the basis of
>procurement without naming a standard.    Under such conditions, OOXML has
>to seek standards status.   If the objection is controversy but there are
no
>definitions for what constitutes controversy, this is still a matter of
>voting.  As to the need for fast tracking, I am neutral as long as the
>reasons are technical.  It may not be policy but it is common sense and the
>way I *would want* American representatives to vote.
>
>We have to disagree on the 'only one international standard' position, Ken.
>There are side-effects that can damage international standards practice and
>culture.  Under such a policy, choice is removed along with competition.  I
>think we probably disagree on the potential severity of the first if not
the
>fecundity of the latter.
>
>len
>
>
>From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com]
>
>Michael Kay said:
>
> >
>http://consortiuminfo.org/standardsblog/article.php?story=2007022819130536
> >
> >That is about responses to the contradictions period, which is a
different
> >stage in the process. ISO basically said "No", or rather "None of what
you
> >say is a showstopper that requires extraordinary intervention, these
> >issues can go on and be addressed by the normal process": the current
> >ballot produces the big issue list to get resolved.
>
>As I understand it, it wasn't ISO that said that but that, per the
>directives, ISO invited Ecma to make comment on the allegations
>coming out of contradiction period.  Ecma then authored the "not a
>showstopper" words based on its interpretation of the contradiction
>comments and ISO dutifully distributed Ecma's words (as it would for
>any fast track submitter) to the national bodies as the submitter's
>response to the allegations of contradiction.
>
>I do not recall seeing a single ISO/ITTF assessment or official
>summary of the contradiction allegations or the Ecma disposition of
>those allegations.  I've only seen Ecma documents circulated.  The
>Directives section 13.4 cites in parts "consulting with the proposer
>of the fast-track document... if the resolution results in no change
>to the document or if a resolution cannot be reached, the fie month
>fast-track ballot commences immediately ... JTC 1 shall circulate the
>comments and the disposition of such comments".
>
>I don't remember seeing any ISO/ITTF document stating in effect "none
>of what is said is a show-stopper".
>
> >The other thing to realize is that no means yes. When a nation gives a no
> >vote, they have to give the technical reasons why not and suggest their
> >preferred fixes.
>
>Not true ... a national body is not obliged to give technical reasons
>for a no vote.  National bodies and other voting members are welcome
>to vote no with non-technical reasons that have no resolution.  Their
>vote is counted as is all the others.  This was confirmed with JTC
>1.  The comment about technical reasons only was misinformation
>disseminated at the Seoul plenary meeting of SC 34.
>
>I'm posting the following comments with my XML developer hat on and
>not in any official capacity regarding my standardization
>responsibilities.  As my private opinions on this matter were
>intentionally outed against my expressed wishes by one of the
>companies involved, I feel I can now comment openly with my own
>opinions about this situation.
>
>I see ISO/IEC 26300 ODF is an XML vocabulary for office documents.
>
>I see DIS 29500 OOXML is an XML vocabulary for office documents.
>
>Adding the faerie dust of international standardization does not, in
>my opinion, add anything to any legacy of existing documents that are
>already in XML.  The legacy and any related prevalence of existing
>documents is immaterial.  Legacy users of OOXML don't gain anything
>by the specification becoming an international standard.  Having
>already chosen to use XML they get the benefits of longevity and of
>access using markup-based tools.  International standardization
>doesn't change that.
>
>I wish I had thought to say this but a good friend (I haven't got
>time to get his permission to attribute him) made the astute
>observation that the phrase "Open XML" is redundant like the phrase
>"edible food" is.  "Office Open XML" is no better than just "Office
>XML".  Existing legacy users of "Office XML" are already getting the
>benefit of using XML markup and deeming that markup to be an
>international standard does not add anything at all to their legacy
>investment.
>
>But think of a customer asking a developer to "please create an
>XML-based expression of this information I have that I would like to
>maintain in a spreadsheet application, and I don't care about the
>application but I do care about the data".  If there are no standard
>formats, the choice is muddy.  If there are two formats to choose
>from, a standard format and a proprietary format, the choice is
>clear.  If there are two standardized formats, the choice is muddy again.
>
>International standards development processes exist to accommodate
>such contradictions:  when an existing standard does not meet
>identified user requirements satisfied by a specification that would
>be in contradiction, the maintenance of the specification should
>address the user requirements following an established process.
>
>Therefore, to move forward the community should focus on new
>developments and what choices in standardization there are when a
>developer creates a new project or a vendor creates a new tool or a
>customer creates a new need.  There should be a clear choice to move
>forward and not a confusing choice to move forward.
>
>I think there should only be one internationally-standardized XML
>vocabulary for office documents and that the existing one should be
>augmented to address identified user requirements brought to the
>maintenance process through proper channels.  The fast track process
>is not a standards development process but a ratification process and
>if it isn't clear that the specification can be ratified easily and
>without contradiction then the user requirements addressed by the
>fast track should have gone through a traditional open standards
>development process.
>
>And OOXML still has a chance to do so, just in my opinion not as an
>ISO fast track.  I don't have anything against OOXML as a vendor's
>choice format, or even Ecma's choice of format for its member
>organizations.  My opinion about how easy or not easy it is to work
>with OOXML is not relevant.  The OOXML developers worked hard to
>produce an XML vocabulary that meets their needs and they have
>valuable input to the development process as a result.  I'm focused
>here on process and the impact of having more than one international
>standard when there is an opportunity to prevent having more than one
>by going through development processes and not fast track processes.
>
>I hope this is considered helpful.
>
>. . . . . . . . . . . . Ken (speaking only for myself)
>
>
>
>
>_______________________________________________________________________
>
>XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>to support XML implementation and development. To minimize
>spam in the archives, you must subscribe before posting.
>
>[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>subscribe: xml-dev-subscribe@lists.xml.org
>List archive: http://lists.xml.org/archives/xml-dev/
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
   Co-Chair, W3C XML Query WG; F&O (etc.) editor    Fax : +1.801.942.3345
Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive      Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA          Personal email: jim at melton dot name
========================================================================
=  Facts are facts.   But any opinions expressed are the opinions      =
=  only of myself and may or may not reflect the opinions of anybody   =
=  else with whom I may or may not have discussed the issues at hand.  =
======================================================================== 


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.