Camel Case, WAS: RE: ebXML header extension mechanism proposal

["Burdett, David" <david.burdett@commerceone.com>]

I don't have strong views on upper vs lower camel case and since XP is
likely to use lower camel case and there could be eventual convergence with
XP, I suggest that we go for Camel Case - Chris - let's put this to a vote.

David

-----Original Message-----
From: christopher ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, December 01, 2000 5:16 AM
To: Burdett, David
Cc: ebxml-transport@lists.ebxml.org
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
UpperCamelCase
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.

Cheers,

Chris
"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