W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2002

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

From: Stefan Wachter <Stefan.Wachter@gmx.de>
Date: Tue, 24 Sep 2002 10:24:36 +0200 (MEST)
To: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>;xmlschema-dev@w3.org
Message-ID: <23779.1032855876@www40.gmx.net>

Maybe you can just use an all-group.

--Stefan

> 
> 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 Tuesday, 24 September 2002 04:25:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:34 GMT