Re: ebXML header extension mechanism proposal

[christopher ferris <chris.ferris@east.sun.com>]

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
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard