RE: proposal: collapse To and From elements

["Burdett, David" <david.burdett@commerceone.com>]

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