nicht angemeldet
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