Nachdem ich nun endlich XML-Schemata einlesen und mich durch den "Baum"
nach unten hangeln kann, stellt sich mir noch folgende (Dummie?-)Frage:
In einem Schema kann man ja auf oberster Ebene, also global, mehrere
Elemente definieren. In meinem Buchbestellungs-Beispiel wird ein
Kommentar nicht als Typ, sondern als Element definiert, das dann per
Referenz benutzt wird.
Aber sehe ich das richtig, daß so ein Schema theoretisch auch
verschiedene Elemente als Root für ein XML-Dokument beschreiben kann?
Ich meine, im XML-Dokument selbst muß es ja eine eindeutige Wurzel geben
(z.B. Bestellung). Alleine aus dem Schema würde ich aber herleiten, daß
man theoretisch auch ein Dokument mit lediglich einem Kommentar
erstellen dürfte, ohne das Schema zu verletzen. Man könnte auch ein
zweites Element "Spezialbestellung" definieren, das statt einer normalen
Bestellung im Dokument stehen dürfte. Ist das richtig?
Oder ist schon aus einem Schema ersichtlich, daß das Dokument dazu ein
ganz bestimmtes Element als Root enthält?
Antworten bitte hier in der NG.
Danke im Voraus,
Sascha
Hier das (wohl weit bekannte) Bestellungs-Schema, gekürzt:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="Bestellung" type="BestellungTyp"/>
<xsd:element name="Kommentar" type="xsd:string"/>
<xsd:complexType name="BestellungTyp">
....
</xsd:complexType>
<xsd:complexType name="DeAdresse">
....
</xsd:complexType>
<xsd:complexType name="WarenTyp">
<xsd:sequence>
<xsd:element name="Buch" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
....
<xsd:element ref="Kommentar" minOccurs="0"/>
....
</xsd:sequence>
<xsd:attribute name="ISBN" type="ISBNTyp" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="ISBNTyp">
....
</xsd:simpleType>
</xsd:schema>
> Aber sehe ich das richtig, daß so ein Schema theoretisch auch
> verschiedene Elemente als Root für ein XML-Dokument beschreiben kann?
Ja, das ist moeglich.
--
Martin Honnen
http://JavaScript.FAQTs.com/
HI,
> Aber sehe ich das richtig, daß so ein Schema theoretisch auch
> verschiedene Elemente als Root für ein XML-Dokument beschreiben kann?
das siehst Du durchaus korrekt.
> Ich meine, im XML-Dokument selbst muß es ja eine eindeutige Wurzel geben
> (z.B. Bestellung). Alleine aus dem Schema würde ich aber herleiten, daß
> man theoretisch auch ein Dokument mit lediglich einem Kommentar
> erstellen dürfte, ohne das Schema zu verletzen. Man könnte auch ein
> zweites Element "Spezialbestellung" definieren, das statt einer normalen
> Bestellung im Dokument stehen dürfte. Ist das richtig?
>
> Oder ist schon aus einem Schema ersichtlich, daß das Dokument dazu ein
> ganz bestimmtes Element als Root enthält?
Nein. Dabei ist zu beachten, dass das Schema seine qualitative Bedeutung
erst erhält, sobald es genutzt wird, eine XML-Instanz zu validieren. Um
jedoch ein Instanzdokument validieren zu können, muss es dem
Schema-Prozessor bekannt sein, sobald er ein Element validieren muss,
was (logischerweise) bereits beim Root-Element der Fall ist. Aus jenem
Grund wird dem root-Element mittels Attribut
(xsi:noNamespaceSchemaLocation bzw. xsi:schemaLocation) die Information
über die Position des Schemas beigefügt.
Abschließend ist es also so, dass mit der Wahl des Root-Elements in der
_Instanz_ festgelegt wird, welcher Knoten der Wurzel im XML-Baum
entspricht. Das Schema kann hier bestenfalls eine Auswahl ermöglichen.
(Man sieht dies bspw., wenn man mit einem Werkzeug aus einem Schema eine
beispielhafte Dokumentinstanz erzeugen will. Da wird man dann nach dem
Root-Element gefragt.)
> Antworten bitte hier in der NG.
Wo sonst?
MfG,
Stephan R.
Okay, dann werde ich es auch so machen müssen: Fragen, welches der
Elemente denn nun die Wurzel sein soll.
>> Antworten bitte hier in der NG.
>
> Wo sonst?
Per Mail?
Aber die ruf ich eben kaum ab, da v.A. Spam-Fänger. Daher der Hinweis.
Merci Dir!
Jetzt häng ich an 'ne anderen Problem. Ich hab mal aus den Beispielen
der Schema-Doku das rausgegriffen, das ein Schema auf zwei Dateien
aufteilt. Adressen-Typen werden einer eigenen Datei definiert, die ich
dann per include einbinde.
Das ganze teste ich ja lokal, also hab ich die ganzen URLs (vorher:
http://...) durch file:///... ersetzt. Aber das war offenbar ein Fehler,
denn nun bekomme ich beim Einlesen folgenden Fehler:
org.apache.crimson.tree.DomEx: WRONG_DOCUMENT_ERR: Dieser Knoten gehört
nicht in dieses Dokument.
at org.apache.crimson.tree.ParentNode.checkDocument(ParentNode.java:250)
.....
Darf ich keine file-URIs verwenden? Liegt der Fehler ganz wo anders?
Sorry, bloody beginner...
adresse.xsd:
<schema targetNamespace="file:///c:/tmp/xsdtests/IBEST"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ibest="file:///c:/tmp/xsdtests/IBEST">
<annotation>
<documentation xml:lang="DE">
Adressen für das internationale Buchbestellungsschema für
Example.com.
Copyright 2001 Example.com. Alle Rechte vorbehalten.
</documentation>
</annotation>
<complexType name="Adresse">
....
</complexType>
<complexType name="DeAdresse">
....
</complexType>
<complexType name="USAAdresse">
...
</complexType>
<simpleType name="USBundesStaat">
...
</simpleType>
</schema>
Und die wird benutzt in ibest.xsd:
<schema targetNamespace="file:///c:/tmp/xsdtests/IBEST"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ibest="file:///c:/tmp/xsdtests/IBEST">
<annotation>
<documentation xml:lang="DE">
Internationales Buchbestellungsschema für Example.com.
Copyright 2001 Example.com. Alle Rechte vorbehalten.
</documentation>
</annotation>
<!-- Einbinden der Adress-Konstrukte -->
<include schemaLocation="file:///c:/tmp/xsdtests/adresse.xsd"/>
usw...
Also den targetNamespace und xmlns:ibest hättest Du jetzt nicht auf eine
File-URI umstellen müssen. Aber daran sollte Dein Problem nicht liegen.
Ein weiterer Vorschlag: Warum benutzt Du nicht eine relative Referenz in
dem Include? Also <include schemaLocation="adresse.xsd"/>. Auch das
beantwortet nicht die ursprüngliche Frage, aber könnte helfen, dass es
funktioniert.
Grüße,
Klaas
> Also den targetNamespace und xmlns:ibest hättest Du jetzt nicht auf eine
> File-URI umstellen müssen. Aber daran sollte Dein Problem nicht liegen.
>
> Ein weiterer Vorschlag: Warum benutzt Du nicht eine relative Referenz in
> dem Include? Also <include schemaLocation="adresse.xsd"/>. Auch das
> beantwortet nicht die ursprüngliche Frage, aber könnte helfen, dass es
> funktioniert.
Hab wieder auf die URLs zurückgestellt und auf relativen Pfad. Leider
selbes Problem. Vielleicht ist in den Beispielen was falsch...
Muß mal nach anderen Schemata suchen, die ich zum Testen nutzen kann.
Wie testest Du das denn? Tritt die Fehlermeldung z.B. auf, wenn Du das
Schema versuchst mit XSOM einzulesen? Oder versuchst Du gerade mit
Crimson ein Instanzdokument gegen ein Schema zu validieren? Denn soweit
ich weiß, hat Crimson kein Unterstützung für die Validierung gegen XML
Schema (lasse mich dort aber auch korrigieren).
Grüße,
Klaas
Direkt beim Einlesen. Ich will ja nur die Struktur von dem Schema
erfassen und, soweit möglich, das (maximal) mögliche XML-Dokument
rauskriegen, das laut diesem Schema daherkommen kann.
Ich schick Dir mal die beiden xsd-Dateien per Mail, vielleicht sagt Dir
Dein eclipse-XSD ja mehr als mein XSOM.