XML-Schema XSD: Attribut als keyref

[Kerstin]

Hallo,

ich bastele mir gerade ein XML-Schema zusammen. Da die Verwendung von ID und IDREF nicht den gewünschten Effekt bringt, habe ich mich für die Verwendung von unique, key und keyref entschieden. Mit unique und key kann man ja ganz einfach ein Attribut als Schlüssel setzen:
z.B.
<xs:unique name="PersonID">
 <xs:selector xpath="Person"/>
 <xs:field xpath="@PersonID"/>
</xs:unique>

In einem anderen Element soll eben dieses Attribut nochmal auftauchen undzwar auch als Attribut, aber als Referenz auf den erzeugten Schlüssel. Leider habe ich bisher noch nicht herausgefunden wie ich das anstellen soll und auch keine Hinweise im WWW dazu gefunden.

"Person" als Element angeben und dort dann die Schlüsselreferenz, das ist möglich:
<xs:element name="Bestellung">
 xs:complexType
  xs:sequence
   <xs:element name="Artikel" type="xs:string"/>
    <xs:element name="Person">
 <xs:keyref name="Person" refer="PersonID">
         <xs:selector xpath="Person"/>
   <xs:field xpath="@PersonID"/>
 </xs:keyref>
    </xs:element>
  </xs:sequence>
 <xs:attribute name="BestellungID" type="xs:positiveInteger" use="required"/>
 </xs:complexType>
</xs:element>

Die Frage ist also, wie ich einem Attribut, den Typ keyref gebe und dann auch auf den eigentlich Schlüssel referenziere?

Ich hoffe, ihr könnt mir helfen. Es wäre echt super, wenn das irgendwie gehen würde.
Gruß,
Kerstin

[Rouven]

Hi,

schau dir mal das Beispiel aus der Wikipedia an. Man trennt es einfach, wie bei einer Datenbank auch:
Schritt 1 = Attribut definieren, mit dem Typ den es nunmal hat, als z.B. integer
Schritt 2 = Verbindung zwischen dem Attribut und dem Schlüssel herstellen.

MfG
Rouven

[Kerstin]

Hi Rouven,

danke für deine Antwort. In meinem Beispiel oben hatte ich wohl vergessen das Attribut für PersonID anzugeben. Schritt 1 ist also klar, Schritt 2 macht mir eben Sorgen. Wo gebe ich das keyref an? Innerhalb des Elements in dem das Attribut definiert ist oder eine Ebene höher? Woher weiß der, dass genau das Attribut gemeint ist?
Die Wiki-Seite kenn ich, verwirrt mich aber fast noch mehr, weil das wieder mal nur Beispielfetzen sind :-(

Gruß,
Kerstin

[Rouven]

Hallo Kerstin,

sagt dir XPath etwas? Wenn nicht, damit macht man Abfragen entlang des XML-Dokument-Baumes. Und genau das ist es auch, was jeweils mittels "selector" angegeben ist. Du kannst also prinzipiell von einer beliebigen Stelle des Dokumentes eine andere ansprechen, du navigierst dich einfach durch den Baum, sei es von der Wurzel aus oder indem du von deinem aktuellen Knoten aus los läufst.
Du solltest den Verweis also da hinpacken, wo er semantisch auch hingehört. Zu _welchem_ Schlüssel er gehört findet er über den Namen (refer) raus. Welche Attribute er dabei abgleichen soll wird ihm mittels Pfad und Feldangaben beigebracht.

MfG
Rouven

[Kerstin]

sagt dir XPath etwas?

Klar, sagt mir XPath was und auch dass man sich eben damit durch den XML-Baum navigiert.

Stimmt, da fällt mir ein, da gibts ja auch ne Angabe für nen Attribut, irgendwas mit pfad/pfad[@attribut] oder so.

Muss ich gleich mal ausprobieren.

Danke. So langsam wird das Lichtlein über meinem Kopf immer heller :-)

Gruß,
Kerstin

[Thomas J.S.]

Hallo,

