XSD: Frage zu "restriction"

[items]

Hallo Forum,
ich bin gerade dabei mich so ein bisschen in XML reinzufummeln. Mit DTDs und XDR bin ich erstmal durch und jetzt hängt es hier aber mächtig bei XSD.
Es geht darum, das ich einen komplexen Typ angelegt habe (damit ich überhaupt ein Attribut angeben kann). Das mache ich mit XML Spy (cooles Dingens, übrigens), das ich mir als Demo runtergeladen habe. Wenn ich jetzt ein komplexes Element anlege, generiert mir XML Spy dieses hier:

<xs:element name="nachricht">
  xs:complexType
 xs:simpleContent
<xs:extension base="xs:string"/>
 </xs:simpleContent>
</xs:complexType>
</xs:element>

Sieht ja auch alles ganz gut aus, aber was ich überhaupt nicht verstehe, ist dieser Teil:

"<xs:extension base="xs:string"/>"

Da gibt es nämlich auch noch die Möglichkeit statt "extension" "restriction" einzugeben. Kann mir jemand erklären, was das bedeutet, bzw. wo der Unterschied liegt? Google gibt leider wenig her zu dem Thema und es gibt zwar endlose Beiträge, die sich mit "restriction" beschäftigen, aber ich habe nirgends gefunden, was das jetzt eigentlich bedeutet.

Vielen Dank und Gruß
items

[fjh]

Hallo item,

ich bin gerade dabei mich so ein bisschen in XML reinzufummeln. Mit DTDs und XDR bin ich erstmal durch und jetzt hängt es hier aber mächtig bei XSD.

Kein Wunder bei den zwei kryptischen Riesen-Spezifikationen...

Es geht darum, das ich einen komplexen Typ angelegt habe (damit ich überhaupt ein Attribut angeben kann). Das mache ich mit XML Spy (cooles Dingens, übrigens), das ich mir als Demo runtergeladen habe.

Und was machste wenn die Demo ausgelaufen ist ;-)

Wenn ich jetzt ein komplexes Element anlege, generiert mir XML Spy dieses hier:

<xs:element name="nachricht">
  xs:complexType
xs:simpleContent
<xs:extension base="xs:string"/>
</xs:simpleContent>
</xs:complexType>
</xs:element>

In der ausführlichsten Version sähe eine Attribut-Deklaration für Dein Element <nachricht> so aus:

<xs:element name="nachricht">
  xs:complexType
    xs:simpleContent
      <xs:restriction base="xs:anyType">
        <xs:attribute name="meinAttribut"
                      type="xs:string"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

"xs:anyType" ist die Typangabe für den sog. ur-type, der keinerlei Einschränkungen enthält. Hier wird also ein komplexer Typ mit einfachem Inhalt (also ohne Element-Inhalt) gebildet, wobei das Element hier leer ist, aber ein Attribut haben kann.

Eine abgekürztere Version wäre:

<xs:element name="nachricht">
  xs:complexType
    xs:simpleContent
      <xs:attribute name="meinAttribut"
                    type="xs:string"/>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

Du siehst, eigentl. brauchst Du dich um den xs:extension und xs:restriction-Kram nicht wirklich zu kümmern, wenn du einfach nur ein Attribut deklarieren willst.

Mit xs:restriction und xs:extension leitest Du eigene Datentypen von schon bestehenden ab. Bei xs:restriction schränkst du den Datentyp ein, bei xs:extension erweiterst du ihn.

Z.B. könntest Du einen eigenen Datentyp vom eingebauten Datentyp String ableiten, der nur 5 Zeichen lang sein darf:
<xs:simpleType name="PLZ">
  <xs:restriction base="xs:string">
    <xs:length value="5"/>
  </xs:restriction>
</xs:simpleType>

Ebenso kannst Du aber auch einen Typ erweitern.

Z.B. könntest Du zunächst einen Typ namens Preis definieren, der eine Dezimalzahl mit zwei Nachkommastellen als Preis zuläßt.

<xs:simpleType name="Preis_Typ">
  <xs:restriction base="xs:decimal">
    <xs:fractionDigits value="2"/>
  </xs:restriction>
</xs:simpleType>

Nun willst du vielleicht diesen Typ erweitern zu einem Typ namens Internationaler Preis, der zusätzlich ein Attribut namens "währung" erhält. Dazu verwendest Du das xs:extension-Element. Das Attribut "base" gibt dabei den Namen des Typs an, der erweitert werden soll.

<xs:complexType name="InternationalerPreis">
  xs:simpleContent
    <xs:extension base="Preis_Typ">
      <xs:attribute name="währung"
                    type="xs:string"/>
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>

Gruß
Franz

[items]

Hallo Franz,

