RE: Brave new world

[Arofan Gregory <arofan.gregory@commerceone.com>]

William:

To you first point about verbosity, I think there are cases where only
sending deltas may be appropriate, but that for ease of processing -
especially when little can be known about your trading partners, and the
retrieval systems for earlier documents that you would like to assume have
been archived (as in the case of an SME, where the archive might be a
print-out of a web form or an XML file saved on somebodies' C-drive) - it is
generally a good idea to repeat information. XSLT *can* do code translation
- it's just not a good way to do it, in my opinion. I think it assumes that
- again, particularly smaller TPs - would be able to manage a local store of
translation tables from codes, which wouldn't be a reality *unless* we
provide a really-easy-to-use reference mechanism, presumably accesible
through a simple URL over the internet for any "standard" code lists.
Generally, however, its easiest to send the whole thing, with spelled-out
tags.

This places the burden on using smaller tags and designing information so
that its not redundant. I've played with these approaches with xCBL
test-beds (during our stress tests) and we could get good performance when
we optimized the documents (default values specified on the header, with
only exceptions to defaults in the line items, etc.)

As to your second point, I think we are looking at a new kind of
"standardization" that *does* make back-office use of semantic constructs
easier: context. If you have a processable set of context rules, explaining
each diff from the standard data sets, and giving the utility of the change,
then "dumb" automated systems can be built to understand the relevant
behaviours to apply to these unexpected bits of data. One of the context
axis that we've talked about is (for want of a better word) "teleology" or
"Purpose", and another is "Processing Function". With this kind of
information, you could compare *your* reuse of standard infomation
components with someone else's to determine why they have extended the
things they did, and what to do with them (drop them on the floor, return
them as-is, or send them on a workflow for approval, etc.)

This is an aspect of ebXML Core Components design that is not specified in
W3C Schema (although local re-naming of types is, which basically supports
polymorphism), because it is the real new material coming from ebXML. I
think we need to look more at these applications, and try to come up with
sufficient context hooks to support this kind of high-end application.

This is the big thing that sets us apart from a group producing "just
another set of mesages".

Cheers,

Arofan Gregory 

-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: Wednesday, July 12, 2000 10:12 PM
To: ebXML Core
Subject: RE: Brave new world

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"