xml-dev - Re: XML: Still Just HypedWebStuff

[Len Bullard <cbullard@hiwaay.net>]

Matthew Gertner wrote:
> 
> > Cost justify XML.
> 
> This is interesting argument, but:
> 
> 1) It is far from clear that XML solutions will have to be sold for less
> because of "hyped perception of ease and ubiquity"

What we are seeing is a hype that XML has some magical effect on the 
bottom line, but the dirty secret is it costs as much or more, and just 
like SGML, if I need consultants and BizPartners just to implement it, 
it is a failed technology.  (Remember, this is just Us Chickens 
talking and exploring potentials; I can make a case for SGML/XML but 
that is coals to newcastle on this list.)

I admit the power of branding, but as more services 
come online to differentiate on price or any other characteristic 
which the customer uses (eg:  gotta have what kid says they gotta 
have), then buying customers with pricing is one way to increase 
the power of the branding.  What the Kroger experience showed 
was that the online model was not necessarily good for business 
even if it was good for the consumer.

XML won't be sold for less unless the TCO is less.  
There are still many markets where competition is based on barrier to
entry.   
Having the press screaming is a double edged sword.  It gets attention
but it 
raises expectation and in revolution counter-revolution cycles, 
not meeting expectations is like dating a runway model and failing 
to have cab fare on the first date.  My point is more that the 
platforms are unstable, XML can't fix that (SGMLers know the real 
misery of this because they don't blame the platform), and the 
folks who use XML need it hidden from them anyway.  

> 2) Do you really think that XML gives the same results as an RDBMS and
> CSV? 

Yes.  By the time any competent developer creates the function libraries 
for moving CSV around, they also develop the utilities to make it 
easy to do the necessary schema mapping.  That is actually the hardest 
part and fact is, its not that hard.  XML adds very little as a magic 
parse except in shrinking the number of parsers.   

> Just to give one example, if I have a PHP/ColdFusion/ASP/whatever
> site delivering HTML and I suddenly discover that I need to support WAP
> (or Ariba Network or PDF or...) I am forced to reimplement everything
> and then maintain my two (or three or four) versions in parallel. If I
> go for an XML-based solution, then much of my site logic can be drawn up
> out of the RDBMS into the XML layer, and the step to the various
> delivery formats is only a transformation away. Saving time means saving
> money, how's that for a cost justification?

Lousy.  The transform can be done at the server before that middle tier 
is ever called.  It is easy to do, done in the language the implementor 
is familiar with, requires little mapping to the tree, etc.  IOW, it is 
just an extra layer of work as far as the implementor sees it. 
Downtranslation 
is downtranslation.  When you are using recordsets, the structural 
model is already efficient, flat, and optimized.  Pushing XML or CSV 
out is about the same.  Where XML gets an edge is if the guy on the 
other end has only weakly agreed to names and membership.  BTW, most 
contracts already read "you will use our COTS schema".

> Nevertheless, there is a need for people to start implementing stuff and
> establishing a community where schemas, stylesheets and the like can be
> "discovered" rather than developed from scratch whenever needed.

Which is why ecom-ecologies emerge from contract negotiations.  It is 
not "discovery".  That is a rotten business model.  It is negotiation
and if 
the emerging registries such as OASIS or BizTalk are to thrive, it 
will be because they provide negotiation services for contracted 
performance.   Again, this isn't a catalog ordering site such as 
toysRUs but the full monty of big corporate projects with primes, subs, 
logistics orgs and all of that.  XML application languages are useful 
for this but only insofar as they provide predictable reliability 
figures (MTBF, MTTR, etc) and that is actually a component level 
statistic, not directly attributable to XML.

> We also
> need more and better tools, especially on the authoring side. The
> investment in getting an XML-based solution up and running is relatively
> high, and even the subsequent leverage that this provides will pay back
> this investment relatively quickly. There's a real risk that
> out-of-the-box solutions will appear that provide only a portion of the
> potential added value of XML but are so easy to implement and deploy
> that they edge more powerful approaches out of the market. Something to
> be scared about.

I think we will get all of that, but we are already seeing a crack the
whip 
dilemma in tools development.  That makes me more uneasy because unless 
I have component level statistics for reliability, I am back exactly
where 
I started:  pick one vendor and stick with them; justify XML by
lifecycle 
costs and avoid it for short lifecycle, non-aggregating information.

ln


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)