Re: [wsrm] adding extensibility to the empy type

[Doug Bunting <Doug.Bunting@Sun.COM>]

Tom,

Yes, this would provide better extensibility.  The immediate question is 
where we need to allow such extensibility?  I doubt every element needs 
this support though it is definitely necessary for more than just our 
top-level SOAP headers.  I see little use for this in (for example), the 
MessageId and SequenceNum elements but they can be defined easily without 
relying on EmptyType.

To go a bit further, I would define three general element types for use 
throughout the schema, EmptyType, ExtensibleType and HeaderType (or 
something similar), and use those as appropriate.  EmptyType should be the 
type of our simplest "pseudo Boolean" elements and never extended. 
HeaderType would be the base for our four SOAP header elements. 
ExtensibleType would be the base of all other elements which are extensible 
(it could also be the base for HeaderType); elements which are not 
extensible or empty would be defined without an explicit base type.

Less importantly and more generally (about the schema as a whole and a long 
standing question I have forgotten to ask), this model puts all extension 
content (new elements) at the beginning of the WSRM elements.  This is 
counter-intuitive though I realise it comes from the use of schema type 
extensions rather than consistent placement of xsd:any at the end of every 
"interesting" complex type.  For example, an extended MessageHeader would 
(today) appear as:

   <wsrm:MessageHeader soap:mustUnderstand="1">
     <foo:bar letsGoToTheBar="yeah" />
     <wsrm:MessageId ... />
     <wsrm:ExpiryTime ... />
     <wsrm:ReplyPattern ... />
   </wsrm:MessageHeader>

rather than something that appears extended:

   <wsrm:MessageHeader soap:mustUnderstand="1">
     <wsrm:MessageId ... />
     <wsrm:ExpiryTime ... />
     <wsrm:ReplyPattern ... />
     <foo:bar letsGoToTheBar="yeah" />
   </wsrm:MessageHeader>

Should we change our choice here?

This also reminds me of another schema nit: Why is the existing extensible 
type (the one with the required soap:mustUnderstand) named wsrm:RmBaseType, 
I thought we nuked all of the "Rm" prefixes?  I purposefully chose 
HeaderType above to work around this complaint.

thanx,
	doug

On 20-Feb-04 12:09, Tom Rutt wrote:

> Would the following change to the empy type provide better extensibility 
> for the protocol?
> 
>   <xsd:complexType name="EmptyType">
>        <xsd:sequence>
>            <xsd:any namespace="##other" processContents="lax" 
> minOccurs="0" maxOccurs="unbounded"/>
>        </xsd:sequence>
>        <xsd:anyAttribute namespace="##other" processContents="lax"/>
>    </xsd:complexType>
> 
> The above prosal adds extensible attributes and elements , without the 
> soap must understand attribute which is there for header elements.