Re: proposal: collapse To and From elements

[Prasad Yendluri <pyendluri@webmethods.com>]

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