Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML: Still Just HypedWebStuff
 Matthew Gertner wrote: > > > Cost justify XML. > > This is interesting argument, but: > > 1) It is far from clear that XML solutions will have to be sold for less > because of "hyped perception of ease and ubiquity" 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. (Remember, this is just Us Chickens talking and exploring potentials; I can make a case for SGML/XML but that is coals to newcastle on this list.) I admit the power of branding, but as more services come online to differentiate on price or any other characteristic which the customer uses (eg: gotta have what kid says they gotta have), then buying customers with pricing is one way to increase the power of the branding. What the Kroger experience showed was that the online model was not necessarily good for business even if it was good for the consumer. XML won't be sold for less unless the TCO is less. There are still many markets where competition is based on barrier to entry. Having the press screaming is a double edged sword. It gets attention but it raises expectation and in revolution counter-revolution cycles, not meeting expectations is like dating a runway model and failing to have cab fare on the first date. My point is more that the platforms are unstable, XML can't fix that (SGMLers know the real misery of this because they don't blame the platform), and the folks who use XML need it hidden from them anyway. > 2) Do you really think that XML gives the same results as an RDBMS and > CSV? Yes. By the time any competent developer creates the function libraries for moving CSV around, they also develop the utilities to make it easy to do the necessary schema mapping. That is actually the hardest part and fact is, its not that hard. XML adds very little as a magic parse except in shrinking the number of parsers. > Just to give one example, if I have a PHP/ColdFusion/ASP/whatever > site delivering HTML and I suddenly discover that I need to support WAP > (or Ariba Network or PDF or...) I am forced to reimplement everything > and then maintain my two (or three or four) versions in parallel. If I > go for an XML-based solution, then much of my site logic can be drawn up > out of the RDBMS into the XML layer, and the step to the various > delivery formats is only a transformation away. Saving time means saving > money, how's that for a cost justification? Lousy. The transform can be done at the server before that middle tier is ever called. It is easy to do, done in the language the implementor is familiar with, requires little mapping to the tree, etc. IOW, it is just an extra layer of work as far as the implementor sees it. Downtranslation is downtranslation. When you are using recordsets, the structural model is already efficient, flat, and optimized. Pushing XML or CSV out is about the same. Where XML gets an edge is if the guy on the other end has only weakly agreed to names and membership. BTW, most contracts already read "you will use our COTS schema". > Nevertheless, there is a need for people to start implementing stuff and > establishing a community where schemas, stylesheets and the like can be > "discovered" rather than developed from scratch whenever needed. Which is why ecom-ecologies emerge from contract negotiations. It is not "discovery". That is a rotten business model. It is negotiation and if the emerging registries such as OASIS or BizTalk are to thrive, it will be because they provide negotiation services for contracted performance. Again, this isn't a catalog ordering site such as toysRUs but the full monty of big corporate projects with primes, subs, logistics orgs and all of that. XML application languages are useful for this but only insofar as they provide predictable reliability figures (MTBF, MTTR, etc) and that is actually a component level statistic, not directly attributable to XML. > We also > need more and better tools, especially on the authoring side. The > investment in getting an XML-based solution up and running is relatively > high, and even the subsequent leverage that this provides will pay back > this investment relatively quickly. There's a real risk that > out-of-the-box solutions will appear that provide only a portion of the > potential added value of XML but are so easy to implement and deploy > that they edge more powerful approaches out of the market. Something to > be scared about. I think we will get all of that, but we are already seeing a crack the whip dilemma in tools development. That makes me more uneasy because unless I have component level statistics for reliability, I am back exactly where I started: pick one vendor and stick with them; justify XML by lifecycle costs and avoid it for short lifecycle, non-aggregating information. ln 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
|
|||||||||