Schritt 1 ist also klar, Schritt 2 macht mir eben Sorgen. Wo gebe ich das keyref an? Innerhalb des Elements in dem das Attribut definiert ist oder eine Ebene höher? Woher weiß der, dass genau das Attribut gemeint ist?

Du möchtest eine einfache Prüfung auf Eindeutigkeit. Dabei muss du beachten, dass die Definition dieser Einschränkung dort passiert, wo es gebraucht wird. D.h. der Ausgangspunkt ist das Element unterhalb dessen diese Prüfung stattfinden soll, also z.B.:

<xs:element name="Bestellung">
 xs:complexType
 ...
 </xs:complexType>

<xs:unique name="PersonID">
  <xs:selector xpath="Person"/>
  <xs:field xpath="@PersonID"/>
 </xs:unique>
</xs:element>

Damit würdest du bestimmen, dass innerhalb von Bestellung jede Person, die über ihre PersonID identifiziert wird, eindeutig bestimmt sein sollte. D.h. es dürfen keine zwei Kunden mit derselben PersonID innerhalb einer Bestellung auftreten.

Hättest du:
<xs:element name="Bestellungen">
 xs:complexType
 ...
 </xs:complexType>

<xs:unique name="PersonID">
  <xs:selector xpath="Bestellungen/Person"/>
  <xs:field xpath="@PersonID"/>
 </xs:unique>
</xs:element>

würde dies dasselbe bedueten.
Ein <xs:selector xpath=".//Person"/> in diesem Konstrukt würde dagegen bedeuteten, dass in Bestellungen jede Person, die über ihre PersonID identifiziert wird, eindeutig bestimmt sein sollte. D.h. es dürfen keine zwei Kunden mit derselben PersonID innerhalb von Bestellungen auftreten.

Das ist also die eine Sache. Damit hättest du die Eindeutigkeit von Person sichergestellt.

Was du mit <xs:keyref name="Person" refer="PersonID"> erreichen möchtest ist mir nicht ganz klar.
Solltest du z.B. eine Struktur wie:
<root>
   <Bestellungen>
      <Bestellung ... >
       ...
   </Bestellungen>
   <Personen>
      <Person ...>
      ...
   <Personen>
</root>
haben, und aus einer Bestellung heraus sicherstellen, dass zu einer dort angegebenen Person tatsächlich eine Person aus Personen existiert, solltest du key und keyref verwenden.

Mit key würdest du ebenfalls eine Eindeutigkeitsbeschränkung (oder Identitätsbeschränkung) defineren, mit dem Unterschied, dass alle als Felder (xs:filed) genannte Knoten existieren müssen. Bei unique gilt, falls ein Feld (xs:filed) zwar definiert, aber der Knoten nicht vorhanden ist, wird der Selektor einfach ignoriert. key impliziert Eindeutigkeit, aber unique impliziert keinen key.

Bei obiger Sturktur könntest du ein key im Personen für Person anlegen, dann muss du aber diese im root mit keyref referenzieren, was im Sinne von XML-Schema zulässig ist.
--------------------------
<xs:element name="root">
 xs:complexType
  <xs:element name="Bestellungen">
   xs:complexType
    <xs:element name="Bestellung">
     xs:complexType
     ...
     </xs:complexType>
    </xs:element>
   </xs:complexType>
  </xs:element>
  <xs:element name="Personen">
   xs:complexType
    <xs:element name="Person">
     xs:complexType
      ...
     </xs:complexType>
     <xs:key name="PersonID">
         <xs:selector xpath="Person"/>
      <xs:field xpath="@PersonID"/>
     </xs:key>
    </xs:element>
   </xs:complexType>
  </xs:element>
 </xs:complexType>
 <xs:keyref name="PersonID2" refer="PersonID">
  <xs:selector xpath="Bestellungen/Bestellung/Person"/>
  <xs:field xpath="@PersonID"/>
 </xs:keyref>
</xs:element>
------------------------

