[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] Results of Open XML balloting at INCITS
- From: Jim Melton <jim.melton@acm.org>
- To: "Len Bullard" <cbullard@hiwaay.net>
- Date: Mon, 13 Aug 2007 10:50:40 -0600
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. =
========================================================================
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]