Kein Wunder bei den zwei kryptischen Riesen-Spezifikationen...

Jo. Das scheint mir eine richtige Wissenschaft zu sein. Einsteigen ist ziemlich leicht (da die XML Regeln beibehalten werden), aber dann wird es schnell fieselig.

Und was machste wenn die Demo ausgelaufen ist ;-)

Dann bin ich hoffentich so weit, das das zu Fuß geht (obwohl ich mir nicht vorstellen kann, das Leute den Kram wirklich von Hand schreiben). Bei richtig komplexen Dingern kriegt man da doch bestimmt einen Vogel, oder?

Außerdem finde ich die Software zum lernen ziemlich gut. Ich lerne nach einem Buch, das teilweise etwas unverständlich ist und einige Quelltexte haben offensichtlich Fehler (oder sind schlecht übersetzt). Deshalb baue ich das im XML Spy nach und gucke dann in den Quelltext, den der generiert. Finde ich ziemlich prima. Da weiß man erstmal das das XSD Schema fehlerfrei ist (da gültig und valide :o) und hat dann eine Basis, von der man ausgehen kann. Ist einfach Scheiße, wenn ein Beispiel da ist, das nicht funktioniert, und man den Fehler natürlich nicht findet, weil mans ja gerade an dem Beispiel lernen will. Kann man Stunden mit verbaseln. Aber ich weiß natürlich worauf du hinaus willst. Es geht mir schon darum, zu verstehen was ich mache.

Mit xs:restriction und xs:extension leitest Du eigene Datentypen von schon bestehenden ab. Bei xs:restriction schränkst du den Datentyp ein, bei xs:extension erweiterst du ihn.

Heißt das, man baut man ein Element und sagt dann, das dieses Element nur vom Typ string, int, decimal usw. sein darf und hat dann später die Möglichkeit, wieder auf dieses Element zuzugreifen und es mit Attributen zu erweitern, kann aber an dem grundsätzlichen Typ nichts mehr ändern? Erinnert mich ja fast ein bisschen an OOP.

War überaus erhellend der Ausflug :-). Ich hoffe mal das ich alles richtig verstanden habe.

Vielen Dank für die große Mühe
Grüße
items

[fjh]

Hallo item,

Jo. Das scheint mir eine richtige Wissenschaft zu sein. Einsteigen ist ziemlich leicht (da die XML Regeln beibehalten werden), aber dann wird es schnell fieselig.

Richtig, das ist auch einer der Kritikpunkte an XSD, obwohl es sich durchzusetzen scheint und auch in immer mehr anderen Standards als Grundlage genommen wird.

Und ich muss sagen, die Spec ist sowas von schwierig zu kapieren. Wenn mir mein Parser einen Fehler meldet (Xerces), dann verweist er immer auch auf einen Abschnitt der Spec. Dort kapiere ich dann aber immer nur unter Gehirnverrenkungen, was denn nun eigentlich gemeint ist. Wenn die Fehlermeldung also etwas kurz und kryptisch ausfällt, steht man ziemlich dumm da.
Dafür ist der Primer ganz gut, aber zum Einstieg hilft eigentlich nur ein gutes Buch, das Schritt für Schritt vorgeht...

Ein wirklich gutes Buch zum Thema ist wie immer bisher noch auf englisch und nicht das billigste: http://www.amazon.de/exec/obidos/ASIN/1861005474/qid=1015764720/sr=8-3/ref=sr_aps_prod_3_1/028-5098431-6133314
Es behandelt alles von Anfang an sehr ausführlich und trotzdem ist es nicht son "For-Dummies-Buch". Zudem aktuell und auf die abschließende REC bezogen.

Dann bin ich hoffentich so weit, das das zu Fuß geht (obwohl ich mir nicht vorstellen kann, das Leute den Kram wirklich von Hand schreiben). Bei richtig komplexen Dingern kriegt man da doch bestimmt einen Vogel, oder?

Ja stimmt ;-)
Ohne Toolunterstützung ist das nicht wirklich praktikabel. Aber ich mache bisher immer noch alles ohne XML Spy oder ähnliche Tools. Ich habe mal versucht mich in das Ding einzuarbeiten und ehrlich gesagt es nie richtig begriffen: fügt der das Elelemnt danach oder davor ein, was heißt nun welches von den 200 Symbolen? Aber es ist schon richtig, bei komplexen Projekten unter Windows wird es ne Menge Zeit sparen, wenn man sich da mal einarbeitet.

