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] Elliotte Rusty Harold on Web Services

[ Lists Home | Date Index | Thread Index ]

On Sat, 08 Feb 2003 18:56:19 -0700, Uche Ogbuji 
<uche.ogbuji@fourthought.com> wrote:

>> The history of C -> C++ -> Java -> C# is an interesting thing to ponder 
>> in this context: to me, it's not self-evident that Java did the right 
>> thing in forking .... I would prefer NOT to do this all over again
>
> I knew your "ecumenism" analogy was dodgy, but even I did not expect you 
> to contradict yourself so swiftly.  What is wrong with the competition 
> between Java, C, C++ and C# ?

Competition is good, but stovepipes are not so good.  Forks lead to 
stovepipes: Java, C/C++, and C# as actually practiced are essentially three 
separate environments -- if one chooses to develop a product, one has to 
either choose one over the others or invest *significant* resources in 
separate code bases, porting tools, or whatever.  Thus innovative tools or 
implementations of new ideas tend to be available in only one of the above. 
 There ain't no way (AFAIK) to work in Microsoft's best-of-breed IDE and 
use the great open source Java code out there.  I for one consider that a 
problem.  [MS may consider it a solution, I'm not going there :-) ]

Hypothetically, had there been a way to agree on the fundamentals and have 
competition over the details, you could get the advantages of competition 
without the disadvantages of stovepipes.  Even in 20:20 hindsight, however, 
I don't see how that could have worked in the C++/Java/C# worlds -- 
arguably the whole *point* was to create incompatible environments to 
negate the momentum of the others.   But I *do* see that as a very viable 
and desireable scenario in the data language worlds.  As much as we all 
disagree on here, there is an awful lot that we agree on, and "forking" 
because some subgroup doesn't like some technology or some vendor is 
counterproductive ... so long as that vendor can't call the shots or the 
technology does not become "core."

So, my general approach to these questions in the XML world is to suggest 
refactoring things so that what is common is in the core, and then there 
can be competition in the periphery among alternative ways of adding value 
to the core. That's why I both resist the efforts of some parties to drive 
technologies such as W3C XSDL types into the core of XML ... and resist the 
efforts of other parties to fork XML into "document" and "data" camps.  
What we all have in common is something much like Common XML, or "the SOAP 
subset" or "the Skunk Works proposal."  I advocate refactoring the core now 
to avoid forking later, and competing in the periphery to avoid premature 
lock-in.

Extreme specwriting.   Another dodgy analogy, I'm sure :-)








 

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

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