Du kannst aber auch einen key im root auf Personen/Person defineren und diese  dann in Bestellung für Person referenzieren:
-------------------------------------
<xs:element name="root">
 xs:complexType
  <xs:element name="Bestellungen">
   xs:complexType
    <xs:element name="Bestellung">
     xs:complexType
     ...
     </xs:complexType>
     <xs:keyref name="PersonID2" refer="PersonID">
         <xs:selector xpath="Person"/>
      <xs:field xpath="@PersonID"/>
     </xs:keyref>
    </xs:element>
   </xs:complexType>
  </xs:element>
  <xs:element name="Personen">
   xs:complexType
    <xs:element name="Person">
     xs:complexType
      ...
     </xs:complexType>
    </xs:element>
   </xs:complexType>
  </xs:element>
 </xs:complexType>
 <xs:key name="PersonID">
  <xs:selector xpath="Personen/Person"/>
  <xs:field xpath="@PersonID"/>
 </xs:key>
</xs:element>
--------------------------------------

Grüße
Thomas

[Kerstin]

Du möchtest eine einfache Prüfung auf Eindeutigkeit. Dabei muss du beachten, dass die Definition dieser Einschränkung dort passiert, wo es gebraucht wird. D.h. der Ausgangspunkt ist das Element unterhalb dessen diese Prüfung stattfinden soll, also z.B.:

<xs:element name="Bestellung">
xs:complexType
...
</xs:complexType>

<xs:unique name="PersonID">
  <xs:selector xpath="Person"/>
  <xs:field xpath="@PersonID"/>
</xs:unique>
</xs:element>

Eigentlich möchte ich mit der Angabe von unique oder key sagen, dass die PersonID eindeutig sein soll, so dass man eindeutig sagen kann: Duffy Duck hat die PersonID 1 und nicht, dass plötzlich auch Daisy Duck die PersonID 1 hat.
Unter Bestellung soll nur eine Art Verbindung zur eigentlichen PersonID hergestellt werden -> also keyref (dachte ich jedenfalls). Dabei ist es egal, ob diese dort mehrmals auftritt. Eine Person kann ja auch mehrere Bestellungen auslösen.

Ein <xs:selector xpath=".//Person"/> in diesem Konstrukt würde dagegen bedeuteten, dass in Bestellungen jede Person, die über ihre PersonID identifiziert wird, eindeutig bestimmt sein sollte. D.h. es dürfen keine zwei Kunden mit derselben PersonID innerhalb von Bestellungen auftreten.

Achso, das ist damit gemeint. D.h. wenn ich die PersonID zwar mit key in Person angebe (oder sonstwo), diese in Bestellungen mit keyref referenziere, mache ich durch Angabe von .//Person diese eindeutig? D.h. es können nicht wie oben beschrieben 2 Personen die gleiche PersonID haben?

Das ist also die eine Sache. Damit hättest du die Eindeutigkeit von Person sichergestellt.

<xs:key name="PersonID">
         <xs:selector xpath="Person"/>
      <xs:field xpath="@PersonID"/>
     </xs:key>

Dieser key zeigt auf das Attribut PersonID in Person, richtig?
Damit ist jetzt sichergestellt, dass jede Person einen eindeutigen Schlüssel PersonID hat?

<xs:keyref name="PersonID2" refer="PersonID">
  <xs:selector xpath="Bestellungen/Bestellung/Person"/>
  <xs:field xpath="@PersonID"/>
</xs:keyref>

Dieser keyref zeigt auf das Element Person in Bestellungen/Bestellung, richtig? D.h. es muss ein Element Person unter Bestellung existieren? Kann ein keyref auch auf ein Attribut zeigen oder ist mit dieser XPath-Angabe gleich beides gemeint?

Ich möchte doch nur wie in meinen Datenbanken sagen: Person hat einen eindeutigen Schlüssel PersonID, der in Bestellung als Fremdschlüssel auftaucht, um referenzieren zu können, wer die Bestellung denn überhaupt ausgelöst hat.

Gruß,
Kerstin

[Thomas J.S.]

Hallo,

Eigentlich möchte ich mit der Angabe von unique oder key sagen, dass die PersonID eindeutig sein soll, so dass man eindeutig sagen kann: Duffy Duck hat die PersonID 1 und nicht, dass plötzlich auch Daisy Duck die PersonID 1 hat.

