Re: Now some feedback on Header v0-63

[Joe Lapp <jlapp@webMethods.com>]

Thanks, Chris.  My comments are inline below...

At 11:26 PM 8/4/00 -0400, Christopher Ferris wrote:
>> 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 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. 

Yeah, this is one of the intended purposes of xsi:type.  But it's also
consistent with the use of types in most programming languages, especially
with the notion of an enumerated type.  XML Schema even has the notion of
an enumerated type.  You can think of type as representing a class of
names.  The names need not have structure, although I suspect that some of
the 'context's people might want would actually proscribe some lexical
structure.

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

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

Right, a URN is a name.  But a name can represent a node.  I was wondering
what the required properties of the referent might be.


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

I think we said the same thing here.  The XML namespace defined in section
3.1 is the URI you have given.

This brings to mind another potential issue.  The spec states that the root
element must have an attribute named "xmlns."  Yet, the "Namespaces in XML"
spec states that the following two syntaxes are logically equivalent:

<root xmlns="someURI">
<n:root n:xmlns="someURI">

So we should probably try to divorce the definition of the vocabulary from
its representaiton in an instance.  For every element name, we should
probably say what namespace that name belongs to and what local name it
has.  This is as easy as saying generically that all element type names
defined in the document belong to a particular namespace.  Alternatively,
you could use the colon notation.  Any given instance can choose between
using the default namespace shortcut and explicitly including a namespace
prefix.

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


Yeah.  You know that people will insert their own headers.  We should
probably do something to help minimize the resulting interoperability pain,
even if we can't completely eliminate it.

- Joe