RE: revised Header DTD, XSD and sample XML doc

[David Burdett <david.burdett@commerceone.com>]

Chris

Comments on your draft below.

David
PS Please note I am about to go on vacation for a week and will (probably)
be unable to respond to any emails in reply to this for around 8-10 days.

DOCUMENT LABEL
I'm not sure of the intended semantics behind this. It could be:
1. A string that identifies the structure and format of the content of
document (e.g. a namespace), or
2. The reason why the document is present, e.g. ebXMLHeader, PurchaseOrder,
ProductImage

I think it should be the latter rather than the former since it can be used
by the software processing the message to locate a particular part of the
message directly.

DOCUMENT ID
We also need to think about what to do if the payload in the message is a
multi-part Mime message and we want to refer to one of the parts ... how can
you do nested references to a Mime part within a Mime Part within a ...

BUSINESS SERVICE INTERFACE
I'd prefer just SERVICEINTERFACE - see my July 20 email to Martin Sachs who
agrees that business is unneccesary. I think we want ebXML TRP to be used
outside of a business context and not just within it.

SHOULD ACTION BE A URI
I think that (Business) Service Interface Should be a URI and Action should
be a string that is unique within the Service Interface. The only reason to
make it a URI is if we (i.e. ebXML) want to define standard actions that
require specific behaviour by the recipient. Do we want to do this?

TPA Id vs TSLA Id
Following on from our conference call yesterday, I think that this should
refer to a transport level agreement ID rather than a complete business
partner to business partner agreement id. Alternatively it might be better
to allow either so that you can refer to a trading partner, business process
specific agreement that implies a transport level agreement or just to a
transport only level agreement specifically.

I'm also only happy with making TPA/TSLA Id mandatory if we agree that we
(ebXML TRP) will define preconfigured TPAs that can just be used without
negotiation of any kind and define only the transport characteristics.

CONVERSATION ID
This is described as "The unique identifier of the conversation (instance of
a TPA)". I don't understand this. An instance of a TPA is an instance of an
agreement between two parties. What I think this should say is "The unique
identifier of a conversation carried out under the terms of a TPA (or
TSLA)".

TIMESTAMP
This is defined as "The point in time at which the message was initially
sent". This is horribly ambiguous and is actually incorrect as it then goes
on to say ... "Subsequent retry delivery attempts for purposes of reliable
delivery should NOT modify this value" ... so the definition is wrong as it
isn't always the time the message was sent. I'd suggest that the definition
is changed to "The point in time at which the ebXML Message Header was
created" which, actually is what it really will be.

TPA ELEMENT
I'm confused ... the TPA Element is defined as ...

<!ELEMENT TPA  (TPAId , ConversationId , BusinessServiceInterface , Action
)>

... and is described as "This composite element contains the TPA specific
properties of the message".

If I saw an element called TPA, then I would expect to be the ACTUAL TPA.
This isn't its only the "TPA Properties" therefore it should be renamed
"TPAProperties" to be a more semantically accurate description of the
definition provided.

I also don't think that that TPA Properties is a very accurate description
of what is inside this element anyway. Because to my mind, the "Properties
of a TPA" implies that you are still describing the characteristics of the
agreement when we're not. What we're actually describing here are the
"characteristics of one message within a converstation carried out under the
terms of a TPA". So I think a better name would be "MessageCharacteristics"
or perhaps "MessageProperties". Think what we are describing here ...
a) the id of the ServiceInterface to which the MESSAGE is being sent
b) the Action which should be carried by the ServiceInterface that receives
the MESSAGE
c) the Conversation Id that relates this MESSAGE to other messages
d) the id of the TPA that is used to control all the MESSAGES within a
conversation as a whole

One thing I am certain of is that this is not a description of a Trading
Partner Agreement and we should not call it TPA.

Finally if we change TPA to something like MessageCharacteristics, then we
might want to think about merging it with MessageData.

DAvid

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Thursday, July 20, 2000 12:39 PM
To: ebxml transport; ebxml-poc@lists.ebxml.org
Subject: Re: revised Header DTD, XSD and sample XML doc


Oops! Thanks to Nikola for pointing out a problem
with the original set of examples. The TPA info
should all have been contained within a single
element. These attachments reflect the correct
structure as agreed to at the face2face in Burlington.

Please disregard the previous post.

Cheers,

Chris

>All,
>
>Since it will be Monday before I get the revised
>header spec distributed, here's the DTD, XSD and
>sample XML document for the ebXML header as it currently
>stands following the face2face meeting in Burlington.
>
>As always, comments are welcomed.
>
>Chris
-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903