Außerdem finde ich die Software zum lernen ziemlich gut. Ich lerne nach einem Buch, das teilweise etwas unverständlich ist und einige Quelltexte haben offensichtlich Fehler (oder sind schlecht übersetzt). Deshalb baue ich das im XML Spy nach und gucke dann in den Quelltext, den der generiert. Finde ich ziemlich prima. Da weiß man erstmal das das XSD Schema fehlerfrei ist (da gültig und valide :o) und hat dann eine Basis, von der man ausgehen kann. Ist einfach Scheiße, wenn ein Beispiel da ist, das nicht funktioniert, und man den Fehler natürlich nicht findet, weil mans ja gerade an dem Beispiel lernen will. Kann man Stunden mit verbaseln. Aber ich weiß natürlich worauf du hinaus willst. Es geht mir schon darum, zu verstehen was ich mache.

Vielleicht behandelt Dein Buch noch eine der Vorstufen der REC, ist mir am Anfang auch passiert, dauern passte irgendwas nicht.

Mit xs:restriction und xs:extension leitest Du eigene Datentypen von schon bestehenden ab. Bei xs:restriction schränkst du den Datentyp ein, bei xs:extension erweiterst du ihn.

Heißt das, man baut man ein Element und sagt dann, das dieses Element nur vom Typ string, int, decimal usw. sein darf und hat dann später die Möglichkeit, wieder auf dieses Element zuzugreifen und es mit Attributen zu erweitern, kann aber an dem grundsätzlichen Typ nichts mehr ändern? Erinnert mich ja fast ein bisschen an OOP.

Ja, das Vererbungsprinzip der Objektorientierung steckt dahinter. Wirklich oft benutze ich das eigentlich nur, um einfache eingebaute Typen (string, int, decimal) in irgendeiner Form einzuschränken. Da kannst du ganz viel machen, da die pattern-Facette auch reguläre Ausdrücke unterstützt. Also z.B.

<xs:element name="ktoNr"/>
  xs:simpleType
    <xs:restriction base="xs:string">
      <xs:pattern value="\d{5}(-\d{4})?"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

Der selbst definierte, einfache Typ beschränkt den Inhalt von Ele-menten des Typs ktoNrTyp auf ein Muster mit fünf Ziffern, einem optionalen Bindestrich und vier weiteren Ziffern.

Gruß
Franz

[items]

Hallo Franz,

Und ich muss sagen, die Spec ist sowas von schwierig zu kapieren.

finde ich ehrlich gesagt überaus erleichternd, das du diese Ansicht teilst. Das ganze machte erst den Eindruck von "machen wir mal eben" und ist dann so entglitten, dass ich gar nicht mehr wußte worum es überhaupt noch geht.

Ein wirklich gutes Buch zum Thema ist wie immer bisher noch auf englisch und nicht das billigste: http://www.amazon.de/exec/obidos/ASIN/1861005474/qid=1015764720/sr=8-3/ref=sr_aps_prod_3_1/028-5098431-6133314
Es behandelt alles von Anfang an sehr ausführlich und trotzdem ist es nicht son "For-Dummies-Buch". Zudem aktuell und auf die abschließende REC bezogen.

Danke. Werde ich mir auf jeden Fall mal angucken. Gibt hier in Berlin auch Läden, wo man sowas mal zur Ansicht bestellen kann (das machen aber leider nur die großen). Als ich mein Buch gekauft habe, ging es erstmal nur darum, überhaupt einen Überblick zu kriegen, worum es bei XML eigentlich geht. XSD wird da nur angerissen, aber die Autoren sind auch der Ansicht, das sich das als Standard durchsetzen wird. Da muß also auf jeden Fall irgendein Buch her, das die Dinge in ein etwas verständlicheres und umfassenderes Licht rückt. Ich habe ja schon mächtig rumgegoogelt, aber da wirds denn auch langsam ein bisschen dünne mit verständlichen Tutorials. Und mir geht es eben, wie gesagt, genau wie dir. Lernen kann ich am besten mit einem guten Buch in der Hand.

Ohne Toolunterstützung ist das nicht wirklich praktikabel. Aber ich mache bisher immer noch alles ohne XML Spy oder ähnliche Tools. Ich habe mal versucht mich in das Ding einzuarbeiten und ehrlich gesagt es nie richtig begriffen: fügt der das Element danach oder

Bei mir lief es eher umgekehrt. Ging relativ schnell ein valides Schema zu basteln, aber dann hinter die Bedeutung zu kommen war das Problem.Der Funktionsumfang hat mich allerdings auch erstmal erschlagen. Aber ich kann mir gut vorstellen, dass man damit auch relativ fette Geräte ziemlich schnell und übersichtlich strukturieren kann. Außerdem ist der Parser imho ziemlich cool. Die Fehlermeldungen sind nämlich überaus verständlich (jedenfalls bisher). Er zeigt dir genau den Tag an, bei dem es hakt und spezifiziert den Fehler im Tag dann auch noch relativ genau. Finde ich überaus erleichternd muß ich sagen.

