XML: Still Just HypedWebStuff

[David Megginson]

Len Bullard writes:

 > Contentious, perhaps, but not false. It isn't what they do; it is
 > what we do with them and what that costs.  What we do can be done
 > many ways so why should large businesses consider moving away from
 > working solutions to solutions that require retooling?  Again, cost
 > justify it.

I don't think that systems get expensive just because people switch to
XML or SGML and keep on doing what they were doing -- the expense
almost always comes from trying to do something new.  XML and SGML are
flexible enough to piggy-back on top of existing systems where such
systems are available, but people almost always want to do something
different or to try a different way of doing it when they decide to
try XML or SGML, and that's where the cost comes.

To take one example, imagine that you're managing a custom publishing
project.  The standard non-SGML/XML way to do this is to assemble
fairly large components (sections, chapters, or whatever) using
relational databases (where the components are blobs) and/or
document-management systems (where the components are smaller
documents), and you've probably bought an off-the-shelf package that
does this.  If (say) you decide to use XML for the assembly templates
to make those templates system-independent (and reuse them elsewhere
in the system), you have only a relatively small integration problem
on your hands.

But ... and here's the catch ... you realize that with XML it is
possible to customize much further than you already are.  You read
books and articles and find out that you can customize at the phrase
or even the word level, like this (to take a silly example):

  <p>What <choice-group><choice loc="CA">colour</choice>
     <choice loc="US">color</choice></choice-group> is that?</p>

Wow!  That's a lot better than the blunt instrument that you have now, 
so you run ahead an invest a few $100K in an XML-aware DMS that may or 
may not scale to your user base and another $500K for a phase-one
implementation from an XML consulting house, etc., etc., and suddenly
you decide that XML is very expensive.

But you're wrong -- it's not XML that's expensive; it's the kind of
custom publishing that you're trying to do.  It's easy enough to demo
this sort of thing on my notebook with ten sample documents, a browser
and a couple of Perl scripts, but it turns out to be very hard and
expensive to implement in a high-volume, high-performance environment.
That's OK if you really needed that configurability, but if you
didn't, then it was either your inexperience or gullibility that cost
the money, not XML.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)