|
A few
points:
o Transformation is not only glue. It
offers a kind of proof of category.
o Transformation can be used normatively to
define membership.
o A standard format lowers the barrier to
entry. It does not necessarily
bring
down the total lifecycle cost or eliminate
transformation.
One reason EDI tools or any tools that
depend on the existence of a common format
solely
become expensive is because once into the actual application,
the
business rules can vary by contract and the system must account
for
the variations. Experience is, the variations are inevitable and
originate in many sources including the need to compete
by adjusting
terms
and conditions, eg, tradeoffs between costs and services,
customization, and so forth. It is
not "no size fits all" but
"no
size fits all comfortably".
We use
meta-languages to enable local adjustments. Even where a
vertical vocabulary exists as a layer, at the bedrock,
we have to
make
fit tighter or looser. XML + XSLT and so forth are ultimately
enterprise tailoring technology. We are
ultimately seamstresses.
We take out cost by our skill at fitting
the garment to the figure.
Len
http://www.mp3.com/LenBullard
Ekam
sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
Thus, the "XML Tower of Babel" that some lament,
while others point out that it's the transformations that count (as Claude
Bullard mentioned in a recent post regarding an article: http://lists.xml.org/archives/xml-dev/200104/msg00758.html).
The truth is that even with EDI technologies, having the transformation tools
was critical. It's just that with those tools, the transformation technology
was proprietary, very expensive, and cumbersome to work with, so the role of
standardized vocabularies was of comparatively greater value. If you could get
everyone to agree to a standard format, you could go with a cheaper toolkit
that only supported that format and alleviate a great deal of
cost.
| 
Cart
