[ebxml-cppa] Wildcard elements and attributes

Title: 

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">
  <complexType>
   <sequence>
    <element 
ref="ds:Signature" 
maxOccurs="3"/>
   </sequence>
  </complexType>
 </element>

 <element 
name="CollaborationProtocolAgreement">
  <complexType>
   <sequence>
    <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"/>
   </sequence>
   <attribute 
name="cpaid" type="tns:non-empty-string" 
use="required"/>
   <attribute ref="tns:version" 
use="required"/>
   <anyAttribute namespace="##other" 
processContents="lax"/>
  </complexType>
 </element>

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.

-Arvola