Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML: Still Just HypedWebStuff
 David Megginson wrote: > > Len Bullard <cbullard@h...> 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
