RE: Brave new world

["William J. Kammerer" <wkammerer@foresightcorp.com>]

To Stephenie Cooper:

Spelling names is rarely a problem for me, as I hardly ever make
assumptions - I merely select and copy the name of the person I'm
responding to out of their own e-mail.  This solves innumerable
embarrassing problems; as a vendor, I must be sensitive at all times.
It also keeps me from inadvertently calling a William "Bill" unless
there were really something terribly wrong with Ctrl-Insert. Even for
Rachel Foerster, whom I know well, I still copy and paste, because
otherwise that last name would throw me for a loop. A name, especially a
good name, is very precious to the wearer in our culture - undoubtedly
in most cultures.   Only for those standard, generic white-bread names,
like that of my good friend Boob Miler's, would I type out directly from
memory.

To Arofan Gregory:

Processing speed certainly has much to do with the size of messages,
though it's not so much to do with the "verbosity of XML."  It's the
temptation to be explicit for everything, even that which can be
inferred, which vastly adds to bulk and effort to consume.  For example,
sending all IDs and descriptions in a product order, when a single
UPC/EAN code would suffice (assuming catalogs are available).

As an extreme example, see http://www.igml.org/, where under
"recombination of igML guidelines," we discuss why igML renditions of
EDI implementation guidelines are maintained as "deltas" rather than as
a full copy of a guideline.  The missing parts of an EDI guideline can
be filled in from the base X12 or EDIFACT standard dictionaries, so
there's no need to carry all that bulk in the igML message.  This, of
course, means that a simple XSLT script would not be able to directly
render the igML message as an understandable and readable EDI
implementation guideline;  instead logic has to be applied to
"recombine" the igML "delta" with a full EDI standard, whether in a
database or in an igML file in it's own right.  Unfortunately, if what
you say is true and XSLT can't even do a simple one-for-one matchup of
code mnemonic to its description, then I would doubt it's suitable for
the more complex logic of recombining guidelines with standards.
Instead, our sample program demonstrates the process in C++ and the DOM.

In many cases, a re-engineering of the process will actually result in
*SMALLER* XML documents than the files they replace!  By using the
"delta" approach in building igML guidelines for all objects (not just
text, as we had done before), our igML exports from the EDISIM product
are significantly *SMALLER*, and *FASTER* to process than the equivalent
SEF (Standards Exchange Format) files.  In this context, the size of the
XML element tags is almost irrelevant.

Re: your note to Margaret Pemberton about SOX and polymorphic
capabilities of schema-based XML.  This is great stuff - Object-oriented
programmers (and the UML modelers) would probably love it.  But is
polymorphism included in the W3C XML Schema?    I assume inheritance
would be.  In any event, the oo-EDI work in UN/CEFACT TMWG has probably
examined this same kind of stuff.  And an ordinary person like
Margaret - who "need[s] to learn more about XML"  - can immediately see
the benefit of defining a PO Ack in terms of many of the same objects as
used in a PO;  this would eliminate a good deal of bulk in the X12 and
EDIFACT manuals, and greatly simplify maintenance and ensure consistency
of the standard messages themselves.  And yes, the heartbreak of similar
but one-off maps will be ameliorated in well designed mapper software
using oo-EDI.

But ultimately, regardless of polymorphism, the same problems will still
exist (as in EDI) - namely that of back-end integration - which was
Margaret's main point.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"