Questions about the ebXML SOAP Extension Element Schema

[Ric Emery <remery@us.axway.com>]

Hello,

I have a few questions about the current version of the ebXML SOAP Extension
Element Schema. This email refers to -
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms-header-3_0-200704.x
sd  .

Earlier today I mentioned that the schema does not match ebMS Public Review
Draft 02 in regards to the "Timestamp" element. I also have found that the
schema does not match the PR Draft in regards to the ConversationId element.
The spec uses "ConversationId" the schema uses "ConversationID". In my
opinion the schema should be fixed.

I have noticed that the schema uses xsd:sequence in many places where I
would have expected xsd:all to be used. xsd:seqence forces an ordering of
elements that I do not think should be required. For example PartyInfo
requires that the From element precedes the To element.

    <xsd:complexType name="PartyInfo">
        <xsd:sequence>
            <xsd:element name="From" type="tns:From"/>
            <xsd:element name="To" type="tns:To"/>
        </xsd:sequence>
    </xsd:complexType>

Within UserMessage there is a specific ordering of MessageInfo, PartyInfo,
CollaborationInfo, etc.

    <xsd:complexType name="UserMessage">
        <xsd:sequence>
            <xsd:element name="MessageInfo" type="MessageInfo"/>
            <xsd:element name="PartyInfo" type="PartyInfo"/>
            <xsd:element name="CollaborationInfo" type="CollaborationInfo"/>
            <xsd:element name="MessageProperties"
type="tns:MessageProperties" minOccurs="0"/>
            <xsd:element name="PayloadInfo" type="tns:PayloadInfo"
minOccurs="0"/>
        </xsd:sequence>
        <xsd:attribute name="mpc" type="xsd:anyURI" use="optional"/>
    </xsd:complexType>



Is there a reason that we have made the schema strict in terms of element
ordering? While typing this email I went back and looked at the ebMS 2.0
schema, I notice that schema also enforces specific element ordering. So, I
suppose it is not a big deal. It just strikes me as unnecessary. Though some
of the examples in the PR02 draft do not validate because they do not match
the schema element ordering.

-ric