[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Wildcard elements and attributes
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC