Re: proposal: collapse To and From elements

[Christopher Ferris <chris.ferris@east.sun.com>]

Charlie,

See my response to Sanjay. 

Cheers,

Chris

Charlie Fineman wrote:
> 
> Errr.... correct me if I'm wrong, but I don't believe Prasad is advocating a
> seperate Party element, just seperating the element's VALUE (from the
> element's attributes).
> 
> Assuming for the sake of argument that Chris' proposal carries the day. To
> get multicast support, why couldn't we just have multiple <To> elements in
> the message header? Is that against the style guidelines?
> 
> -----Original Message-----
> From: Patil, Sanjay [mailto:Spatil@netfish.com]
> Sent: Tuesday, December 12, 2000 4:34 PM
> To: 'Prasad Yendluri'; Christopher Ferris
> Cc: ebXML Transport (E-mail)
> Subject: RE: proposal: collapse To and From elements
> 
> 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
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
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard