Re: proposal: collapse To and From elements

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

Agreed, or, as David and others have pointed out,
an aliasing scheme could be employed.

Regardless, we have not chosen to address multicast
at this time. I believe that all we need to ensure is that
we haven't precluded it in our design.

Cheers,

Chris

"Adams, Robert" wrote:
> 
> Style?  Who needs style?  But the DTD says there can only be one <To> and
> one <From> in the <Header>.
> 
> I also vote for the second proposal ("<To
> context="uri">urn:duns:blahblahblah</To>") because the value of the "To"
> should be the body of the element while qualifiers of the value should be in
> the attributes.
> 
> For multicast, we'd have to change the <Header> definition to allow one or
> more <To> elements.
> 
> -- RA
> 
> -----Original Message-----
> From: Charlie Fineman [mailto:fineman@arzoon.com]
> Sent: Tuesday, December 12, 2000 4:29 PM
> To: 'Patil, Sanjay'
> Cc: 'Prasad Yendluri'; ebXML Transport (E-mail)
> Subject: RE: proposal: collapse To and From elements
> 
> 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
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