OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project


Tim:

I think there might be some confusion here. You are correct in pointing out
that this is duplicative of messaging fields, and that point has not been
lost on those doing the Generic Header project - alignment is key. The point
is that long before the message envelope has been created, and after the
envelope has been received and opened - some of the messaging information is
still needed by applications that *cannot* access the envelope information.
This is a very common problem, especially with tools such as EDI translators
that are now being equipped to handle XML (they always relied on the control
fields in the message). The idea is to have an optional, standard place to
put this data *in the message* should that be needed.

Melanie can probably better answer your questions, but I would point out
that this is not a business modelling concern - it is strictly mechanistic,
to accomodate the capabilities of tools and applications.

Cheers,

Arofan

-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Monday, February 10, 2003 6:24 PM
To: A Gregory
Cc: UBL-NDR; UBL LCSC; mkudela@uc-council.org
Subject: Re: [ubl-ndrsc] UN/CEFACT ATG "Generic Header" Project


I must admit to being confused by this.  I recognise the concerns that
EDIFACT folks might have about this data, but I am not sure that they
need to have any.  It is being tackled by the OASIS ebXML MS TC.

Either I missed soemthing here, or what you describe sounds to me like
the ebXML MS specification, which i think you will find covers the same
ground.

Therefore, my first reaction would be to suggest that rather than
re-invent this protocol we remain agnostic of it.

However, I would like to make a few observations and ask some further
questions, either of Arofan or Melanie....


A Gregory wrote:

>This is an incredibly common set of data - we found ourselves adding it in
>xCBL, and every other major e-business vocabulary lists this data,
typically
>as a set of attributes on the document-level element. It includes such
>information as who sent the message, who is receiving it, what business
>process it is part of (correlation IDs), and similar. It is very similar to
>some of the control fields found in EDI messages.
>
>

The reason that every major e-business vocabulary lists this data is
that they want to remain independant of messaging and transport
protocols.  The problem with this is that you establish  duplicate and
possibly conflciting data sets.  One of the strengths of the ebXML
framework is that is separates the 'business/core components' ,
'business processes' and the 'messaging, routing and transport'
protocols.  They do not overlap. Rather, they work with each other (but
do not rely on each other).

I must plug a ( :-[ ) reference for this comparison
(http://www.amazon.com/exec/obidos/ASIN/1861005903/qid%3D1044929975/103-7202
419-8491066).
 Specifically, chapter 15 compares EDIFACT control fields with ebXML MS
elements.

>The generic header project is standardizing the names and datatypes for
>these fields. It would be fairly simple to adopt the proposed standard, and
>fit this information in as a set of standard, optional attributes at the
>document level. (And I can guarantee that of we don't include this basic
>information in our version 1.0, we'll have requests to include it in our
1.1
>release...)
>
>
Isn't this a 'higher level' protocol?  doesn't it run the risk of
overlapping with others?  I think you will find that the ebXML MS spec
has mappings to the EDIFACT control fields (UNB-UNZ, UNG-UNE, and
UNH-UNT) - this is not accidental, those building the ebXML MS spec used
these (and the NASI counterparts ) as a basis for their work.

>Typically, these fields are used by translators that are communicating with
>a back office application, and which are capable of only performing the
>translation on a single XML document at a time. If the envelope information
>isn't present, then the translator has to make calls out to a database or
>other place where the envelope information is stored. This is often not
>possible, especially for users with less sophisticated systems, since a
link
>to the envelope received and opened at a corporate gateway doesn't always
>exist.
>
>
Again, what you decribe is the business proccess interface that is part
of ebXML  BP definitions.  Isn't this a CPP reference accessed from a
repository?

>Melanie and her group can supply materials describing the project, but I
>think it would be great if we could adopt this standard as a part of the
UBL
>library, and figure out how to implement it. At the very least, I'd like to
>add it to the agenda for discussion at the next NDR con-call.
>
>
I am all for unified standards , but i am not clear what problem this
project is addressing that ebXML isn't already working on.

Perhaps we can see the materials you refer to, and specifically how this
varies from that of the ebXML MS OASIS technical committee (ref:
http://www.oasis-open.org/committees/ebxml-msg/documents/ebMS_v1_092.pdf) ?

>Cheers,
>
>Arofan Gregory
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>

--
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC