Re: [wsrm] comments on ws-r 1.05

[Christopher B Ferris <chrisfer@us.ibm.com>]

Tom,

comments on the ws-r schema at: 
http://www.oasis-open.org/committees/download.php/7109/ws-reliability-1.1.xsd

The schema defines two base types, HeaderBaseType and ExtensibleType, 
which allow for
attribute and element wildcards. For simplicity, I'll simply list the 
ExtensibleType definition:

        <xsd:complexType name="ExtensibleType">
                <xsd:sequence>
                        <xsd:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
                <xsd:anyAttribute namespace="##other" 
processContents="lax"/>
        </xsd:complexType>

And then these types are derived by extension, as in the case of 
RequestType:

        <xsd:complexType name="RequestType">
                <xsd:complexContent>
                        <xsd:extension base="wsrm:HeaderBaseType">
                                 <xsd:sequence>
                                        <xsd:element name="MessageId" 
type="wsrm:MessageIdType"/>
                                        <xsd:element name="ExpiryTime" 
type="xsd:dateTime"/>
                                        <xsd:element name="ReplyPattern" 
type="wsrm:ReplyPatternType"/>
                                        <xsd:element name="AckRequested" 
type="wsrm:EmptyType" minOccurs="0"/>
                                        <xsd:element 
name="DuplicateElimination" type="wsrm:EmptyType" minOccurs="0"/>
                                        <xsd:element name="MessageOrder" 
type="wsrm:EmptyType" minOccurs="0"/>
                                 </xsd:sequence>
                        </xsd:extension>
                 </xsd:complexContent>
        </xsd:complexType>

In the spec, the graphic in figure 6 suggests that the element wildcard 
content follows the wsrm:MessageOrder element
when in fact, it actually precedes the MessageId element according to XML 
Schema which only supports extension via appending.
The note in section 2.2.1.3 of XML Schema Part 1 reads:

        NOTE: This specification allows only appending, and not other 
kinds of extensions. This decision simplifies application processing 
required to             cast instances from derived to base type. Future 
versions may allow more kinds of extension, requiring more complex 
transformations to effect 
        casting. 

Either the spec or the schema should be modified to correct this 
inconsistency. Also, I am puzzled as to why the formal prose and tabular
definitions of the elements for this spec do not identify those elements 
which are extensible via element and/or attributes.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295