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] combining malfunctioning, evil adult as XML with Elliot Ru

[ Lists Home | Date Index | Thread Index ]
  • To: "Alaric B. Snell" <alaric@alaric-snell.com>,"Gavin Thomas Nicol" <gtn@rbii.com>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] combining malfunctioning, evil adult as XML with Elliot Rusty Harald
  • From: "James Governor" <jgovernor@red-monk.com>
  • Date: Fri, 31 Jan 2003 10:39:24 -0600
  • Thread-index: AcLJHDBzRTyVOvLyQtKIf0DAJZcDbwAJSu8w
  • Thread-topic: [xml-dev] combining malfunctioning, evil adult as XML with Elliot Rusty Harald

Humans are "less than optimal" in a huge range of habitats. Yet we're
comfortable and effective in almost any environment. Evolution is funny
that way--animals and plants have a tendency to occupy, and thrive in,
unexpected niches.

We used to live in trees right? Surely we were "less than optimal" for
the plains and wide open spaces. Or maybe not.

Don't we need to be comfortable with change? Getting stuck in a niche is
the quickest route to extinction if conditions ever change.

And conditions always change--that's entropy for you.

I actually agree with Eric too, from what I can read and understand, but
I just think that the balance between specialized and general purpose is
one of the most fluid and interesting in IT, and not something that can
be controlled. It's all about the balance between available resources
against current problems. When networks are shit cheap, for example, a
whole range of possibilities present themselves. When networks are
expensive--different problems need to be solved. 

Its like centralization and distributedness--both have a place in the
world, and some of the most exciting developments happen when they
converge (Linux on the mainframe, for example).

Recently someone on this list gently roasted network hardware
accelerator vendors for getting into the XML game. But these vendors are
just trying to address a problem --that is, the verbosity of textual

This to me seems a sensible attempt to solve a problem. What's the
alternative? Demand that all network traffic is binary encoded? Ban XML
from corporate networks?

The "good enough" surely defines success in IT and the world at large.
From where I am standing, with neither a programmer or markup prejudice,
it seems like XML is "good enough" for a wide range of applications and
use cases. I see all sorts of communities getting excited by XML for
this reason. 

Might XML get "bastardized" or even "hybridized"? sure.

Is binary more appropriate in some use cases? Sure. Will it coexist with
markup? Sure. 

But people have to make their own mistakes, have to discover what
technologies are most appropriate in which niches. And if the technology
has to be forced to suit the niche, and creates value in the process,
well then so be it. And if conditions change to make a technology
appropriate in a way it didn't use to be, then that's cool too. Likesay,
barbary macaque monkeys in Gibraltar.

The complaints are good. That is human nature. Conflict leads to
creativity and problem solving. 

The "meaning" of XML is surely to be found in how it is used, not in
some "essence of markup"

Hey I just got another post from Mike Champion that says something
similar WAY WAY WAY MORE more effectively than I have done! Maybe he
will get the brunt of the flame.... ;-) 
Excerpt from Mike post below

ERH has a thought provoking comment on his weblog today 

It's interesting that the Web Services community has managed to alienate

three different communities for three different reasons that all derive 
from not understanding or accepting the basic principles of the 
technologies they're building on. They're either geniuses or idiots. My 
money's on idiots, but time will tell."
On the "XML community" critique, the way I see it is that the Web
people are pushing the XML envelope in ways it was not pushed before,
have found it wanting: Things like entity references play hell with 
efficient buffer management in high-performance parsers; XML 1.x is not 
composable as specified, which makes the full spec unusable for a
extension model such as SOAP offers, and so on. (See the response by the

XMLP WG to this issue on www-tag a month ago for details).  It's not at
clear what the best way forward is -- forking, profiling, deprecating
XML 2.x -- but I personally have little patience with the argument that
"fundamental design of XML" has been compromised.  In fact, the fact
the SOAP community independently came up with essentially the same
of XML that the SML-DEV folks did a few years ago ("Common XML Core")
me even more convinced that the "fault" lies more on the XML side than
WS side.  Document and Messaging XML use cases certainly share a lot,
maybe they don't share everything.  I resist data-heads imposing their 
paradigm on XML as a whole, and I resist doc-heads insisting that data- 
oriented applications do it the One True XML Way.

My money is on the geniuses (whichever community they're in!), simply 
because they're learning what actually works and are adapting in real
I'll bet against the zeaots (in any community) who think they understand

the problems of everyone by their knowledge of certain a priori
As offensive as I found much of Erik Naggum's post discussed earlier, I 
gotta love his .sig:

"Act from reason, and failure makes you rethink and study harder. Act
from faith, and failure makes you blame someone and push harder"

So, I pose the question: are the various communities who "detest"
Web services acting from reason and learning from both the WS failures
the failures of their own pet theories, or are they acting from faith
blaming those who tried to apply their pet theories and found them
To be honest, I see lots of adaptation to the ideas of REST and XML in
WS community, but don't see many signs of learning from the WS
in the REST and XML communities.  Maybe I'm acting "from faith" too :-)


Mike Champion



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

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