Now some feedback on Header v0-63

[Joe Lapp <jlapp@webMethods.com>]

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?

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

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.

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.

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.

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