Dazu (d.h. wenn du nichts anderes erreichen möchtest) reicht unique und brauchst weder key noch keyref. [1]

Unter Bestellung soll nur eine Art Verbindung zur eigentlichen PersonID hergestellt werden -> also keyref (dachte ich jedenfalls). Dabei ist es egal, ob diese dort mehrmals auftritt. Eine Person kann ja auch mehrere Bestellungen auslösen.

[2] Das sagt mir aber, dass du deine Personen _nicht_ in <Bestellung> verwaltest, d.h. dass die Liste der möglichen Personen woanderes steht und du in <Bestellung> auf diese Liste referenzieren willst: d.h. du hast

1. eine Liste der Personen, in der du sicherstellst, dass keine zwei Personen dieselbe PersonID haben (kannst mit unique oder key machen)
2. eine Liste der Bestellungen, in der du sicherstellen willst, dass die Person die die Bestellung aufgegeben hat, tatsächlich eine Person aus der Liste der Personen ist (machst du mit keyref) und weil du bereits in der Liste der Personen die Eindeutigkeitsbeschränkung definiert hast, kannst du eben aus Bestellung/Person darauf referenzieren.

Nur: ich kenne die Struktur deines XMLs nicht, aber was ich bisher gesehen habe, legt nache, dass du eben keine Liste der möglichen Personen hast [3], sondern nur eine Liste von Bestellungen und dazu reicht wiederum --> [1].

Ein <xs:selector xpath=".//Person"/> in diesem Konstrukt würde dagegen bedeuteten, dass in Bestellungen jede Person, die über ihre PersonID identifiziert wird, eindeutig bestimmt sein sollte. D.h. es dürfen keine zwei Kunden mit derselben PersonID innerhalb von Bestellungen auftreten.

Achso, das ist damit gemeint. D.h. wenn ich die PersonID zwar mit key in Person angebe (oder sonstwo), diese in Bestellungen mit keyref referenziere, mache ich durch Angabe von .//Person diese eindeutig? D.h. es können nicht wie oben beschrieben 2 Personen die gleiche PersonID haben?

Ich glaube, dass dir noch immer nicht so ganz klar ist, was key-keyref macht.
Lese nochmal [2] durch und vergleich es mit deinem XML siehe --> [3].

Wie gesagt: wenn es dir nur um die Eindeutigkeit einer Person geht, reicht unique (dort kannst du auch mehrere Felder angeben).

Schau dir das Beispiel unter http://www.edition-w3c.de/TR/2001/REC-xmlschema-0-20010502/#K5 an (ignoriere mal die Namensräume einfach, der Text unter das Schemabeispiel ist leider als Erklärung sehr irreführend und kaum brauchbar, weil dort im gegensatz zum englischen Original nicht auf das Beispiel Bezug genommen wird. Wenn du kannst, solltest du dazu das englische Original durchlesen).

Dort wird mit:

<unique name="EindBeschr1">
   <selector xpath="a:Kundenkonto/a:Kunde"/>
   <field xpath="a:Name"/>
   <field xpath="a:Vornamen"/>
   <field xpath="a:Geburtsdatum"/>
</unique>

sichergestellt, dass im <KundenAufstellung> jede Kunde nur einmal vorkommen darf. Der selector "Kundenkonto/Kunde" wählt eine Menge von Elementen aus, und um die ausgewählte Elementen zu identifizieren, werden die Elemente Name, Vorname, Geburtsdatum (innerhalt der ausgewählten Elemente) herangezogen.

Das alles hat aber nichts mit keys und keyrefs zu tun.
du kannst dann dort oder unter http://www.edition-w3c.de/TR/2001/REC-xmlschema-1-20010502/#element-keyref die Beispiele für die Verwendung von key und key-ref anschauen. Das zweite Bsp. ist zuerst mal sicher kompilzierter, aber auch sehr anschaulich dafür wie key-keyref genutzt werden kann (man muss halt immer das XML dazudenken ;-))