Vielleicht behandelt Dein Buch noch eine der Vorstufen der REC,

Ja. Ist durchaus möglich. Der Typ schreibt auch, das an XSD immer noch ziemlich viel rumgeschraubt wird und man öfter mal gucken soll, was sich so getan hat.

»»auch reguläre Ausdrücke unterstützt. Also z.B.
Öha. Ich dachte am Anfang ehrlich gesagt, ich setze mich mal eben hin und lerne XML. Da sehe ich langsam ein bißchen Schwarz :o)

Grüße
items

[fjh]

Hallo,

Danke. Werde ich mir auf jeden Fall mal angucken. Gibt hier in Berlin auch Läden, wo man sowas mal zur Ansicht bestellen kann (das machen aber leider nur die großen).

Ja, Kiepert z.B. ;-)

Bei mir lief es eher umgekehrt. Ging relativ schnell ein valides Schema zu basteln, aber dann hinter die Bedeutung zu kommen war das Problem.Der Funktionsumfang hat mich allerdings auch erstmal erschlagen. Aber ich kann mir gut vorstellen, dass man damit auch relativ fette Geräte ziemlich schnell und übersichtlich strukturieren kann. Außerdem ist der Parser imho ziemlich cool. Die Fehlermeldungen sind nämlich überaus verständlich (jedenfalls bisher). Er zeigt dir genau den Tag an, bei dem es hakt und spezifiziert den Fehler im Tag dann auch noch relativ genau. Finde ich überaus erleichternd muß ich sagen.

Es ist der msxml-parser...

Vielleicht behandelt Dein Buch noch eine der Vorstufen der REC,

Ja. Ist durchaus möglich. Der Typ schreibt auch, das an XSD immer noch ziemlich viel rumgeschraubt wird und man öfter mal gucken soll, was sich so getan hat.

Du erkennst es am Namensraum. Steht da statt:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
z.B.
<xs:schema xmlns:xs="http://www.w3.org/2000/10/XMLSchema">
dann ist es ne ältere Version.

Gruß
Franz

[items]

Hi,

Ja, Kiepert z.B. ;-)

Genau :o). Wobei ich allerdings entfernungstechnisch Dussmann bevorzuge. Und die sind auch überaus gut sortiert.

Du erkennst es am Namensraum. Steht da statt:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
z.B.
<xs:schema xmlns:xs="http://www.w3.org/2000/10/XMLSchema">
dann ist es ne ältere Version.

Das dürfte es gewesen sein. Das heißt, die Beispiele aus meinem Buch können z.T. gar nicht funzen. Das ist natürlich eine ziemlich müßige Geschichte dann. Der Parser nöhlt nämlich laufend rum und wenn ich den Code generieren lasse, funzt es zwar, aber ich weiß nicht warum einzelne tags dastehen. Räudig das. Kann ja dann nicht voran gehen.

Angenehmen Tag noch
Ralf

[Simon Reinhardt]

Hi!

ich bin gerade dabei mich so ein bisschen in XML reinzufummeln. Mit DTDs und XDR bin ich erstmal durch und jetzt hängt es hier aber mächtig bei XSD.

Da es mich doch echt gewurmt hat, dass es da ein XML-Akronym gibt, welches mir bisher noch nie zu Ohren gekommen ist, habe ich mal nach XDR gesucht und festgestellt, dass es gar nichts mit XML zu tun hat: http://www.faqs.org/rfcs/rfc1832.html. Meinst Du wirklich das?
Oder sollte es da noch etwas anderes geben?

VG Simon

[fjh]

Hallo Simon,

Da es mich doch echt gewurmt hat, dass es da ein XML-Akronym gibt, welches mir bisher noch nie zu Ohren gekommen ist, habe ich mal nach XDR gesucht und festgestellt, dass es gar nichts mit XML zu tun hat: http://www.faqs.org/rfcs/rfc1832.html. Meinst Du wirklich das?

Ich vermute mal nein.

XDR steht auch für "XML Data Reduced", eine der vielen alternativen Schema-Varianten zu XML-Schema vom W3C. Es ist eine Teilmenge von XML-Data, das es bereits seit Januar 1998 gibt (also noch vor dem endgültigen XML-Standard) (http://www.w3.org/TR/1998/NOTE-XML-data-0105/Overview.html). Der MSXML-Parser unterstütze lange Zeit nur XDR, nun auch XML-Schema. Mit XML-Spy kannst Du die beiden Dialelekte so weit ich weiss ineinander umwandeln.

Oder sollte es da noch etwas anderes geben?

ja, s.o.

Gruß
Franz