Re: prototype proposal update

[srh@us.ibm.com]

Thanks Chris,
I have brought up versioning in the arch team in the past,
and circulated a sugested UML modeling packaging
initial suggestion for consistency across ebXML that
showed versioning. Versioning is on the list of discussion
in arch for Brussels.

|Does OTA parse
|the tag value for the appended 'RQ' to drive certain
|processing behavior? Wouldn't a specific element or
|attribute have been more convenient?

OTA debated the grammar structure issue (not yet talked about in ebXML from
what I can tell) and decided to concat the RQ. There are several
alternatives
but we agreed on this approach.

|Precisely! This is the message which ebXML Marketing should
|be repeating ad-nauseum to anyone who will listen. Of course,

Incorrect. Should be "This is one of the messages".

Scott R. Hinkelman
Senior Software Engineer
XML/Java Solutions/Standards
Architecture and Development
IBM Austin
Office: 512-823-8097 TieLine: 793-8097
Home: 512-930-5675, Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074



Christopher Ferris <chris.ferris@east.sun.com> on 05/04/2000 01:17:03 PM

Please respond to "ebXML-Transport@lists.oasis-open.org"
      <ebXML-Transport@lists.oasis-open.org>

To:   Scott Hinkelman/Austin/IBM@IBMUS
cc:   ebXML-Transport@lists.oasis-open.org
Subject:  Re: prototype proposal update




Some comments below.

Cheers,

Chris

srh@us.ibm.com wrote:
>
> Nick, good job on the demo doc.
> Here are some quick points:
>

<snip/>

>
> Industry (verticals, but a better term) Migration points to an ebXML
> Transport Infrastructure:
>
> 1) Industries would drop any industry-defined message type, such as that
> indicated
> by the "RQ" at the end of the original OTA <v1.CustProfileUpdateRQ> tag,
> and
> express this in the ebXML MessageType element. Note that OTA maintains
> using it's industry-specific approach to versioning the OTA intention.

Yuch! Possibly, something we would need to consider as
a value-add of ebXML is a specific versioning scheme
which makes sense (possibly, from the Architecture
or Core WG). Explore the potential maintenance
nightmare which would (IMO) be caused by a versioning
of the OTA vocabulary. One would have to update reams of code
to consume a v2.Xxxx because all of the $%^&^%$ tag names
have changed! Yikes, that sounds like built-in/hidden future
consulting fees if I ever did see such a thing;-)

NB. that SOAP v1.1 doesn't address versioning either
other than to stipulate that if the namespace is not
as specified, it must be a different version;-)

Our work should incorporate as an architectural
principal the inevitability of subsequent versions
and a migration strategy from one to the next with
minimal impact on systems implementing a predecessor.

> 2) Industries would load the ebXML payload with the remaining industry
> content. This
> would mean dropping any industry-defined 'method or intention' and
message
> type, such as the
> OTA <v1.CustProfileUpdateRQ> tag since this is to be defined in the ebXML
> header.

Possibly, but not necessarily. Again, this seems a rather
contrived approach to encoding intent. Does OTA parse
the tag value for the appended 'RQ' to drive certain
processing behavior? Wouldn't a specific element or
attribute have been more convenient?

> 3) Other infrastructure information accomodated by the ebXML Transport
> level defined
> by an industry such as the TimeStamp attribute
> from the original OTA top document element.........
> <OTA_v1 Timestamp="2000-04-25 12:54:55.0" EchoToken="228722"
> Target="Production" GeoCode="+4256-1482">
> should be removed (given the same semantic as the ebXML Transport) and
> expressed
> into the ebXML Transport headers. The OTA EchoToken is in the same
> situation
> because we can accomodate this in ebXML with the MID field that expresses
> the
> associated message Note we are not showing these in the demo.

I never would have guessed that EchoToken represented
a MessageID;-)

> 4) An Industry may need to maintain information important to the industry
> once
> defined in perhaps a top industry root element with in ebXML payload. The
> examples
> in the case of OTA are the the GeoCode and Target attributes on the
> original OTA_v1 top tag.
> These are now expressed within *what has now become the OTA payload top
> tag* :
> <OTA_v1 Target="Production" GeoCode="+4256-1482">.
> Note that the TimeStamp and EchoToken are removed since the ebXML
Transport
> supports
> the same semantics.

I was looking at RosettaNet again which also has an element
in its preamble header indicating the mode (test/production):

     <GlobalUsageCode>

I think that we should support this directly in the ebXML
message headers as well. It would serve the purpose for
enabling a test of an exchange between partners to ensure
compatibility, etc.

>
> A prime selling point that is evident in the demo of the ebXML Transport
> (not complete for all of ebXML):
>
> + The ebXML Transport level provides a cross-industry approach for
defining
> infrastructure
> constructs commonly defined by, or being defined by, industry-specific
> efforts. The ebXML
> Transport can free industry-level efforts from addressing
> infrastructure-level constructs for
> needed for commercial-level messaging.

Precisely! This is the message which ebXML Marketing should
be repeating ad-nauseum to anyone who will listen. Of course,
we need to make it a reality (or close to it) so that the
various verticals will adopt it as their own. We need
to be able to demonstrate that we're on track to deliver
something within the timeframes they require (yesterday).

>
> Nick, I can speek to the detail in Brussels if needed.
>
> Scott R. Hinkelman
> Senior Software Engineer
> XML/Java Solutions/Standards
> Architecture and Development
> IBM Austin
> Office: 512-823-8097 TieLine: 793-8097
> Home: 512-930-5675, Cell: 512-940-0519
> srh@us.ibm.com
> Fax: 512-838-1074