Re: How to Create an ebXML Order (EDI 850 transaction set)

[Duane Nickull <duane@xmlglobal.com>]

John Evdemon wrote:
> 
> How familiar are you with EDI and EDIFACT?  
>>>>
Fairly.  I agree that the 20+ years of EDI experience is too important
to ignore.

> > I am not a Cone cheerleader and xCBL has its' problems however we are
> > using it as a starting point.
> >
> Why start with something that contains known flaws?  
>>>>>
I didn't make these rules.  I just joined a WG that is in progress.  My
understanding is that they are specifically tackling a very small set of
all business documents just to PoC ebXML and get it right.  If all is
well in UBL land after the initial period,  the work will extend to
other documents.  There simply isn;t enough time to tackle everything
right now in one go.

FYI - we have talked about a small subset of xCBL,  not even the entire
range of xCBL documents to begin with.  As you point out,  the work is
fairly monumental and not tobe taken lightly.

I agree with the points you make on EDI. 
 
> Both approaches will result in the significant duplication of work that has
> already been completed.
>>>>>
There has to be work done to establish whether or not this is true.  IF
the work done in the UBL group results in a way to adopt EDI to
facilitate ebXML messaging, then the work is worth while.  The goals are
the same,  I think it is just being said differently.

> True, unless you use the XEDI approach.  XEDI supports a direct one to one
> mapping for any transaction, any version of X12 and EDIFACT.  There is no
> mismatch at the document level.  There is no dilution or loss of data.
>>>>
Throw in cXML and xCBl at a document level then try four way mappings.  
Gotcha!!!!

Seriously,  I haven't examined the document to document mapping using
XEDI but I understand that it has the same problems when trying to map
outside of the edi world.  Is that true?

> I'm a bit skeptical about this - I would expect the transformation to be
> strictly a machine to machine process.  Prompting a user to supply missing
> information for each transaction is not practical for an organization that
> may be processing hundreds of thousands transactions per day.
>>>>>
The human intervation is a last resort.  Installing Core COmponents on a
local machine means that we could also dictate a source for them.  For
instnaces of things like <MyName>,  I could specify to always use the
value of "Duane Nickull".  If the <MyName> element was required in a
target instance document,  the Components assembler module can call a
loca method to find a vlaue if the source document does not contain the
data.  This still yields an automated approach, even when there is a
mismatch in information.

The human resource should only be as an absolutely last resort.

> This sounds very thorough, but the XEDI approach provides EDI to XML (and
> XML to EDI) support for all transactions, all versions of EDIFACT and X12
> "out of the box" (no additional development required).
>>>>>>

Great.  Where can one view the XEDI document and mapping sets?  
 
Interestingly enough,  xCBL was built off of Simple EDI.

I favour garnering whatever epxerience we can from EDI for building
ebXML.  I think most people will agree that we can learn from the past
(good points as well as mistakes) so we all avoid making them in the
future.

Cheers
 

-- 
Duane Nickull, CTO - Founder
XML Global Technologies, Inc.
-----------------------------------
http://www.xmlglobal.com
http://www.goxml.com
http://www.xslt.com
-----------------------------------