Re: Rudie ebXML Requirements

[Mike Rawlins <rawlins@metronet.com>]

More of my responses, labeled MCR 2, to Don's responses to my comments on his
requirements.

"Rudie, Donald" wrote <snipped>:

> -----Original Message-----
> From: Mike Rawlins [ mailto:rawlins@metronet.com
> <mailto:rawlins@metronet.com> ]
> Sent: Wednesday, January 05, 2000 12:45 PM
> To: List, ebXML Requirements
> Subject: Re: Rudie ebXML Requirements
>
> Don, thanks for raising some very good points.  As with many of the
> discussions
> we've had, I find people offering solutions as well as requirements.  What I
> would like to do with this note as well as some of the others is to try to
> distill specific requirements from your concerns, and identify issues for
> discussion.   When discussing specific requirements we need to be aware of
> scope
> issues and have some ideas about the impact of satisfying them.  However, it
> is
> mostly beyond the scope of our project team to recommend specific solutions
> to
> requirements.  That is what the other project teams will be doing, and we
> will
> have quite enough to do just dealing with requirements.
>
> "Rudie, Donald" wrote <snipped>:
>
> > >
> > > General Comment
> > >
> > > We heard a lot of comments about this being useful for the SMEs,
> however,
> > > I think that unless its also useful for the BEs (Big Enterprises) or LEs
> > > (Large Enterprises) it won't go very far.  BEs have to deal with other
> BEs
> > > and SMEs simultaneously.  Since the majority of BEs are already heavy
> EDI
> > > (X12 or EDIFACT) users, they have to be able to operate in that mode
> while
> > > they are trying to branch out and reach SMEs that may come up fresh
> using
> > > XML.
>
> I think most of this is covered by what I called scalable implementations -
> it
> should work for SMEs as well as large enterprises.  The other might be
> covered
> by maximizing interoperability with current EDI standards.  Don, do these
> cover
> what you are trying to express here?
>
> DDR Comment
>
> Mike, No.
>
> The basic requirement here is that when the BE/LE expands their trading
> partner base for the traditional EDI partners to partners using ebXML
> standards (probably SMEs) they want some assurance that the information
> content and the manner of expression is the same.  That is, they will
> receive (in their application system) the same data element definition, code
> values, semantics from the SME that they receive from the BE/LE.
>
> The processing logic in the application system should not depend on the
> source of the data -- EDI or XML.
>
> For example, the purchase order for a widget from a BE/LE using EDI should
> contain the same information content, etc. as a purchase order for the exact
> same wedget from an SME created according to the ebXML rules.
>
> This flows on to data element definitions, code values, versioning, legal
> requirements, etc.
>
> It seems to me that unless we state this as an ebXML requirement the BE/LE
> who understands this won't use or endorse ebXML.

MCR 2 - Don, I think I understand better what you mean.   Part of the confusion
here (including mine) is "semantics about semantics".  At the basic level, we
have mostly equivalent semantics in X12 and EDIFACT.  That is, if we identify
the business meanings (in actual usage) of the various components then we have
roughly the same set of meanings.  The problem is that within each standard
there are multiple ways to present that meaning, i.e., many different choices
for encoding that information into an X12 transaction set or EDIFACT message.
In other words, X12 and EDIFACT are riddled with synonyms.  That's fine for
spoken language, but quickly gets very awkward for computers.

I agree with your basic requirement, but I see possible complications when it
comes to code values.  Again, we don't have to come up with the solution within
our group, but we may flag this as an issue for the full work group.

I'm not sure that "maximizing interoperability with existing EDI standards"
quite captures your concern.  It has more do to with application integration
than the interoperability, or automatically translating between formats.   Might
something like "minimizing cost impact of ebXML application integration in
traditional EDI environments" better capture what you are saying?

> > >
> > > ebXML Semantics
> > >
> > > The ebXML semantics should at a minimum cover the semantics contained in
> > > X12 and EDIFACT.  This is not to say that every X12 Transaction Set nor
> > > EDIFACT message be specified within ebXML -- only that one could if
> > > desired express the TS or message in ebXML.
>
> I see two distinct requirements:  One that ebXML semantics should
> incorporate
> all that is currently defined in X12 and EDIFACT.  This is a very tall order
> that greatly increases the scope of the ebXML effort.  How long has it taken
> to
> come up with current X12 and EDIFACT semantics?  The other again deals with
> maximizing interoperability with current EDI standards.
>
> DDR Comment
>
> I am not saying that we should start over, only that we should take
> advantage of the rich set of X12, EDIFACT semantics and state as a
> requirement that they be included in the ebXML semantics probably as a
> subset.  Hopefully we can find a way to expressing them by an "automated
> process".
>
> > >
> > > We may, however, have to be able to distinguish between X12 and EDIFACT
> > > semantics at the instance level.
>
> > >
> > > We may very well want to go beyond the semantic requirement of X12 and
> > > EDIFACT, however for our short term delivery we may want to use those as
> > > our baseline.
>
> If I understand correctly, you think we should maximize interoperability
> with
> both X12 and EDIFACT.  A solution to this might be supporting both, but that
> is
> in conflict with delivering a single standard.   Are you advocating that we
> develop a single set of semantics in the long term, and focus in the short
> term
> on ways to use existing EDI standards for semantics at the expense of
> maximizing
> interoperability between ebXML implementations?
>
> DDR Comment
>
> Back to my first point.  We should want to avoid (if possible) the situation
> where the "specifications/requirements" for an ebXML purchase order destined
> for an X12 oriented application system is different from the same ebXML
> purchase order for an EDIFACT oriented application system.

MCR 2 - I think the data requirements for a document will be driven by the
business process and application requirements, and not by a particular standard,
be it X12, EDIFACT, or ebXML.

>
>
> I realize that this is a tall order because of the differences between X12
> and EDIFACT, however, there are alignment activities taking place in the
> X12, EDIFACT world and our requirement for a single standard could build on
> that.
>
> Regarding your last statement do not see the focus on existing EDI standards
> as an expense of maximizing .. rather I see it as a way to jump start the
> process since we don't have to create off of the semantics from scratch.

MCR 2 - I think my concern is about most of the approaches to mechanically take
existing X12 or EDIFACT messages of any version and release and mechanically
convert them to XML.  This yields maximum interoperability with current EDI
implementations, but only further propagates the problems we have now with
interoperability between different EDI implementations.  This type of solution
means that we would have many different ways to present a single set of business
information in an ebXML document.  I would favor maximum interoperability
between ebXML implementations by enabling (as much as possible) a single way to
present the information.

>
> > >
> > > ebXML tag names
> > >
> > > It think we should try to use one set of tags to cover both X12 and
> > > EDIFACT semantics rather that one for X12 orientation and one for
> EDIFACT.
> > > We will need to distinguish content (e.g. code values), however, this
> > > should be specified higher up in the exchange or referenced somehow.
>
> This sounds more to me a solution than a requirement.
>
> DDR Comment
>
> I don't think so.  Making this a requirement will increase interoperability.

MCR 2 - Point well taken.  I think this is covered by my requirement for
maximizing interoperability (within ebXML) by using a common presentation.
Common presentation, in the case of XML documents, would include a common set of
tag names, common attributes, common structure, etc.

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/