OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: ebXML header extension mechanism proposal

Agreed. I have (as has Nikola) been trying to lobby for
lowerCamelCase since I cannot remember. I say we bite the
bullet and make any change now. 

Note that SOAP (XP) uses lowerCamelCase for attributes and
for elements. 

I would also suggest that while it will be easier if we choose
the mustUnderstand attribute, that we still REQUIRE a specific
usage mode to ensure interoperability of the infrastructure itself.


"Burdett, David" wrote:
> I think this is a good idea but I think I would go for "mustUnderstand"
> rather than "mayIgnore".
> On another point in the current DTD attributes are Upper Camel case rather
> than lower camel case (e.g. DeliverySemantics) we need to be consistent.
> David
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Thursday, November 30, 2000 6:03 AM
> To: ebxml-transport@lists.ebxml.org
> Subject: ebXML header extension mechanism proposal
> 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
org:Sun Microsystems, Inc;XTC Advanced Development
title:Sr. Staff Engineer
fn:Christopher Ferris

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC