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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] You call that a standard?

[ Lists Home | Date Index | Thread Index ]

I can understand the frustration of the early VEO days and the standards armies. 
I sit today in the other extreme;  a company that has only recently admitted that
work going on at the Department of Justice and OASIS might actually show up
in an RFP, and now that it does, is caught napping.  My frustration is every
bit as deep as yours, but my bank account is likely not as deep.  :-)
The problem with the 'let's just get smart guys together and figure out what
works' is believing anyone believes them, but really, that they will cite that in
an RFP so one can sell that.   Some bits get implemented in say a Microsoft
or Sun application and no one has to worry about the RFP because the
work is actually sold as part of the framework.   The W3C is very good at
doing that kind of standard.   But we don't cite and sell those.  We build 
on them.  
XML as a requirement is a single checkbox in an RFP.   Global Justice XML
isn't.  It is a large and expensive box to check.   It is also is a commoditizer
and some will resist that while others will realize that a commodity market
isn't a bad market if the commodities actually work and one can add value
without breaking the standard.  For example, the database messages or
web service methods may be standard, but the presentations may be
an area of competition, the analysis tools may be competitive.
Where VEO went off the rails was conflating standardization and
technical innovation.  I am all for the 'chaos is the engine of
evolution' strategy when innovating.  I am for standards when
procuring innovative products that have tested well and now
should be standardized.  I have no problem working with
proprietary XML vocabularies.
I wrote the Enterprise Engineering papers and Beyond the
Book Metaphor before Veo existed or Matt wrote those
papers for school and Disney.   That's vision work; it is not
standards work.  Think how frustrated I got when because 
the Air Force locked up BTBM and EE languished in a
CALS publication, I had to sit and watch some of my 
best work die on the vine while others claimed "invention". 
That's the price of real pioneering, not the stuff the news guys
notice:  obscurity.  Well, that's the gig.  Life in the crow's nest.
We did know that enterprises and agencies
would integrate across the networks.   We did not have the
detailed designs because we did not yet have the standards
for addressing and the GE network honchos adamantly
opposed using the Internet when and if it was commercialized. 
So we proposed what was there.  HyTime went too far but at that time, it
was what we had.   HTTP did not go far enough and now
we have SOAP.   But understand this:  those who do have
to procure need a way to trust what they procure without
having to go find those smart guys and ask them.   That's
business.   Standards are created for many reasons but
the business reasons don't go away just because someone
says, 'this standard isn't ready or this product won't pass
the conformance suite.'    We have to meet in the middle
and that is how we get standards that work and more importantly 
are provably workable.
I sympathize with the dismay, but I think it is the cost of doing business.
Would you like to be Intel producing something so complicated
that no matter what they do, they will always trip on someone's
patents so now, lawsuits are a cost of doing business.  No
free lunch and all the smart guys in the world can't fix that.

From: Bob Glushko [mailto:glushko@sims.berkeley.edu]
I was at first amused by all this discussion as a follow up to my interview about standards.

I don't have any special insights.  The only reason I was called by the reporter was that I was apparently the only person willing to be quoted by name in John Markoff's NY Times article about Microsoft and CEFACT...and that's because I no longer work for a commercial concern that could suffer because of anything I said.   

And as I said to the CNET reporter, you can't be surprised that companies want to influence the process, but you can be surprised that they'd try to do it in ways that don't look good with the lights turned on.  I always tried to make sure that the work I personally did or directed at Veo and Commerce One would pass the "lights on" test .   But now that I look back at it, I have to conclude that we vastly overinvested in standards activities, spending gobs of money to participate in the W3C or OASIS or ebxml or UBL to do "good work"  whose direct ROI for us was minuscule.  We might have been better off investing our time and talent in products rather than standards because a lot of them got co-opted or undermined.  Matt Fuchs, Alex Milowski, Terry Allen, Arofan Gregory, Sue Probert, David Burdett,  Brian Hayes, Lisa Seaburg-- we had armies fighting the standards  battles..  I approved a lot of travel expenses for a long time.

Anyone remember the eco framework?  Take a look at http://eco.commerce.net/. In 1998-1999 that group proposed most of the web services stack in a more open way (Murray Maloney was hired by CommerceNet to run this) and it is in the dustbin of history.  To follow up on something in this thread -- where the press focuses on personalities rather than events -- it annoys me immensely every time I read about the history of web services because I know they started in eco and some of the companies that were in eco simply took the best ideas from it and repackaged worse versions of them as the first web services "STANDARDS."

So the more I read in this follow up discussion, the more I'm feeling dismayed rather than amused.

=Even though
good process has emerged by dint of experience,

I think the processes of creating recommendations / specifications / standards are getting worse. The W3C seems to be working, but OASIS has devolved from the place where interoperability was job 1  (remember the SGML catalog, the table model efforts) to a place where redundant  and incompatible splinter vocabularies are encouraged because it helps the business model -- "democratically,"  of course -- but I'd prefer to have the less democratic process of the SGML Open days when the smartest people in the world just got together to fix things that really needed fixing.   We don't need standards... what we need are things that work.  And we need to organizations that claim to be helping that happen to actually do it.


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

Copyright 2001 XML.org. This site is hosted by OASIS