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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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

Subject: [ebxml-cppa] Wildcard elements and attributes

I just discovered that I have used invalid syntax for specifying the namespace constraint for wildcard elements under the CollaborationProtocolProfile and CollaborationProtocolAgreement elements.

The following introduction to Appendix A is incorrect:

To provide for extensibility, many of the CPP and CPA schema elements allow namespace qualified wildcard elements. These are defined in the form

 <any namespace="not ##targetNamespace not ##ds"

     processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

in the elements CollaborationProtocolProfile and CollaborationProtocolAgreement, and in the form

<any namespace="##other"

     processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

in the elements PartyInfo, SimplePart, Packaging, PartyRef, CollaborationRole, ProcessSpecification, Certificate, SecurityDetails, DeliveryChannel, Transport, DocExchange, OverrideMshActionBinding, and ActionContext. (The second form cannot be used on CollaborationProtocolProfile and CollaborationProtocolAgreement because their content models would otherwise be ambiguous, due to the ds:Signature element which can occur 0 to 3 times.)

Even though section 3.10.1 (The Wildcard Schema Component) in http://www.w3.org/TR/xmlschema-1 seems to suggest that any namespace can be excluded, section 3.10.2 (XML Representation of Wildcard Schema Components) is more restrictive and only allows the targetNamespace to be excluded, by setting namespace="##other".

In other words, the construct namespace="not ##targetNamespace not ##ds" is not legal (even though neither the version of XML Spy used by Dale and Peter nor an earlier version of XML Authority used by me flagged this as an error).

Section 3.10.1 in http://www.w3.org/TR/xmlschema-1 also states:

Wildcards are subject to the ambiguity constraints (Unique Particle Attribution (3.8.6)) as other content model particles: If an instance element could match either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.

One way to work around this problem is to wrap the ds:Signature elements by a tns:Signature element as follows:

 <element name="Signature">
    <element ref="ds:Signature" maxOccurs="3"/>

 <element name="CollaborationProtocolAgreement">
    <element ref="tns:Status"/>
    <element ref="tns:Start"/>
    <element ref="tns:End"/>
    <element ref="tns:ConversationConstraints" minOccurs="0"/>
    <element ref="tns:PartyInfo" minOccurs="2" maxOccurs="2"/>
    <element ref="tns:SimplePart" maxOccurs="unbounded"/>
    <element ref="tns:Packaging" maxOccurs="unbounded"/>
    <element ref="tns:Signature" minOccurs="0"/>
    <element ref="tns:Comment" minOccurs="0" maxOccurs="unbounded"/>
    <any namespace="other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
   <attribute name="cpaid" type="tns:non-empty-string" use="required"/>
   <attribute ref="tns:version" use="required"/>
   <anyAttribute namespace="##other" processContents="lax"/>

Please let me know if you have objection to this change. Please also note that I am following the example of the ebMS schema that whenever a CPP/A element allows wildcard sub-elements, it also allows wildcard attributes. (Tony: I intend to submit this change both in the spec and in the schema for the 1.10 draft.)

I hope we have time this Thursday to talk about the issue of what elements within the CPP/A schema should allow wildcard sub-elements and attributes.



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

Powered by eList eXpress LLC