At 2002-09-23 07:16, Maggiulli, Patrick G (Patrick) wrote:
Greetings,
I am seeking clarification on Unique Particle Attribution
as it applies to an XML Schema specification from ECMA for their
CSTA phase 3 protocol. ... When
invoked, the Xerces application reports the following error:
Error...
Message: 'callID and 'callID" violate the Unique Particle
Attribution rule.
On further investigation I concluded that the following complexType
definition in ECMA's XML Schema for call-connection-identifiers may
be the root cause of the problem:
<xsd:complexType name="ConnectionID">
<xsd:choice>
<xsd:element name="callID" type="csta:CallID"/>
<xsd:element name="deviceID" type="csta:LocalDeviceID"/>
<xsd:sequence>
<xsd:element name="callID" type="csta:CallID"/>
<xsd:element name="deviceID" type="csta:LocalDeviceID"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
I've some questions to ask, and I would be grateful to each of you
if you could help me find answers to them. My questions are:
1) Is the complexType above in violation of the Unique Particle
Attribution Rule, and if so, why?
Yes, it does. The UPA requires, in effect, that if someone
reads out to you a sequence of generic identifiers, then as
soon as they read one, you can point to the specific particle
in the content model which that generic identifier matches.
If the first element in the sequence is a 'callID' element, then
it's not clear whether it should match the particle created
from the first child of the choice, or the particle created from
the first child of the third child of the choice. This would
be crucial if the two definitions of callID had different
appinfo: the schema processor needs to know which appinfo to
supply.
Appendix H, Analysis of the Unique Particle Attribution
Constraint (non-normative), in XML Schema Part 1: Structures,
identifies reasons for Unique Particle Attribution Rule
violations but I need to identify the exact rule that is
being violated, and I am having difficulty doing so.
Hmm. The closest Appendix H comes is "A content model will violate
the unique attribution constraint if it contains two particles which
overlap and which ... are both in the {particles} of a choice" group.
The second callID particle is only indirectly in the choice group,
so I understand your confusion.
The exact rule being violated is the Unique Particle Attribution
Constraint itself. In the complex type definition as shown,
it is not the case that "the particle ... with which to attempt
to validate each [element information] item in the sequence in
turn can be uniquely determined ... without any information
about the items in the remainder of the sequence."
2) Is there a way to express a complexType for ConnectionID
above that allows (callID OR deviceID OR (callID AND deviceID))?
Yes. Here is one way, that corresponds to (deviceID OR (callID AND
OPTIONALLY deviceID)).
<xsd:complexType name="ConnectionID">
<xsd:choice>
<xsd:element name="callID" type="csta:CallID"/>
<xsd:element name="deviceID" type="csta:LocalDeviceID"/>
<xsd:sequence>
<xsd:element name="callID" type="csta:CallID"/>
<xsd:element name="deviceID" type="csta:LocalDeviceID"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
I hope this helps.
-C. M. Sperberg-McQueen
World Wide Web Consortium
| 
