RE: ebXML header extension mechanism proposal

["Adams, Robert" <robert.adams@intel.com>]

I'd prefer "Extension" instead of "ExtensionBag" so the name implies the
semantics (like the other elements) instead of both semantics and syntax.

And "Extension" should be added to DocumentReference for per document
information (signatures, ...)

-- RA

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, December 01, 2000 5:17 AM
To: ebxml-transport@lists.ebxml.org
Subject: Re: ebXML header extension mechanism proposal


Matt,

Good point. Does anyone else have an opinion on this?

Cheers,

Chris

Matthew MacKenzie wrote:
> 
> 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