[
Lists Home |
Date Index |
Thread Index
]
- From: Len Bullard <cbullard@hiwaay.net>
- To: Matthew Gertner <matthew@praxis.cz>
- Date: Thu, 25 Nov 1999 10:06:58 -0600
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@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)
|