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

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

[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