RE: Now some feedback on Header v0-63

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

Joe

Comments inline

David

-----Original Message-----
From: Joe Lapp [mailto:jlapp@webMethods.com]
Sent: Friday, August 04, 2000 4:04 PM
To: ebxml-transport@lists.ebxml.org
Subject: Now some feedback on Header v0-63


1)	Section 3.3 "DocumentReference" says that DocumentLabel contains a
"textual description."  This sounds like a human-readable explanation of
the document.  The example uses the description "PurchaseOrder" which looks
like a pre-defined term, not a human-readable description.  What is
intended here?  Is this a free-form field?

<db>I think it could be either. If ebXML TRP is being used in a highly
structured way then this field could be used: a) by a Business Process to
specify what "attachments" a message can validly have and give each one a
label that identifies the type, b) so that a recipient of a message can
locate an attachment of a specific type with certainty. On the other hand if
TRP is being used in a looser way then this field could contain a natural
language description. IMO I think we want to have two separate
elements/attributes that are used for each purpose separately. How about
DocumentLabel and Document Description where both could be optional.</db>

2)	Section 3.5 "From and To" says that From must be a URN, but it
doesn't
say what To is constrained to be.  Presumably this is also a URN, but it
should be stated. <db>Agreed></db>

Also, the verbage here is a bit confusing, since it
seems to be saying that the From identifier is simultaneously both a
PartyId element and a URN.  It's easy to infer what is meant, but it should
probably be more direct. <db>Also agreed></db>

3)	Section 3.5 "From and To" defines a 'context' attribute.  This
attribute
has the same purpose as the W3C XML Schema xsi:type attribute.  I'm
wondering whether we should be using this soon-to-be-standard way of
specifying content type instead of inventing our own.  There is no doubt
within the W3C XML Schema WG about whether xsi:type will make it into the
XML Schema standard, so I think it's safe to use.  BizTalk uses xsi:type
for exactly this purpose, even allowing xsi:type in its header entries.
The one drawback is that the value of xsi:type is a URI, which is
considerably less readable than the keywords ebXML might specify.  On the
other hand, it is considerably more extensible, since it doesn't require
ebXML to serve as a clearinghouse for all potential type names.
<db>Sounds a good idea to me - we should discuss in the F2F.</db>

4)	One more issue with section 3.5 "From and To."  Does the party URN
identify a business entity irrespective of the node or nodes on which that
business entity might reside, or does it identify a single node?  I suspect
that we mean to identify a node-independent business entity, since we're
restricting values to URNs.  BizTalk makes this distinction very clearly.
You can physically send a message to a named node and logically to a named
entity.  Perhaps this will be delegated to the associated TPA.  In any
case, it would be helpful to be able to read this section and know what is
meant independently of what other documents say.
<db>I'm not sure we need to restrict this to business entities since I can
imagine that TRP messaging could be used to send messages to places that
aren't easily identifiable as a business. This then raises the whole thorny
question of how you discover what the correct "From" or "To" should be, as
both the sender and the recipient of the message need to know this. You
could put this in the TPA, but you could also put the information in a
registry that could be searched. It's not clear to me what the "best"
approach would be.</db>

5)	Neither section 3.6 "TPAInfo" nor section 3.7 "MessageData"
identifies
the type of conversation in which the message partakes.  Does the TPA
instance correspond to exactly one type of conversation?  Will
RefToMessageId somehow provide this information?  Or will this be implicit
from the BusinessServiceInterface given?  Or do we need to add it?  BizTalk
has a process type identifier, along with a means for identifying a
sub-process or handle within that outer process.
<db>I think it should be separate. For example, RosettaNet also identifies a
PIPId, PIPVersion and an Activity for a similar purpose. I think that TPAs
can operate at a number of different levels, a non-exhaustive list might
include:
a) industry standard TPA for a business process
b) TPA agreed between two parties for all instances of all business
processes
c) TPA agreed between two parties for all instances of a single business
process
d) TPA agreed between two parties for a single instance of a business
process
e) Varying Transport level TPA parameters on a per message basis.
I'm very much torn between the simplicity of a single TPA that can just be
used in all communications between parties and my belief, that eCommerce
won't be that uniform and you will need to vary the parameters of the TPA to
meet individual needs and requirements and therefore some TPA type
information should be allowed in the header.
</db>

6)	Some statement should be made about the extensibility of the message
header.  Right now all header entries belong to the XML namespace defined
in section 3.1 "Root Element."  Are middleware applications allowed to
insert their own header entries to ride with the message?  I'm guessing
that ebXML won't be able to specify all the possible middleware
applications that may need to communicate with each other, that ebXML won't
be able to specify all the possible headers.  If we want this to be
extensible, we should say so and state a policy for extending the header.
The BizTalk/SOAP approach is to require that every child element belong to
some XML namespace (that every header entry belong to some namespace).
That way a middleware app can identify its own headers by namespace and
ignore everything else.

I'll be looking at Reliable Messaging v0-06 on Monday.  Where am I going to
find treatment of synchronous vs. asynchronous messaging?  I guess I'm
waiting for the Messaging spec.  Where can I grab the current draft?
Thanks!

- Joe