Re: Now some feedback on Header v0-63

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

Joe/All,

Thanks for starting this discussion. Comments interspersed below.

Cheers,

Chris

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

Clearly this needs to be discussed in more detail. I think that David's
suggestion has metit. The DocumentLabel should identify the type
(e.g. PurchaseOrder). Adding an optional Description element would seem 
reasonable, but we haven't gotten into the optional elements just yet.
We should discuss at the f2f next week.

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

Agreed, I'll clear this up.

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

I'll clear this up as well. What is meant is that the To and From elements
are comprised of PartyId elements which are URNs. Thanks for the fb.

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

It does?!?!? I fail to see how you came to this conclusion. 
The context is not about type, but about context much as
one would consider a domain name as providing context for
a path or a package providing context for a class in Java.

The context attribue is intended to provide a context for the
value of the PartyId element. DUNS is not a type, it is a namespace 
if anythying. 

I actually have always prefered a more commonly recognised 
approach of use of an explicit URN or URI syntax.

I would be glad to discuss this at the f2f next week.

> 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

Who's going to read it? This is intended for machine consumption.

> 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

A URN is not a node, it is a name and nothing more. To quote RFC2141:
"Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces"

Like BizTalk, this is a "logical" address. I actually favor
an explicit URN which needs no Context attribute. e.g.
	<PartyId ref="urn:duns:1234567890123"/>

The intent is to have a URN which can be mapped to other namespaces
which might actually be URLs (since an URL is an URN). 

Clearly, this needs to be made more concise. We should discuss at the
f2f.

> 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

Basically, you would use the address (URL) in the TPA for the transport
protocol to physically send the message to its destination. 

Regardless, the intent here is to have an identifier which can be resolved
from a logical to a physical address using a mapping/resolution appropriate
to the "context" of the PartyId and the scheme of the physical transport.

> case, it would be helpful to be able to read this section and know what is
> meant independently of what other documents say.

I agree, we should firm up the language and agree to a normative approach
for use of these elements.

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

I believe that it does. Others may disagree. I know that there are and will
be more discussions on this as we move forward in our understanding and
definition of tpaML.

> 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

Actually, they belong to the default namespace, which is the ebxmlHeader
namespace http://www.ebxml.org/namespaces/messageHeader. We could explicitly
add an identifier to the namespace and namespace qualify all of the elements
and attributes (actually, attribute namespace is a bit trickier).

> insert their own header entries to ride with the message?  I'm guessing

We haven't discussed this yet. My preference would be to treat this
with caution as extensibility == non-interoperability in many cases.
SOAP's mustUnderstand is something which (IMHO) is likely to lead
to non-interoperability. 

> 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

I think that this deserves some discussion. The ebXML Header is intended
to be transport neutral. On this point, we all agree(I hope!). I think that we also 
need a clear and unambiguous statement that it is also intended to be 
middleware agnostic. Most cases of eBusiness message exchange will involve
DIFFERENT middleware (or none) software implementations at either party.

> 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

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