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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] More predictions to mull over

Michael Champion wrote:

> Maybe you don't see the problem because you are happy writing custom integrations, one system at a time. Eric is talking about standardizing that process so that his customers don't have to figure out how to map each application's data and protocols laboriously onto XML+HTTP, reinventing 90% every time. They want to put that common 90% into the infrastructure and just build on top of it.  

I guess I'm not convinced that there is a 90% or even 50% commonality to 
these systems that can be taken advantage of. If there is (and there 
might be) I don't think WS-* has managed to find it. Ws-* adds so much 
complexity and confusion to the process that it is easily more costly 
and complex than doing custom integrations one system at a time.

Could somebody find a way to hit the 90% point better without all the 
extra complexity WS-* brings to the table? Maybe. I haven;t noticed it 
yet if anyone's done it.

I do think there's a problem with overly generic solutions in our 
industry, especially when pushed by large organizations. They try and 
solve all problems even when they only need to solve one. The simple, 
specific, one-off solutions are usually all most companies need most of 
the time, and they come in a lot cheaper.

WS-* is hardly the only place where I see this. The problem is rampant 
in APIs. See 
for another example and some more discussion.

Sometimes you do need interoperability and a high level of genericity, 
but more often than not you don't. My problem arises when people tell me 
I have to pay the cost for genericity even when I don't need the 
interoperability that buys me.

> For example, what if the RSS ecosystem didn't exist, but people wanted to track changes to a number of websites in a client or server side aggregator.  One could happily sink one's teeth into the problem of scraping the HTML of each site of interest, transforming the common information into a common XML format or database schema, and sorting/filtering/displaying it on demand.  Then RSS came along and shoved all that down into the infrastructure. Probably people on this list did a lot of those custom aggregators a few years ago, and may have thought RSS was lame and doomed because it was so ugly and fragmented.  But we all got another reminder that Worse Is Better, and somehow or other everyone starting syndicating their sites in some flavor of quasi-XML RSS,  and there are hundreds of free ways to consume all that stuff. Dave Winer is a millionaire media guru while people who know how to design proper XML formats still have to work for a living :-)  

FWIW, I don't think Winer made his millions from RSS. However I don't 
think it's a coincidence that the successful solution here came from a 
small developer and one company. For all its flaws, RSS got a lot right. 
Most importantly it was simple enough for people to grok after a quick 
reading, and simple enough that they could write their own tools for it. 
  There was one level of indirection at most in the spec, and Winer's 
initial version worked for pretty much one web site: his. Netscape had 
something to do with it, but they were imploding and focused elsewhere 
so it didn't get much attention from them.

Small developers don't have the option to spend person-years and 
millions of dollars solving every variation of a problem, and following 
the waterfall model of spec-design-code-test-deploy. They have to be 
more agile. They have to solve problems right now with limited resources 
or they don't meet the payroll or pay the rent. Had AOL, Microsoft, Sun, 
CNN, the NSA, AW, and a dozen others gotten together to invent something 
  to track changes to a number of websites they could never have been as 
successful as RSS was.

There's also an advantage to many options. RSS was not the only solution 
to syndication available in the late 90s. Microsoft had one. Slashdot 
had one. Probably others had one too. RSS is just the one that took off. 
  At early stages, it is much better to have 6 different solutions than 
6 organizations working on one solution. This principle is quite 
relevant to JSR-311 for example, or schema languages.

> What's the real evidence that WS-* has gone off the rails, *if* we assume that the objective is to shove the common 90% of integration development down into the infrastructure and that the beauty of the technology is not a criterion of success?

I think the onus is on the WS-* purveyors to demonstrate that what 
they're selling is worth the cost, not the other way around.

´╗┐Elliotte Rusty Harold  elharo@metalab.unc.edu
Java I/O 2nd Edition Just Published!

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS