xml-dev - Re: XML: Still Just HypedWebStuff

[Len Bullard <cbullard@hiwaay.net>]

David Megginson wrote:
> 
> Len Bullard <cbullard@hiwaay.net> writes:
> 
> > 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.
> 
> Both statements are false: SGML and XML don't do much, and they don't
> cost much.

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.
 
> High-volume custom publishing systems, complex interactive databases,
> document management systems with word-level granularity, large
> customizable dynamically-constructed Web sites, and other such goodies
> *do* cost a lot, and they'd cost a lot with or without SGML or XML
> (you probably save a trivial amount because you can use OTS software
> for a few of the tasks).

Yes, but they don't cost as much as they used to.  With or without 
SGML/XML, the cost of these systems is coming down.  Why?  Economy of
scale 
mostly, plus, being able to buy a unified framework (eg, MS) for 
enterprise-capable deployment certainly helps.  The fact of the ubiquity 
of that framework makes it a lot cheaper to sell; the fact of the 
application of a unified lexical definition at every level of the 
system (eg, SQLServer to Client), makes it cheaper.  The fact that 
competitors such as Oracle support it as well make it cheaper.  The 
fact that they may do it in incompatible ways will certainly add 
cost back in, but the costs may be sustainable if the transforms 
are cheap enough.  We would like competition as well to reduce 
cost, but that one is a reliability problem.  

XML is part of the solution to getting TCO under control, but 
it also comes with a price and that price is high initially.

> That's not a bad thing, as long as people are building those systems
> for the right reasons (they need them) and not for the wrong reasons
> (they think that something about SGML or XML compells them to).

Need them?  Nothing about HTML compelled us to use it.  Why do we use
it?  
Economy of scale.  Hype and free software help, but the money only 
came once the economy of scale could be demonstrated.  Attaching a 
stigma to competitors helped, but that's business politics.  The W3C and
the 
HTML community have paid for that considering they have adopted the very 
tech they were actively stigmatizing.  We all have those moments.
 
> I'm really, really tired of people writing that XML is expensive.
> That's like saying that tires are expensive because you have to buy a
> Jaguar to put on top of them.

There is that training thing.  A Jag isn't a good example; such a 
poorly designed and overrated sports car.  Take a 
Porsche.  High performance, high cost.  Not drivable unless someone 
spends some time teaching one how to handle it.  Otherwise, a dangerous 
car to the driver and anyone they share a highway with.   The gas costs 
don't go up; the insurance does.  Bad business decision.

TCO (Total Cost of Ownership) is what one should look at to cost justify 
SGML/XML.  The costs on the front end, although better than they used 
to be, are still stiff.  Anyone who fields large COTS systems to large 
organizations (has a current successful product line) can't simply jump 
into XML.  There are skills, tools, the ever elusive mindshare, industry 
concepts and requirements expressed in requests for proposals, testing
for performance 
(load test IIS and watch where it breaks - it does break),
synchonization, 
security, and so forth to pay for.  By the time that is all worked out
and can 
pass a FAT, quite a lot of money has been spent.  Now, that reliability 
thing Gates is talking about is a fairly old problem where I learned 
SGML: Integrated Logistics Systems (ILS), and until it is solved at 
the component level, integrating very large systems remains problematic 
and XML remains tech hyped but unproven.  XML helps this problem only if 
the information shared can be proven valid independent of the
implementation 
of the component.  That DTD thing, easy.... but the components?

TCO comes down when reliable components can be spec'd, 
tested, shared, delivered and sustained.  The payoff of markup comes
when the views 
within an organization, across a contractually bound set of performing 
organizations, and across the lifecycle of the deliverable are
considered. 
The payoff is there, but it won't be unless the tech scales across both 
the views of the organization and the schedules, and the basis for 
negotiating records of authority are proven and shared.

Think Record Of Authority.  A Semantic Web is just more email without 
that concept.  Machines do not have "meaning".  They cannot make
agreements, 
or can they?  That one is the fun problem these days.

BTW:  arrays in schemas or let's drop the schemas and try something 
without religious beliefs in the design.  The well-formed schema 
concept has merit, so good; but the data structures need to be 
discussed openly.  Applications such as X3D have requirements for the 
arrays.

len


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)