RE: Brave new world

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Margaret, Chris, and other Good People,

I don't especially like XML syntax.  But then again I don't like X12/EDIFACT
syntaxes either.  But I do observe that XML syntax, and associated XML-based
tools (e.g., XLINK, XSLT) provide a much richer capability than is provided
by the 'passive' EDI syntaxes.  A challenge of ebXML is to make effective
use of this capability to help solve the problems of which Margaret and
Chris speak.

I've imbedded some specific comments to both Margaret's and Chris's comments
below.

Cheers,
        Bob 

<Margaret>
the real problem is in the back end application being able to
understand, process and correctly (i.e. as the sender requires) reply to the
data received. In the real world, most senders and receivers are using
different applications, requiring and providing different pieces of data to
complete the required business process  - until everyone uses the exact same
process model, I cannot see how these problems can be resolved by "YET
ANOTHER STANDARD".

As an EDI consultant, I have always found that the technology of sending and
receiving message (whether they be UN/EDIFACT, X12, proprietary or even XML)
has been the easy part - getting the business data suitable for both ends of
the relationship has always taken the larger part of any implementation!! As
an example, what if the receiving application requires their own product
codes, delivery locations, whilst the sender has no way of converting these
from their codes. Or worse, the sender produces invoices of what has been
despatched at that time, while the receiver can only handle an invoice that
contains details for a single purchase order.

<MILR> As Chris also notes, the 'end-user' problems (both human and machine)
are the heart of the problem.  So how does ebXML help here?

1) I've noticed a trend of common business applications providing an XML
interface to their systems (import/export).  Likewise, DBMS's on which many
sutom applications are constructed are also providing XML interfaces.  As
one might imagine, these interfaces are rather straight-forward.  Just map
the stored data using the sotred internal data structures and names, and 
produce a simple DTD defining same.  That's a start, but it's not a
solution.

2) The XLINK XML tool provides an ability to 'extend' the DTD by providing 
additional relational links outside the DTD itself.  If ebXML establishes
the foundation for representing metadata, and XLINK provides the path from
simple DTD's etc. to that metadata, transformations can be developed and
automated
within the ebXML framework.  For major business applications, either the 
producers of these packages or third party vendors may find it beneficial to
provide such transformation products.

3) ebXML won't eliminate 'data mismatch' problems.  Traditional EDI could
not 
eliminate such mismatches either.  Given knowledge of these mismatches, XML
can provide automated supply/calculation of 'missing' information; 
automatic translation of mismatched data; and transformation from/to 
application data interfaces.  ebXML will help make this a more solvable
problem by providing a common framework.  Software developed on the ebXML 
framework may even eliminate the problem for some application classes.  

I must point out that other XML-based information exchange protocols (such
as 
BizTalk) could do the same thing - it's the capability of XML that provides
the power.  But if an application vendor has to support many XML-based
protocols, the cost of such services goes up and the availability of vendors
goes down.  That's why so many different companies are particiapting in the 
ebXML effort.

Bottom line on the 'big problem' is it will continue to be the 'big
problem',
but not near so 'big' as it was.

Cheers,
        Bob

----------------------------------------------------------------------------
---------
<Chris>

 
1. Setting up the communications links - direct, via a VAN or over the
Internet. These are all well known issues and easily resolvable.

<MILR> ebXML does not add 'yet another commlink standard', so it does not
make this problem worse.  The trend toward use of internet comm links is 
making this issue even less significant.


2. Getting your 'EDI' software vendor to support the standards and
communications you want to use - which is not too much of a problem. Just
pick someone who does what you need, and hope they keep up-to-date with new
developments. (For EDI, also read ebXML, BSI, BizTalk etc.)

<MILR>  Traditional EDI will likely be around for a long time yet.  The
multitude of XML based e-business message systems (e.g., RosettaNet) makes 
this problem bigger.  The vendor has many more 'standards' to consider; the
user may have more standards with which he must comply.
ebXML offers hope that this proliferation of XML-based e-business message 
systems will either converge toward ebXML, or at least develop automated
ebXML conversion capability.  Of course, if that doesn't hapen, ebXML has
simply added one more 'standard' to the existing pile.

3. Getting the data you want to exchange into or out of your business
process/systems. This is the biggie. If you have home-grown systems, you
will have to design and implement it all yourself. If you have a bespoke
package, you will need to get your supplier, if he still exists to do it,
and hope he already has something which will interface with your 'EDI'
software. If you have a standard package, then you have a better chance of
getting the vendor to have interfaces of some sort, though they will
probably be to your preferred 'EDI' vendor. If you have no business systems
( a very small business - what we call 'Fred in a shed'), then you will
have to struggle with some form of Web-Enabled interface.

     So what will ebXML do for us.

     For a start, it will replace the EDIFACT et al that we all know and
love with something more cumbersome and bandwidth hogging - let's replace
the three char segment tags and one char separators with meaningful text.
Not a problem, so long as the translation software gets updated.




     With suitable XSL we should be able to read it in a browser. Great, I
just spent years getting rid of all the manual labour of entering data from
paper orders - now you want me to do it from a screen.

MILR: XSLT provides much more than 'read it in a browser'.

     The key is automation. We need to be able to update our business
systems automatically, We need no delay and we need to be able to see what
has been updated. In short, we need PROCESSES integrated into our business
systems with standard exchange formats. The standards for the formats are
already there - EDIFACT etc. but what is being done by the package vendors
to build the interfaces and ensure that they are compatible. If you are
lucky, you might get Order Entry and Invoicing out of the box. Most likely,
you will have to either modify what they provide, or get an extension
written.

MILR: XML and its associated tools can provide much of what we need.

     Another exchange standard does not do a lot for us out here at the
sharp end. We need the package vendors to get together and agree on the
processes. Not just the obvious bulk data exchanges, but the those which
allow access and visibility of data between systems. Why shouldn't my
supplier see my stock levels and use them to control replenishment. Why
shouldn't my customers see how I am getting on with their order. The key to
improving business is integration between trading partners - openly, but
managed.

MILR: Application vendors have to provide some of what we need.  While this
is outside the scope of ebXML, a strongly established ebXML increases the
value to application vendors of such enhancements, as it addresses a wider
end user market.


Chris Hill
Technical Support Manager
AP Hydraulics Ltd