RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen ericHeader' Project

["Burdett, David" <david.burdett@commerceone.com>]

Title: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG 'Gen eric Header' Project

See comments inline

David

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Wednesday, February 26, 2003 9:18 AM
To: Duane Nickull; Burdett, David
Cc: Assaf Arkin; tmcgrath@portcomm.com.au; MKudela@uc-council.org;
ebxml-dev@lists.ebxml.org; ubl@lists.oasis-open.org
Subject: RE: [ebxml-dev] Re: [ubl-lcsc] Re: [ubl-ndrsc] UN/CEFACT ATG
'Gen eric Header' Project

Comments inline.

Burdett, David wrote:
> The original use case for including the "header information" in the
> payload is to support some of the existing translation/mapping
software
> tools that can only handle one "document" at a time. They are unable
to
> support message information in a header and simulataneoulsy handle the

> document itself. Copying the information into a header in the document

> solves this problem. This is really no more than a different
> representation of the message information.
>
> But is this the right way of solving the problem?
>

The GH team has not been concerned that the GH solution is "the right
way" to solve all problems with interfacing the business application
with the remainder of the middleware stack. That is a religious issue,
and there are many sects professing to know the "right way." These
include CORBA, RMI, JMS, MQ, DCOM, .NET, and untold others. I personally
do not think it is very useful to worry about endorsing/describing all
those integration technologies.
<DB>I wasn't trying to. I was simply expressing one use case where a generic header can help.</DB>

I also question whether it will advance the real-world integration
situation by inventing yet another alternative to all those technologies
which is the ebXML "right way." I think that is a certain recipe for
impeding the deployment of ebXML solutions. Obviously the GH is a lower
budget way for integration through the file system and will be of
interest to those people interested in preserving their applications
while needing to dump their data into an XML format and down the stack,
over the wire, to their collaborators.
<DB>Again I was just providing a use case. I always think that having a use case is essential in judging whether or not any particular functionality is of benefit. I think that a generic header is of *some* use but by no means is it essential. It really boils down to deciding whether or not low budget ways of doing integration through the use of generic headers is a worthwhile feature. Personally I am of two minds.</DB>

So I think that David is really on a fishing expedition here. This is
not the "right" question to raise.
<DB>I'm not fishing I am just providing a use case.</DB>

> The questions we need to answer include:
> 1. Does creating a standard set of header information help? I think
> the
> answer is yes at it reduces development cost for *those instances*
where
> you have a business or technical need to do it.
>

It also allows a "syntax decoupled" approach to saying what minimally is
available for interfacing EDI/XML business document serializations with
the gory underworld of middleware stacks. It also seeks to define a
namespace and infoset for XML usage. Also a schema is a probable work
item.

> 2. Should such a header be a standard (optional) part of each message?

> I
> don't think so since in many cases it will not be needed at all

I don't get this, David.
If it is optional, doesn't that address your apparent objection that "in
many cases it will not be needed at all." I thought that was what
optional means...
<DB>There's a better way, see below.</DB>

One real worry is that people who insert the XML for GH be able to
extend their documents to insert the XML elements and still have the XML
document validate against their schema for the business document. That
could be taken care of at document design time by means of appropriate
construct for extensibility. But even if that small amount of
standardization fails, a local copy of a BOD/BIE unit could be made that
allows validation against that. So making provision for a GH extension
is a "nice to have" not a necessity.
<DB>Agreed. This has always been my view.</DB>

> 3. Should you define a standard way of including it in a message when
> needed? I think you should as sometimes you will need it. In this case

> handling it using XML Schema and its extension mechanism makes sense,
I
> think.
>

OK, I think I agree with this,  as I would save hacking on a local copy
of a schema in many cases as previously mentioned.

> Bottom line, message metadata information should normally go in the
> header and not in the document but a method of putting or copying the
> information into the message itself should be defined for use when
needed.
>

The data in a GH won't necessarily or even normally be copied into a
message SOAP header block itself. Translators would not do that, for
example.
<DB>Agreed, but how the information gets into the SOAP Header block is an implementation decision.</DB>