OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: proposal: collapse To and From elements


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC