Re: revised Header DTD, XSD and sample XML doc

[Christopher Ferris <chris.ferris@east.sun.com>]

David,

Comments on your comments below.

Cheers,

Chris

David Burdett wrote:
> 
> 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.

Agreed. However, this reopens the question raised during the face2face
by Ian and John, should the BSI and Action be elements of the Manifest
or Header. There was considerable debate on this point, and I think
that we settled on having these items in the Header for simplicity
(KISS). Of course, this means that the payload items (if the payload
is multipart/related) need to be able to be understandable to the
processing software.

Placing BSI and Action on each DocumentReference element of the Manifest
would go a long way towards satisfying this requirement (IMHO).
Using DocumentLabel for this would be either redundant with Action
or would necessarily mean that the payload items were somehow
arguments to the 'Action'.

I'm reluctant to use of DocumentLabel as some key to the processing
software. DocumentType would be more to my liking in this regard.
That then raises the question as to whether we should 'promote'
the MIME type of each body part to the Manifest. Of course, if there
were multiple images (jpeg) then the type would be identical for
each, which wouldn't really go far enough to advise the software
as to what its purpose was (left wrist xray, right wrist xray, etc.)

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

I think that all of the parts are identified in the Manifest. Whether
we should support some manner of nesting is a good question. Possibly,
we should permit DocumentReference to contain DocumentReference. 

Possibly, we should rename DocumentReference to be PayloadReference
or simply Reference.

<!ELEMENET DocumentReference (DocumentReference+ | DocumentId, DocumentLabel, ...)+>

Just a thought worth considering. Let the structure of the Manifest
mirror the structure of the Payload.

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

I am in agreement on the naming of ServiceInterface, in fact, that's
what I had in my mark-up for the face2face. I think that
for now, we should leave it BusinessServiceInterface and coordinate
with BP WG on renaming that component of their model before we
change it to ServiceInterface.

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

I don't think that we should be prescriptive at this time. Let's
plan on discussing this in San Jose.

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

Let's discuss in San Jose. We may also have some valuable feedback from
POC teams on this issue.

> 
> 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)".

You missed Ian and John's preso @ the face2face. I think that the concept
is covered in either or both of Bruce and Phillipe's write-ups as well
as in the documents on TPAs circulated.

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

I'll be glad to clear up the definition phrasing. I don't see how it is 
currently horribly ambiguous.

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

Fine. I am not married to TPA as the top level element name. Anyone
else have an opinion?

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

I would think not.

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

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