Benson:
I believe the problem is that you have defined an indeterminate
content model.  Essentially the problem is that the parser can't
tell which of the two definitions an element called "UserArea" should
match:

   <xs:element ref="UserArea" minOccurs="0"/>
or
   <xs:any namespace="##targetNamespace"/>

Because UserArea is in the target namespace >and< UserArea is >optional<, it 
might match either declaration.  (N.B. XML Schema 1.1 >may< fix this problem, 
but that's not published yet.)

To prove that, consider the following schema fragment, almost identical
to your original:

<xs:element name="Status">
        <xs:complexType>
                <xs:sequence>
                        <xs:element ref="Code" minOccurs="0"/>
                        <xs:element ref="Description" maxOccurs="unbounded" 
minOccurs="0"/>
                        <xs:element ref="Change" maxOccurs="unbounded" 
minOccurs="0"/>
                        <xs:element ref="UserArea" minOccurs="0"/>
                        <xs:any namespace="##other" processContents="lax"/>
                        <xs:choice minOccurs="0" maxOccurs="unbounded">
                                <xs:any namespace="##other" 
processContents="lax"/>
                                <xs:any namespace="##targetNamespace"/>
                        </xs:choice>
                </xs:sequence>
                <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:complexType>
</xs:element>

The only difference is that there is a line right before your choice:

        <xs:any namespace="##other" processContents="lax"/>

This line disambiguates the possible sequence of items.
Likewise, if you redeclare UserArea as

        <xs:element ref="UserArea"/>

the problem goes away.  However, if you define UserArea as

        <xs:element ref="UserArea" maxOccurs="unbounded"/>

the problem comes back, because it's not clear which UserArea is the last
one to match the element.

I'll note for those using XML Spy (which I do) that my XML Spy Enterprise 
Edition version 2004 rel. 3 doesn't report the problem correctly.  You have to 
use Xerces or XSV or some other tool to find the problem.  I hope they'll fix 
this soon.

Best regards,
David Ezell

-----Original Message-----
From: Benson Cheng [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 04, 2004 1:39 PM
To: [EMAIL PROTECTED]
Subject: Schema question: xs:choice


Hi All,

Xerces reprots this error on the follwoing element, I know why, but I
don't how to fix the schema, does anyone know how fix this schema?

- Error:
cos-nonambig: "":Code and WC[""] (or elements from their substitution
group) violate "Unique Particle Attribution".


- Element
<xs:element name="Status">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="Code" minOccurs="0"/>
   <xs:element ref="Description" maxOccurs="unbounded" minOccurs="0"/>
   <xs:element ref="Change" maxOccurs="unbounded" minOccurs="0"/>
   <xs:element ref="UserArea" minOccurs="0"/>

   <xs:choice minOccurs="0" maxOccurs="unbounded">
    <xs:any namespace="##other" processContents="lax"/>
    <xs:any namespace="##targetNamespace"/>
   </xs:choice>

  </xs:sequence>
  <xs:anyAttribute namespace="##other" processContents="lax"/>
 </xs:complexType>
</xs:element>

Thanks,
Benson.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to