[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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" <email@example.com> To: "ebXML Transport (E-mail)" <firstname.lastname@example.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"
Powered by eList eXpress LLC