Re: proposal: collapse To and From elements

[Scott Hinkelman <srh@us.ibm.com>]

William says "some compatibility between RN and ebXML might be desirable".
I say "compatibility between RN and ebXML is desirable".
With all of the efforts/products emerging within the related space of
ebXML, I increasingly believe
that enabling RN with ebXML is important for ebXML traction.
My view is that if it decreases RN enablement on ebXML, don't change it.

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"William J. Kammerer" <wkammerer@foresightcorp.com> on 12/13/2000 08:40:51
AM

To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:
Subject:  Re: proposal: collapse To and From elements




Chris:

The example I gave mimicked somewhat the example in RNIF V2, where they
use DUNS all the time, but still they had an internal routing gimmick;
some compatibility between RN and ebXML might be desirable.

<Party> should specify IDs which would be known to the transport
mechanism (like URLs; or in the case of VANs, TP IDs in the form of
DUNS, etc.)  Even though a TP might want all messages to go to the same
MSH using a known ID, the recipient may want to separate messages
according to business function or unit, without looking inside the
payload documents, once the message arrives within their firewall. Most
importantly, the Internal Routing specification may be known only to the
sender and receiver, and VANs or software in between may have no idea
how to interpret the Internal Routing - they can only carry the data
along in the message header.  I suppose <ServiceInterface> and <Action>
could be used for this particular culling, but my point was there could
be some additional junk we discover that needs to added to <To> and
<From> , and if they're collapsed now, graceful ways of extending them
will be precluded.

Internal business units certainly can be identified with DUNS+4 (and X12
and EDIFACT make allowances for this), but DUNS+4 is far more likely to
be exchanged between business partners as application data.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Memorial Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"Commerce for a New World"

----- Original Message -----
From: "christopher ferris" <chris.ferris@east.sun.com>
To: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Sent: Wednesday, December 13, 2000 7:28 AM
Subject: Re: proposal: collapse To and From elements


William,

I'm not sure what you mean by "pretty". No one ever said
angle brackets were "pretty";-)

You do raise an interesting point. However, isn't
this sort of "internal" routing supposed to be
addressed with DUNS+4 (assuming that DUNS is used as
a Party identifier)?

Cheers,

Chris

"William J. Kammerer" wrote:
>
> What if some day you wanted to add internal routing specifications to
> either the <From> or <To> specifications, à la RosettaNet's (V2)
> optional <locationID> within <PartnerIdentification>?
>
>  <To>
>       <Party context="uri">urn:duns:123456789</Party>
>        <InternalRouting>Columbus office</InternalRouting>
>  </To>
>
> I suppose <InternalRouting> could be made another attribute of the
newly
> "collapsed" <To> and <From> elements, but...
>
> Also, I've got a gut feel against having different leaf-node elements
> which are a whole lot like other elements (even if they're easy enough
> to define in a schema).  If and when we ever got Core Component Design
> Rules, would the type of collapsing described by Christopher Ferris be
> considered pretty?
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Memorial Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "Commerce for a New World"