RE: proposal: collapse To and From elements

["Patil, Sanjay" <Spatil@netfish.com>]

Charlie, you are right. Prasad was indeed not advocating
a separate Party element.

Now considering separate <To> elements for multicast 
scenario, would you prefer to have a wrapper for the 
multiple <To> elements in the interest of a good containment 
model. If yes, then leaving Party as a separate element inside 
<To> would serve the same purpose.

thanks,
Sanjay Patil
----------------------------------------------------------------------------
------------------------------
Work Phone: 408 350 9619
http://www.netfish.com


-----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