Das ist also die eine Sache. Damit hättest du die Eindeutigkeit von Person sichergestellt.

<xs:key name="PersonID">
         <xs:selector xpath="Person"/>
      <xs:field xpath="@PersonID"/>
     </xs:key>

Dieser key zeigt auf das Attribut PersonID in Person, richtig?

Ja (auch wenn es jetzt nicht gut ist, dass du den Code aus dem Kontext genommen hast!)

Damit ist jetzt sichergestellt, dass jede Person einen eindeutigen Schlüssel PersonID hat?

Ja.

<xs:keyref name="PersonID2" refer="PersonID">
  <xs:selector xpath="Bestellungen/Bestellung/Person"/>
  <xs:field xpath="@PersonID"/>
</xs:keyref>

Dieser keyref zeigt auf das Element Person in Bestellungen/Bestellung, richtig?

Ja. (wobei das wort "zeigen" hier falsch ist, aber ich weiss was du damit meinst)

D.h. es muss ein Element Person unter Bestellung existieren?

Ja.

Kann ein keyref auch auf ein Attribut zeigen oder ist mit dieser XPath-Angabe gleich beides gemeint?

Nain. Ein <selector> darf nicht auf ein Attrubut zeigen, das darf nur ein <field>.

Ich möchte doch nur wie in meinen Datenbanken sagen: Person hat einen eindeutigen Schlüssel PersonID, der in Bestellung als Fremdschlüssel auftaucht, um referenzieren zu können, wer die Bestellung denn überhaupt ausgelöst hat.

Da sind wir wieder ganz bei [2] und somit müssen in deinem XML 1) und 2) vorhanden sein.

Grüße
Thomas

[Kerstin]

Hallo,

[2] Das sagt mir aber, dass du deine Personen _nicht_ in <Bestellung> verwaltest, d.h. dass die Liste der möglichen Personen woanderes steht und du in <Bestellung> auf diese Liste referenzieren willst: d.h. du hast

1. eine Liste der Personen, in der du sicherstellst, dass keine zwei Personen dieselbe PersonID haben (kannst mit unique oder key machen)
2. eine Liste der Bestellungen, in der du sicherstellen willst, dass die Person die die Bestellung aufgegeben hat, tatsächlich eine Person aus der Liste der Personen ist (machst du mit keyref) und weil du bereits in der Liste der Personen die Eindeutigkeitsbeschränkung definiert hast, kannst du eben aus Bestellung/Person darauf referenzieren.

Genau so ist es und so möchte ich es umsetzen.

Kann ein keyref auch auf ein Attribut zeigen oder ist mit dieser XPath-Angabe gleich beides gemeint?

Nain. Ein <selector> darf nicht auf ein Attrubut zeigen, das darf nur ein <field>.

Ja, das ist mir klar. Ich möchte statt eines Elements <Person></Person> unter Bestellung, ein Attribut in Bestellung <Bestellung Person="1"></Bestellung> haben. Und mit diesem Attribut soll der Schlüssel in <Person PersonID="1"></Person> gemeint sein.

Ich möchte doch nur wie in meinen Datenbanken sagen: Person hat einen eindeutigen Schlüssel PersonID, der in Bestellung als Fremdschlüssel auftaucht, um referenzieren zu können, wer die Bestellung denn überhaupt ausgelöst hat.

Da sind wir wieder ganz bei [2] und somit müssen in deinem XML 1) und 2) vorhanden sein.

Genau!

Gruß,
Kerstin

[Thomas J.S.]

Hallo,

Nain. Ein <selector> darf nicht auf ein Attrubut zeigen, das darf nur ein <field>.

Ja, das ist mir klar. Ich möchte statt eines Elements <Person></Person> unter Bestellung, ein Attribut in Bestellung <Bestellung Person="1"></Bestellung> haben. Und mit diesem Attribut soll der Schlüssel in <Person PersonID="1"></Person> gemeint sein.

Das kannst du dann z.B. im Eltern-Element vom <Bestellung> mit:

