Ambiguous content model : the following particles overlap

[Binew.]

Hallo Zusammen,

ich habe noch ein Problem
und zwar bilde ich meine XML Logik in XSD Schemas ab.

Ein Regel ist beispielsweise dass folgende Suchkriterien angegeben
werden können:
<xsd:complexTyp e name="kundensuc heTyp">
<xsd:choice>

<!-- Beim Suchen von Hostpersonen sind der Nachname, Geburtstag
und Ort Mussfelder. -->
<xsd:sequence > <!-- Suche mit Name / Anschrift -->
<xsd:element name="vorname" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="nachname" type="xsd:strin g"/>
<xsd:element name="strasse" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="ort" type="xsd:strin g"/>
<xsd:element name="geburtsta g" type="datumTyp"/>
</xsd:sequence>

<!-- Für die Suche aus einer anderen APP heraus soll lediglich
der Nachname als Mussfeld definiert werden. -->
<xsd:sequence > <!-- Suche mit Name / Anschrift -->
<xsd:element name="vorname" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="nachname" type="xsd:strin g"/>
<xsd:element name="strasse" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="ort" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="geburtsta g" type="datumTyp" minOccurs="0"/>
</xsd:sequence>

<xsd:sequence > <!-- Suche mit Vertragsnummer -->
<xsd:element name="vertragsn ummer" type="vertragsn ummernTyp"/>
</xsd:sequence>

</xsd:choice>
</xsd:complexType >
Wir erstellen die XSD und XML mittels WSAD. Hier bekommen wir beim
validieren keinen Fehler. Lassen wir es aber über XML Spy laufen oder
den "Schema Quality Checker" ebenfalls IBM,
dann bekommen wir folgenden Fehler:
Ambiguous content model : the following particles overlap

Woran ligt das? Verstoßen wir hier wirklichgegen einen XSD Standard?

Vielen Dank für eure Hilfe...

[Soren Kuula]

[e-mail] wrote:

Hallo Zusammen,
Hi,
Ein Regel ist beispielsweise dass folgende Suchkriterien angegeben
werden können:
<xsd:complexTyp e name="kundensuc heTyp">
<xsd:choice>
<xsd:sequence > <!-- Suche mit Name / Anschrift -->
<xsd:element name="vorname" type="xsd:strin g" minOccurs="0"/> ....
</xsd:sequence>
<xsd:sequence > <!-- Suche mit Name / Anschrift -->
<xsd:element name="vorname" type="xsd:strin g" minOccurs="0"/> .... </xsd:sequence>
....
</xsd:choice>
</xsd:complexType >

Yes that is verboten.

XSD types must be such that you can determine every decision made at a
regular expression, as a document is being read, without having to
guess. In your schema, there's no way of telling from start, whether an
element sequence matches the first or second branch of your choice. In
fact, there is not way to tell AT ALL which branch is the one that must
be taken (an XSD validation must decide that, not just approve, because
it is obsessed with types and typing .. silly but true). If you have all
of vorname, nachname, strasse, ort, geburtstag, which one matches then ;) ?

You have to unify them both into one. Or kick out XML Schema and use
Relax NG.

Soren

[George Bina]

Ambiguity errors are generally resolved by
1. rewriting the content model in a non ambiguous way
2. relaxing the content model and place the constraints at some other
level

In your case your complex type can be rewriten in a non ambiguous way
as:

<xsd:complexTyp e name="kundensuc heTyp">
<xsd:choice>
<xsd:sequence >
<!-- Suche mit Name / Anschrift -->
<xsd:element name="vorname" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="nachname" type="xsd:strin g"/>
<xsd:element name="strasse" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="ort" type="xsd:strin g" minOccurs="0"/>
<xsd:element name="geburtsta g" type="datumTyp" minOccurs="0"/>
</xsd:sequence>
<xsd:sequence >
<!-- Suche mit Vertragsnummer -->
<xsd:element name="vertragsn ummer" type="vertragsn ummernTyp"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType >

Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

[Soren Kuula]

George Bina wrote:

Ambiguity errors are generally resolved by
1. rewriting the content model in a non ambiguous way
2. relaxing the content model and place the constraints at some other
level

In your case your complex type can be rewriten in a non ambiguous way
as:

Yeah I think I tried to say that ;)

(had they only defined that darn language as restrained-competition...)

Soren