Re: [Moderator Action] Unique Particle Attribution and ECMA's CSTA phase 3 XML Schema

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

Received on Monday, 23 September 2002 13:50:37 UTC