Re: proposal: collapse To and From elements

[Henry Lowe <hlowe@omg.org>]

I agree with Scott.

Best regards,
Henry
-------------------
At 10:11 AM 12/13/2000 -0600, Scott Hinkelman wrote:
>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"
>
>
>
>
>