Regulating the XML Marketplace

[len bullard]

Paul Prescod wrote:
> 
> In many of XML's markets (unlike many of
> SGML's markets) the move to XML actually saves money in the short, medium
> and long terms. Traditionally SGML has only saved money in the long term.

Basically right.  SGML and SGML systems:

o  Were typically expensive to acquire and set up.  Lack of cheap 
tools (until SGMLS, IADS, etc.), lack of expertise (little training 
in the universities, mostly fueled by high-dollar aerospace/DoD 
efforts, homegrown, fed by the kindness of strangers).

o  Mired in the print technology of the time and forced to compete 
with WYSIWYG systems.  Saying markup could support objects was once 
considered a statement of *magic* and taken almost as seriously.   
Goldfarb and Rubinsky had to defend the idea that SGML could even 
support real hypertext.  The fights between the PostScript/LaTex 
and SGML communities were legends and some are still happening.  
See comp-text-sgml.

o  Forced down odd paths of development by requirements of the 
standards process that demanded any attempts to look at markup as an 
application of programming be disregarded.

o  Subject to the misguided rants of the HTML community that declared it
"too 
hard, too obtuse, too syntactically strange" (see TimBL) 

and so it goes.

XML is in a much better position to make the benefits of markup 
more profitable.  Will a killer app emerge?  Folks, that is like 
Elvis:  largely a context issue for a certain time when a certain 
realization takes hold.  Mosaic was not a great development to those 
of us who already had SGML-based, DTD-aware, stylesheet driven 
hypertext in 1992.  It wasn't.  When you remember just how 
few people did (check out the prices of hypertext browsers and 
authoring tools then), then the idea that a lot of folks already 
understand XML (they don't) is self-defeating. Still, I don't think it 
necessary to evangelize XML as much as it is necessary to get the 
language communities currently designing their next generation of 
languages and applications to use it.  XML's successful emergence 
will not come as the result of a killer app, but when a set of 
DIFFERENT XML applications interoperate, share information, and 
enable an enterprise to be more competitive.  That has been the 
goal for over fifteen years and you are much closer today to 
realizing it than ever.  Target the companies that have:

o  Data with long lifecycles (Still the biggest payoff)
o  Lots of little data pockets (aka, islands of automation) 
o  The requirement to dynamically create JIT documents 
o  The requirement to share those documents across organizational 
   boundaries without requiring *economic bullpens* (see 
   contractually bound communications and delivery of data)

The good news is the quiet revolution has been won and the 
emerging evolution has begun.  This isn't about new ideas.   
This is about cost-effective, sustainable implementations.  
Like SGML at its best, an XML application is successful when 
invisible.  So, Paul is right;  the secret is not the 
demonstration of XML.  It is the application of XML.

Y'all really need to decide what to do about architectures.  
They are critical.  Base enabling applications would surely 
help clean up the standards and that is a big favor to the 
next generation of software developers.  Ask me about the 
problems of the FedsPostCALS:  very little change in the 
data delivery and maintenance nightmares.  Real drag on the 
economy, that one.

len

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/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe 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)