Re: ebXML header extension mechanism proposal

[Matthew MacKenzie <matt@xmlglobal.com>]

I very much support having an extension mechanism such as you suggest,
my only comments are related to the implementation of the extension
mechanism.

How about something like this:

<element name="ebXMLHeader" type="ebXMLHeader"/>
  <complexType name='ebXMLHeader'>
    <element ref='Manifest' minOccurs='1'/>
    <element ref='Header' minOccurs='1'/>
    <element ref='RoutingHeader' minOccurs='0' maxOccurs="1"/>
    <element ref="ExtensionBag minOccurs='0' maxOccurs='*'/>
        ...
  </complexType>

Of course,  the same separation can be accomplished using namespaces -
I would just prefer it this way to keep the messages uncluttered.
Namespaces could still be used in either instance.

Cheers,

-Matt

christopher ferris wrote:

> All,
>
> This issue seemed to get lost in the discussion surrounding
> the test/production indicator...
>
> I'd like to formally resurrect the issue of adding in an explicit
> extension mechanism to the ebXML headers to allow for
> headers such as test/production flag, security credentials (S2ML
> and/or XSignature), session context information, transaction context
> information (ie. XAML) and others which are considered
> "infrastructure" as opposed to "application" specific.
>
>   e.g.
>
>   <!ELEMENT ebXMLHeader (Manifest, Header,
>         RoutingHeader, ANY)>
>
>   or
>
>   <element name="ebXMLHeader" type="ebXMLHeader"/>
>   <complexType name='ebXMLHeader'>
>     <element ref='Manifest' minOccurs='1'/>
>     <element ref='Header' minOccurs='1'/>
>     <element ref='RoutingHeader' minOccurs='0' maxOccurs="1"/>
>     <any minOccurs='0' maxOccurs='*'/>
>         ...
>   </complexType>
>
> with the addition of something along the lines of
> mustUnderstand and possibly actor attributes defined.
>
> Of course, I would suggest that to ensure interoperability
> of the ebXML platform, that instead of mustUnderstand that
> we adopt the opposite semantic of 'mayIgnore' for extensions
> which a receiver is unprepared to handle. Thus, the only
> value of mayIgnore (which would be an optional attribute)
> would be 'true'. Of course, we could use the 'mustUnderstand'
> attribute name and require that the only valid value
> which MAY be used is 'false' and achieve the same semantic
> meaning.
>
> Extension headers MUST be namespace qualified, which means
> that we would need to allow for an arbitrary list of
> xmlns qualifiers in the ebXMLHeader element.
>
> I think that at the very least, we need to allow for future
> formal extensions to ebXML MS (version 2.0) which would
> need to allow for backwards compatibility with version 1.0.
> Thus, we'd need to support this manner of extension feature
> in version 1.0.
>
> Comments encouraged.
>
> Cheers,
>
> Chris