Re: proposal: collapse To and From elements

[christopher ferris <chris.ferris@east.sun.com>]

I certainly think that this is a valid scenario.

Cheers,

Chris

"Burdett, David" wrote:
> 
> Do you think it is possible to do multi-cast with the To containing a name
> which represents a list of names, e.g. "ebxml-transport@lists.ebxml.org"
> which then results with mutliple messages on the wire with separate
> ReceiverURI addresses for each recipient.
> 
> David
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, December 12, 2000 6:01 PM
> To: Patil, Sanjay
> Cc: 'Prasad Yendluri'; ebXML Transport (E-mail)
> Subject: Re: proposal: collapse To and From elements
> 
> Sanjay,
> 
> In that event, you wouldn't be agreeing with Prasad.
> Prasad wanted to preserve the element content (#PCDATA)
> as separate from the context attribute.
> 
> As to multicast, the point of the To element is to be
> a "logical" address/identifier. Thus, the concept of
> a multicast "alias" (ala email) could be implemented.
> 
> In any event, we can always extend in a future version
> to permit multiple To elements if that turns out to
> be our multicast addressing scheme.
> 
> Cheers,
> 
> Chris
> 
> "Patil, Sanjay" wrote:
> >
> > I agree with Parasad. Keeping the Party distinct
> > as an element will also retain the ability to specify
> > multiple <To> recipients if needed for multicast,
> > etc in future. Of course, this will require a change
> > in the Header type definition, but the change would
> > be smoother.
> >
> > thanks,
> > Sanjay Patil
> >
> ----------------------------------------------------------------------------
> > ------------------------------
> > Work Phone: 408 350 9619
> > http://www.netfish.com
> >
> > -----Original Message-----
> > From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
> > Sent: Tuesday, December 12, 2000 3:45 PM
> > To: Christopher Ferris
> > Cc: ebXML Transport (E-mail)
> > Subject: Re: proposal: collapse To and From elements
> >
> > Chris,
> >
> > I like the second alternative, as it still keeps the value of the
> > element distinct from an attribute of the element.
> >
> > Regards, Prasad
> >
> > Christopher Ferris wrote:
> >
> > > All,
> > >
> > > I would like to submit a proposal to collapse the Party
> > > element within the To and From elements in the Header.
> > >
> > > In v0.8, the current To and From elements look
> > > like the following:
> > >
> > > <ebXMLHeader ...>
> > >   <Manifest/>
> > >   <Header>
> > >     <To>
> > >       <Party context="uri">urn:duns:blahblahblah</Party>
> > >     </To>
> > >     <From>
> > >       <Party context="uri">urn:duns:blahblahblah</Party>
> > >     </From>
> > >     ...
> > >   </Header>
> > >   ...
> > > </ebXMLHeader>
> > >
> > > What I propose is to collapse the To and From element
> > > content models to be attributes only. e.g.
> > >
> > > <ebXMLHeader ...>
> > >   <Manifest/>
> > >   <Header>
> > >     <To context="uri" partyId="urn:duns:blahblahblah"/>
> > >     <From context="uri" partyId="urn:duns:yaddayaddayadda"/>
> > >     ...
> > >   </Header>
> > >   ...
> > > </ebXMLHeader>
> > >
> > > Semantically, I'm suggesting no change whatsoever. However,
> > > there is a benefit gained in use of attributes in this
> > > particular case especially when using a SAX parser because
> > > as you are processing either the To or From element, the
> > > information (metadata really) about To or From is immediately
> > > available to you.
> > >
> > > In the current model, you would need to set the context to
> > > To or From and then drop down to Party at which point you
> > > then process the attribute (context) setting the context
> > > for that and then parse the text of the element.
> > >
> > > As an alternative, if we simply collapsed the To and From
> > > elements by promoting the context attribute to the To and From
> > > elements and then eliminated the Party element as follows:
> > >
> > >         <To context="uri">urn:duns:blahblahblah</To>
> > >         <From context="uri">urn:duns:blahblahblah</From>
> > >
> > > Either form works for me...
> > >
> > > Again, it reduces the number of steps involved in parsing
> > > the content (which would make it more efficient for processing!).
> > > I think that in general, having seemingly artifical containers
> > > to make the Header document more "human readable" is really
> > > unnecessary.
> > >
> > > Note that this change would not substantively change
> > > the spec itself since all of the semantic meaning is
> > > preserved unchanged.
> > >
> > > Feel free to tell me to faaagetaboudit;-) I'm just
> > > trying to help make the spec the best it can be. To my mind,
> > > the added <Party> element adds no real value and simply
> > > adds an additional (and IMHO unnecessary) 30 characters to
> > > each message.
> > >
> > > Comments?
> > >
> > > Cheers,
> > >
> > > Chris
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard