RE: Jon Bosak's suggestion that xCBL be adopted as the ebXML Busi nessDocument framework

["Blantz, Mary Kay" <mblantz@netfish.com>]

Just one more comment...

The Excel spreadsheet is simply the vehicle we use to capture 
the information.  It is not the best, but Excel is something that
everyone involved had on their laptop computers.

The first step is a business process model.  Not always UML, I
admit, but a model of some sort.  Not a spreadsheet, and not an
EDIFACT dictionary or message.

I suggest reading the latest submission on CC Discovery and
Analysis.  We tried to spell out the steps to follow to 
discover CCs.  You always need to start with a model of the
business process.

Mary Kay


-----Original Message-----
From: Stuart Campbell [mailto:stuart.campbell@tieglobal.com]
Sent: Friday, March 30, 2001 4:00 PM
To: 'Gregory, Arofan'; 'ebXML Core'
Subject: RE: Jon Bosak's suggestion that xCBL be adopted as the ebXML
Business Document framework


Arofan

Maybe you want to take some of this off-line before we start a personal
takeover of the exploder so i'll be limited in my response

, but it has been done with xCBL, albeit not in an open environment.
***if its open and adds value then im happy

glib assertion that we can "auto-generate" schemas from what ebXML provides
will be true.
***Unfortunately the current CC syntax modeling technique appears to be an
excel spreadsheet - so this isnt a great start - i agree.  However, putting
ebXML to one side...if you have a strong methodology to make (UML) models
for business information sets, and you have a strong design on the shape and
structure of XML models (element, attribute argument etc) then you only need
a strong methodology to convert between the two.  Unfortunately there is a
lot of gaps here as far as ebXML is concerned but they are being filled and
no doubt they will be filled in the future whatever this holds.  However, to
say the whole process is glib is from my experience wholly wrong.  There are
several projects that prove this and i have already mentioned some

I suspect that many initial attempts will share the failings of attempts to
automatically translate the EDIFACT and X12 standards into XML: they abandon
many of the best features of the new syntax in order to accomodate the old.
We can do better than this, even if that involves some hand-crafting in the
meantime.
***Again i agree, to simply XMLise EDIFACT by putting tags around it serves
no one and most project like this now dont exist.  However, if you take eg
an EDIFACT message, reverse engineer it back to a model (fixing it as you go
for the earlier messages ) and then go from here for 500 messages - then
thats a great start.  Indeed for 'later' EDIFACT messages such as those in
health care they were already designed to be syntax independent from the
start

It may be we have to agree to disagree on this one: I think that xCBL
provides a strong basis on which to begin this work, and Jon Bosak and many
others have discussed the merits of this approach, and find it worth
considering. Probably nothing will be perfect, but I believe the proposed
approach is the best suggestion to date.
***I think you are right in the agree-to-disagree - but then again you are
slightly biased in this area :-).   However, this is not to say i think xCBL
is a bad thing, i just dont think the parts of it i have examined up to date
offer much above the underlying models of EDIFACT (however you do need a
little imagination in this area!!) and certainly in terms of its scope it is
minimal as the BP Business Process catalogue identifies - and thats just for
trade messages.  EDIFACT, X12 covers much more than just trade type aspects
but moves into legal, healthcare , stats etc etc etc.  No doubt xCBL could
address this but some already do.


Regards



STUART


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org