Okay, as the wide-eyed XML optimist of this discussion, I'd like to chime in
on a few points.
1) XML is a local solution. What I mean by this is that most of the XML
Schema development that I have seen largely stops at the boundary of a given
company. XML, like X12, is largely a political affair, but unlike X12 what
this means is that people are beginning to recognize that one schema will
not "do it all" ... nor should it. X12 worked upon the predicate that you
could create a general domain "schema" that could be enforced from the top,
which resulted in a large number of exception fields in X12 formats for each
company. At first, people attempted to use XML in the same manner, but this
attitude has largely disappeared -- getting concensus at a level much higher
than say an industry vertical is difficult if not impossible, and with the
malleability of XML through the mechanism of XSLT and DOM, its largely
unnecessary. Yes, you end up with more schemas and more apparent
fragmentation, but this is a dynamic system; over time, those schemas that
best represent the largest group of agents will gain momentum, and those
that don't can readily be transformed into the survivors.
2) XSLT is the one element in the equation that I believe will make a
difference in the long run. Currently, I would agree that XSLT is cryptic,
difficult to understand, and there aren't a large population of users for it
yet. I however see that changing, and I've also noticed that its beginning
to gain a momentum that languages such as Java ran into early on. A
difference between Java and XSLT, however, is that the Java language is
largely being developed by a single company which has been inconsistent in
its status as a standard. XSLT, and the other XML technologies, ARE
standards, ones that are universally recognized and adopted. XML is fast
becoming the language of web communication, both in the back end and (to a
lesser extent) on the front end. As the Internet has become the backbone of
the current technological society, XML will likely end up becoming largely
ubiquitous over the next five years.
3) You bring up the issue of semantic standards. I have pored over the X12
specs for several companies, and seen just how truly "semantic" these
specifications are. Semantics and meaning are not easy concepts to bridge
in any computer language, but one of the characteristics of meaning is that
meaning is largely driven by context, not by specific tag designations. X12
enforced context by carefully scribing the boundaries of the standards,
while XML takes the opposite tack and works on the assumption that context
is largely a result of transformation of information. This is a view that is
beginning to gain credence among XML developers, and is one that can make
for very powerful and sophisticated applications without a huge amount of
programming.
4) Is XML a magic bullet solution? No, of course not. It simply provides a
grammar for common data interchange -- it is up to the participants in that
exchange for agreeing upon conventions between them. To just summarily say
that XML will solve all of your problems without understanding what those
problems are in the first place strikes me as an open recipe for disaster. I
would, however, argue that much of this discussion ignores the fact that XML
schemas are waiting in the wings. A schema is a powerful thing, though one
that most people don't really appreciate. With a schema, you can build in a
fairly high degree of context, of semantic meaning. Moreover, you make XML
data largely self-descriptive, which is something that DTDs currently don't
do terribly well.
5) The language is still in transition. Schema is necessary, a few of the
more fundamental standards such as XLink still need to be ironed out. In
many ways I see XML as being essentially a data language application for the
world, and we're about three years into a five year beta testing cycle.
Anyone who's tested beta software understands that you don't necessarily
build full applications on it, but you do start pilot projects to explore
how it may affect you and your company. Companies with an extensive
investment in EDI shouldn't think about switching over to an XML standard
overnight, but they should be exploring options for moving their new
projects into such a mode, exploring questions about legacy conversions,
sizing up the benefits and drawbacks of the language, training a few domain
gurus in the intricacies of the language. In the end, X12/EDI will be a lot
like COBOL: it won't disappear completely, but as fewer people work with it
and as software vendors support it less and less over time, it'll be largely
relegated to a legacy standard. Moreover, I suspect that you'll increasingly
see X12/EDI sitting behind an XML to X12 conversion, so that the older EDI
standards effectively disappear even when they are in use.
6) Finally, I want to address the combinatorial problem that you bring up --
how do you manage to support XML translations as the number of business
partners increase? I've actually thought about this one for a while, and it
occurred to me that this is actually not as major a problem as it sounds on
the surface. Consider this: I work with a trading partner using one schema,
and that trading partner works with another trading partner using a
different schema. What this means is that this partner essentially maintains
two translations -- one from your standards to his (which may be the same,
in which it is an identity transformation), and from his standard to the
third party. If I choose to work with this third party directly, I can
approach the second party about acquiring her translation, in which case I
have a transformation that consists of two other transformations. Moreover,
it increases the number of potential partners that I can work with that
don't require yet another schema translation. Thus you end up with the six
degrees situation -- the number of transformations required to move
information from one schema to another in a given domain stays relatively
low, since in the main transformations are associative. Additionally,
economic pressures will similarly force the number of transformations to
remain low, since it is in the best of interest of any company to work with
as few schema transformations as possible -- those that adopt wildly
divergent schemas will find that no one is interested in trading with them,
because of the cost of building the transformation.
-- Kurt Cagle
-- Author, XML Developer's Handbook, Sybex Press
-- Co-author, Beginning XML, Wrox Press
-- Co-author, Windows DNA, Wrox Press
-- XML Pro, Fawcette Publications
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
