Question

I have to describe a choice between multiple region types which all contain “coordinates”. Unfortunately it is not allowed to have multiple xsd elements with the same name – it does not matter if they are defined multiple times or just referenced to multiple times.

<xs:group name="Region">
    <xs:choice>
        <xs:group ref="tns:CircularRegion" />
        <xs:group ref="tns:RectangularRegion" />
        <xs:group ref="tns:PolygonalRegion" />
    </xs:choice>
</xs:group>

With the referenced groups:

<xs:group name="Coordinates">
    <xs:sequence>
        <xs:element name="Latitude" type="xs:integer" />
        <xs:element name="Longitude" type="xs:integer" />
    </xs:sequence>
</xs:group>
<xs:group name="CircularRegion">
    <xs:sequence>
        <xs:group ref="tns:Coordinates" />
        <xs:element name="Radius" type="xs:integer" />
    </xs:sequence>
</xs:group>
<xs:group name="RectangularRegion">
    <xs:sequence>
        <xs:group ref="tns:Coordinates" />
        <xs:group ref="tns:Coordinates" />
    </xs:sequence>
</xs:group>
<xs:group name="PolygonalRegion">
    <xs:sequence>
        <xs:group minOccurs="3" maxOccurs="12" ref="tns:Coordinates" />
    </xs:sequence>
</xs:group>

As “Latitude” and “Longitude” are referenced to multiple times, the validation process ends with an error (multiple definitions…).

Any idea how to solve this?

EDIT The error message (German) from “Liquid XML Studio 2012” validator:

Error Mehrere Definitionen des Elements ‘Psid’ verursachen ein
mehrdeutiges Inhaltsmodell. Ein Inhaltsmodell muss so gebildet werden,
dass während der Validierung einer Elementinformationssequenz das
darin direkt, indirekt oder implizit enthaltene Partikel, mit dem
versucht wird, jedes Element in der Sequenz zu validieren, wiederum
eindeutig bestimmt werden kann, ohne den Inhalt oder die Attribute
dieses Elements zu untersuchen und ohne dass beliebige Informationen
zu den Elementen im Rest der Sequenz benötigt werden.

In English (Google translate)

Error Several definitions of element Psid ’cause an ambiguous content
model. A content model must be formed such that during validation of
an element information sequence that is directly, indirectly or
implicitly contained particles that attempts to validate each element
in the sequence in turn can be uniquely determined without the content
or attributes of that item are required to investigate and without any
information about the items in the rest of the sequence.

Answer 1

The problem isn’t multiple references to the Coordinates group – the problem is a violation of the Unique Particle Attribution rule (described as deterministic in the XML spec; the description there is easier to understand).

This is because you have a choice between CircularRegion and RectangularRegion, but both begin with the same <Latitude> element (from Coordinates).
If you imagine trying to parse an xml document that has an <Latitude> element in it, the parser can’t tell if it’s from a CircularRegion group or a RectangularRegion group just by looking at that element. (It could if it looked further ahead in the xml, but that’s not allowed by the UPA rule). It’s a specific kind of ambiguity: more than one particle (part of the schema) can be attributed to that element, so it’s not a unique particle attribution.

---

The clearest solution to this is to wrap each of your choices in a unique element (e.g. <CircularRegion>, <RectangularRegion> and <PolygonalRegion>), by using complexTypes instead of groups.

However, I get the impression that you want the XML that your XSD describes (or would describe if it were allowed). A simple way to do that is to factor-out the common prefix e.g.

<xs:group name="Region">
  <xs:sequence>
    <xs:group ref="tns:Coordinates"/>                <!-- common prefix -->
    <xs:choice>
      <xs:element name="Radius" type="xs:integer" /> <!-- Circular      -->
      <xs:group minOccurs="1" maxOccurs="11" ref="tns:Coordinates" />
                                                     <!-- Rect and Poly -->
    </xs:choice>
  </xs:sequence>
</xs:group>

---

BTW: I tested your original XSD and my xsd parser (xmllint), and it worked fine, parsing xml matching each choice. It did not flag the UPA problem…. which is odd. Despite this evidence, I’m positive it does violate the UPA rule, and xmllint is at fault. Can someone confirm or refute this please?

I also tested my solution, and it also works.

EDIT removed the second level of ambiguity that @SebastianMauthofer pointed out in the comments.