Lists Home |
Date Index |
- From: Len Bullard <firstname.lastname@example.org>
- To: David Megginson <email@example.com>
- Date: Fri, 26 Nov 1999 13:36:40 -0600
David Megginson wrote:
> Len Bullard <firstname.lastname@example.org> 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
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
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
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
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
(load test IIS and watch where it breaks - it does break),
security, and so forth to pay for. By the time that is all worked out
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
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
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
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
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)