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] Competing Specifications - A Good or Bad Thing?

[ Lists Home | Date Index | Thread Index ]

one other aside here. why is that the ieee has had so much success on
ethernet (wired, wireless, etc) standards and ws- seems such a mess?
seems to me there's as many competing commercial interests.

the other intriguing pseudo standards effort is pc buses. back in the
80's there was lots of standards for buses, and then along came pci - to
me almost from nowhere, it's not the best but works well, is cheap to
implement, and now ubiquitous.

as you said, like trying to pick the next beatles record.

rick

On Tue, 2004-04-06 at 04:00, Bullard, Claude L (Len) wrote:
> As long as people want specification and standard to mean 
> the same thing, they'll be in a chinese finger puzzle of 
> their own making and chumps to the ambitions of self-selected 
> consortia for standards manufacturing.  
> 
> A spec for a technology that does 
> not yet exist is research becoming product.  A standard 
> to converge technologies that do exist because such 
> convergence increases their value to some asset holder 
> (proprietary, open, it doesn't matter to the definition) 
> has benefits which have to be reckoned in terms of that 
> value type to those asset holders.   
> 
> Netscape was/is a product; not a spec.  It 
> was never a standard either.   It was the beneficiary 
> of some decades of research and the opening of the 
> internet distribution system.  It was only the first, 
> not the best or the least, but by no means, standard. 
> But it set an example the market believed was a product 
> of the forces of standardization instead of a temporal 
> convergence of the forces of cheap memory and processors, 
> the opening of the Internet to commercialization, and 
> the free IP.  Trying to emulate its success is like 
> trying to be the next Beatles.  Hard to do because the
> same conditions might not exist.  Don't buy the 
> mythInformation of Killer Apps.  It's a crock.
> 
> Web services are a redux of earlier efforts at creating 
> networked applications that balance workload.   The  
> visions of 'seamless computing' or "frictionless economy" 
> are crocks.   That network resources can be made available 
> programatically is not.  It seems to me that the web 
> services picture falls apart depending on which problem
> one wants to solve with a web service interface.
> If the only web service a system exposes is a query 
> processor constrained to a schema, that works ok under 
> common practices.  Security?  Not so far.  So I think
> we agree here.  Choose wisely the problem to be solved.
> 
> len 
> 
> -----Original Message-----
> From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
> Sent: Monday, April 05, 2004 12:45 PM
> To: Bullard, Claude L (Len); rjm@zenucom.com; xml-dev@lists.xml.org
> Subject: RE: [xml-dev] Competing Specifications - A Good or Bad Thing?
> 
> 
> Bullard, Claude L (Len) <clbullar@ingr.com> writes:
> 
> > 
> > It depends on the local issues.  A single spec for a 
> > new technology might indicate a proprietary development 
> > ripe for IP exploitation.  If it works, why not? 
> 
> Seems to me you're trying to have your cake and eat it to: on the one
> hand any spec. that is "ripe for IP exploitation" is ok, but OTOH, any
> spec. that prematurely codifies practice is bad.  How are you supposed
> to know the difference?
> 
> > Not 
> > everything is in the commons and that assumption of 
> > community property for all things web is one way to 
> > sort out the naive and inexperienced including those 
> > who offer up single spec/single use specifications 
> > labeled or processed as standards.   Respect for IP 
> > is the way forward.  IP keiretsu in the form of consortia 
> > managed royalty free contributions will work both 
> > for ensuring that submissions are vetted under 
> > participation agreements, and for keeping as much 
> > IP as is workable in the commons of jointly indemified 
> > contributions.   
> 
> Sure, but that seems only peripheral to the issue is when to spec. and
> how much?  A lot of the spec. world isn't about IP, it's about trying to
> standardize business practices.  Trying to use specs. to leverage first
> mover advantages is a tad like bit like, <bad-metaphor> trying to keep
> the wilderness pristine by building a theme park in it</bad-metaphor>
> (though when someone does manage to sneak -- Netscape like -- under the
> radar, the advantage can be enormous for a while).
> 
> > People make assumptions.  That is how they learn.  If 
> > they don't, they fail.  Life and death in the ecosystem.
> > 
> > We got here because too many stopped focusing on developing 
> > software and started playing the standards game.  I blame 
> > the W3C squarely for that.  This community made its own 
> > problems and this community will have to face up to the 
> > job of fixing the mythInformation it created.
>  
> Given the ambitions of "web services", the ill defined scope, the
> previous history of universal interoperability specs of the same nature
> (CORBA or the OSI stack anyone?) and the ever increasing pressure to get
> to market I can't imagine why anyone would expect any of this to emerge
> cleanly or rationally? 
> 
> Every time I preach "how to do a system architecture" it usually
> includes a phrase something to the effect of "use standards where there
> is a significant body of best practices that clearly match the business
> problems you are dealing with". IOW, pick you risks wisely...
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
> 





 

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

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