<xs:keyref name="PersonID2" refer="PersonID">
  <xs:selector xpath="Bestellung"/>
  <xs:field xpath="@Person"/>
</xs:keyref>

erreichen.

Grüße
Thomas

[Kerstin]

Ja, das ist mir klar. Ich möchte statt eines Elements <Person></Person> unter Bestellung, ein Attribut in Bestellung <Bestellung Person="1"></Bestellung> haben. Und mit diesem Attribut soll der Schlüssel in <Person PersonID="1"></Person> gemeint sein.

Das kannst du dann z.B. im Eltern-Element vom <Bestellung> mit:

<xs:keyref name="PersonID2" refer="PersonID">
  <xs:selector xpath="Bestellung"/>
  <xs:field xpath="@Person"/>
</xs:keyref>

erreichen.

aaaaaah, danke. Und wenn es dann doch ein Element <Person></Person> sein soll? so?

<xs:keyref name="PersonID2" refer="PersonID">
   <xs:selector xpath="Bestellung"/>
   <xs:field xpath="Person"/>
</xs:keyref>

Ein Element <Person></Person> unter <Bestellung></Bestellung> - also:
<Bestellung><Person>1</Person></Bestellung>.
Bisher habe ich das @ auch bei normalen Elementen in field verwendet.

[Thomas J.S.]

Hallo,

aaaaaah, danke. Und wenn es dann doch ein Element <Person></Person> sein soll? so?

<xs:keyref name="PersonID2" refer="PersonID">
   <xs:selector xpath="Bestellung"/>
   <xs:field xpath="Person"/>
</xs:keyref>

Ja, genau so.

Bisher habe ich das @ auch bei normalen Elementen in field verwendet.

Ich verstehe den Satz nicht.
@-Bezeichnet im XPath einen Attribut.

Grüße
Thomas

[Kerstin]

Hallo,

aaaaaah, danke. Und wenn es dann doch ein Element <Person></Person> sein soll? so?

<xs:keyref name="PersonID2" refer="PersonID">
   <xs:selector xpath="Bestellung"/>
   <xs:field xpath="Person"/>
</xs:keyref>

Ja, genau so.

gut, dann hab ichs jetzt, glaube, kapiert ...

Bisher habe ich das @ auch bei normalen Elementen in field verwendet.

Ich verstehe den Satz nicht.
@-Bezeichnet im XPath einen Attribut.

ja, genau das tut es. Bin halt nur etwas verwirrt, wenn bei manchen Beispielen beim xs:field ein @ steht, obwohl ein normales Element und kein Attribut gemeint ist.
Ich glaub, ich habs geschnallt und hoffe meine keys, keyrefs und uniques an den richtigen Stellen platziert zu haben.
Vielen Dank Thomas für Deine Geduld und natürlich für Deine Antworten.

Gruß,
Kerstin

[dieKerstin]

Hallo,

aaaaaah, danke. Und wenn es dann doch ein Element <Person></Person> sein soll? so?

<xs:keyref name="PersonID2" refer="PersonID">
   <xs:selector xpath="Bestellung"/>
   <xs:field xpath="Person"/>
</xs:keyref>

Ja, genau so.

NEIN, XMLSpy will das aber nicht so. Im XML-Schema ist das so ok, wenn ich aber eine XML-Datei gegen dieses Schema prüfen lasse, kommt:

"Diese Datei ist nicht gültig: Der <keyref> Identity Contraint 'PersonID2' ergab keinen Treffer im Geltungsbereich des Elements 'Bestellungen'. Der referenzierte Identity Contraint 'PersonID' befindet sich außerhalb des Geltungsbreichs."

So sieht das ganze im XML-Schema aus:
<xs:element name="Bestellungen">
 xs:complexType
  xs:sequence
   <xs:element name="Bestellung">
     xs:complexType
 xs:sequence
   <xs:element name="Person"/>
 </xs:sequence>
 <xs:attribute name="Person" type="xs:positiveInteger"
         use="required"/>
     </xs:complexType>
   </xs:element>
 </xs:sequence>
 </xs:complexType>
 <xs:keyref name="PersonID2" refer="PersonID">
  <xs:selector xpath="Bestellung"/>
  <xs:field xpath="Person"/>
 </xs:keyref>
