Re: proposal: collapse To and From elements

[Michael Joya <mike.joya@xmlglobal.com>]

I like this idea too. I like using attributes for optional or implied 
data in any scenario, mainly for parsing ease.


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


-- 
// mike.joya@xmlglobal.com
// XML Global
// POC Project Team - ebXML
// Vancouver, Canada
// 604.717.1100 x230