</xs:element>

Wieso ist das falsch? Ich wähle in selector das Element Bestellung aus und das Unterelement Person ist das field, was gemeint ist.

[dieKerstin]

Und wenn es dann doch ein Element <Person></Person> sein soll? so?

<xs:keyref name="PersonID2" refer="PersonID">
   <xs:selector xpath="Bestellung"/>
   <xs:field xpath="Person"/>
</xs:keyref>

Ja, genau so.

Nee, so geht das net. Wenns so <xs:selector xpath="Bestellung/Person"/> aussieht, ists ok, dabei spielt es überhaupt keine Rolle, was in xs:field als xpath drinne steht. Das is völlig egal: ob nun mit @ oder ohne - es interessiert net und das is mein Problem. Warum dieses Feld bei einem keyref, wenns dann doch egal ist, was da drinne steht?

[Thomas J.S.]

Hallo,

Und wenn es dann doch ein Element <Person></Person> sein soll? so?

<xs:keyref name="PersonID2" refer="PersonID">
   <xs:selector xpath="Bestellung"/>
   <xs:field xpath="Person"/>
</xs:keyref>

Ja, genau so.

Nee, so geht das net. Wenns so <xs:selector xpath="Bestellung/Person"/> aussieht, ists ok, dabei spielt es überhaupt keine Rolle, was in xs:field als xpath drinne steht. Das is völlig egal: ob nun mit @ oder ohne - es interessiert net und das is mein Problem. Warum dieses Feld bei einem keyref, wenns dann doch egal ist, was da drinne steht?

Sorry, aber du postet hier mittlerweile unzählige totatal zusammengewürfelte Schema-Fragmente (deine andere Posting z.B. https://forum.selfhtml.org/?t=124134&m=802722.
Mir brummt schon der Schädel davon, dass ich versuche zu erahnen was denn nun wo in deinem Schema und/oder in deinem XML steht und dann Beispiele dafür schreiben, sie Teste etc.
Ich habe nichts gegen experimentieren, aber ich steige hier aus, weil mir das jetzt mit dem sich ständig ändernden Strukturen für Elemente und/oder Attribute zu viel wird.

Ich meine es jetzt nicht böse, aber bitte erlaube mir die Kritik: mir scheint, dass dir noch die Grundlagen einige Probleme bereiten, aber du versuchst schon jetzt komplizierte(ste) Zusammenhänge und Anwendungen zu erstellen und dabei springst von einer Idee zur nächsten, was halt dir gerade so einfällt oder dir über den weg läuft.

Grüße
Thomas

[dieKerstin]

Hallo,

ja, mir ist klar, dass ich einiges noch nicht verstehe, allerdings sind teilweise kaum brauchbare zusammenhängende Beispiel zu finden, wo mal beschrieben ist, was überhaupt gemeint ist, wenn keys und keyrefs angegeben sind.

Allerdings bleibt mir nichts anderes übrig ein so komplexes XML-Schema zu erstellen, weil die Daten halt nun mal so komplex sind. Ich versuche es mir an einem vereinfachten Schema (Bestellungen und Personen) zu verdeutlichen, aber scheinbar klappt das auch nicht.

Ich dachte wirklich nach deinem letzten Post, ich hätte es. Ich hab mich auch wirklich nur an die Beispiele dort gehalten und das umgesetzt. Aber beim Erstellen des zugehörigen XML-Dokuments bin ich leider wieder auf einige Probleme gestoßen an denen mein Projekt nun wohl scheitern wird.

Ich danke dir trotzdem für deine Hilfe. Allerdings muss ich sagen, dass es zu umfangreich wäre, hier ein komplettes Schema zu posten, weil einfach zu lang und unübersichtlich ...
Desweiteren waren auch deine Schemata nicht immer vollständig, so dass ich immer wieder nachfragen musste.
Nunja, es ist vorbei ... THX

Gruß,
Kerstin