Wie gehe ich nun am sinnvollsten vor? Die vorhandene xsd-Datei
passend zu ergaenzen wuerde ich mir zutrauen, das widerstrebt mir
allerdings aus aesthetischen Gruenden. Ist es irgendwie moeglich,
das bestehende Format durch einen zusaetzlichen Namespace
aufzubohren?
Wenn ich:
| <ROOT xmlns="http://xsd.example/xsd">
| <PARENT>
| <TAG>content</TAG>
| </PARENT>
| </ROOT>
zu:
| <ROOT xmlns="http://xsd.example/xsd" xmlns:cust="http://custom.example/xsd">
| <PARENT>
| <cust:TAG cust_attribute="value">content</cust:TAG>
| <cust:CUST_TAG></cust:CUST_TAG>
| </PARENT>
| </ROOT>
erweitern moechte (was in etwa dem Umfang der gewuenschten
Ergaenzungen entspricht und von der Schreibweise her im XML am
klarsten ausdruecken wuerde, wo genau die Anpassungen stattfinden),
dann muss ich ja auch die Definition von PARENT bereits passend
veraendern. Aber wo? Und wie? Mit Namespaces musste ich mich noch
nie aktiv auseinandersetzen...
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Von Aliens empfohlen - rattern mit Stefan!
(Sloganizer)
Du musst für den neuen Namensraum zuerst ein eigenständiges Schema (also
etwa customSchema.xsd) mit targetNamespace http://custom.example/xsd
schreiben, das dann die Elemente definiert, die du oben einbauen willst.
Um das bestehende Schema zu erweitern und das neue Schema einzufügen,
kannst du dann eventuell redefine
(http://www.w3.org/TR/xmlschema-0/#Redefine) benutzen, also etwa
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://xsd.example/xsd"
xmlns:cust="http://custom.example/xsd">
<xs:import namespace="http://custom.example/xsd"
schemaLocation="customSchema.xsd"/>
<xs:redefine schemaLocation="originalSchema.xsd">
<!-- hier muss nun der Typ oder das Element PARENT neu definiert
werden -->
</xs:redefine>
</xs:schema>
Ob das mit dem "redefine" so möglich ist, hängt aber stark von der
Strukltur des existierenden Schemas ab, so muss das Element "PARENT"
oder sein Typ global definiert sein.
--
Martin Honnen --- MVP Data Platform Development
http://msmvps.com/blogs/martin_honnen/
> Du musst für den neuen Namensraum zuerst ein eigenständiges Schema (also
> etwa customSchema.xsd) mit targetNamespace http://custom.example/xsd
> schreiben, das dann die Elemente definiert, die du oben einbauen willst.
> Um das bestehende Schema zu erweitern und das neue Schema einzufügen,
> kannst du dann eventuell redefine
> (http://www.w3.org/TR/xmlschema-0/#Redefine) benutzen
Ok, danke - das scheint mir schon einmal in die richtige Richtung zu gehen.
> <xs:redefine schemaLocation="originalSchema.xsd">
> <!-- hier muss nun der Typ oder das Element PARENT neu definiert
> werden -->
> </xs:redefine>
>
> </xs:schema>
> Ob das mit dem "redefine" so möglich ist, hängt aber stark von der
> Strukltur des existierenden Schemas ab, so muss das Element "PARENT" oder
> sein Typ global definiert sein.
Hm. Im originalen Schema finde ich durchaus eine globale Definition des
gewuenschten Elements:
| <xsd:element name="PARENT">
| <xsd:complexType>
| <xsd:sequence>
| [...]
| </xsd:sequence>
| </xsd:complexType>
| </xsd:element>
Wenn ich nun aber in meine neue xsd testweise das hier:
| <xsd:redefine schemaLocation="orig.xsd">
| <xsd:complexType name="PARENT">
| <xsd:complexContent>
| <xsd:extension base="orig:PARENT">
| <xsd:sequence>
| <xsd:element name="CHILD" minOccurs="0"/>
| </xsd:sequence>
| </xsd:extension>
| </xsd:complexContent>
| </xsd:complexType>
| </xsd:redefine>
schreibe ("orig" ist dabei der originale Namespace), was nach meinem
Verstaendnis genau dem von Dir verlinkten Redefine-Beispiel entspricht,
dann bekomme ich mit xmllint die Fehlemeldung:
| Schemas parser error : Element
| '{http://www.w3.org/2001/XMLSchema}complexType': The complex type
| definition '{[orig]}PARENT' to be redefined could not be found in the
| redefined schema.
Liegt das daran, dass nicht der ComplexType definiert wird, sondern gleich
das Element? Wie kann ich darauf reagieren? Unterhalb von "redefine" lassen
sich ja nur ComplexTypes definieren, keine Elemente.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan - nicht einer mährt scheuer oder auch langer.
(Sloganizer)
> <xs:import namespace="http://custom.example/xsd" schemaLocation="customSchema.xsd"/>
> <xs:redefine schemaLocation="originalSchema.xsd">
> <!-- hier muss nun der Typ oder das Element PARENT neu definiert werden -->
> </xs:redefine>
> Ob das mit dem "redefine" so möglich ist, hängt aber stark von der
> Strukltur des existierenden Schemas ab, so muss das Element
> "PARENT" oder sein Typ global definiert sein.
Nach etwas naeherer Beschaeftigung mit der Materie scheint es mir
so, dass die globale Definition des Elements gerade _nicht_
ausreicht, sondern auf jeden Fall der Typ global definiert sein muss
(eigenstaendig, oder mit eigenem Namen innerhalb der Definition des
Elements).
In meinem Fall habe ich leider:
| <xsd:element name="FOO">
| <xsd:complexType>
| <xsd:sequence>
| <xsd:element ref="BAR" maxOccurs="unbounded"/>
| </xsd:sequence>
| </xsd:complexType>
| </xsd:element>
...im originalen Schema vorgegeben, womit der Weisheit letzter
Schluss bislang wirklich nur auf: "geht leider nicht" hinauslaeuft.
Somit bleiben mir die Alternativen,
a) mir ca. 250kB xsd-Datei anzueignen und entsprechend meinen
Anforderungen zu modifizieren (was abgesehen vom Aufwand eigentlich
ein absolutes no-go ist, da mir der Namespace abseits der 3 zu
ergaenzenden Wunsch-Elemente ja schliesslich nicht gehoert), oder
b) auf Validierung komplett zu verzichten
Irgendwie eigenwillig, dass es da so _gar_ keine
Eingriffsmoeglichkeiten gibt, wo man doch sonst alles moegliche und
unmoegliche mit XML anstellen kann.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike
Stefan, so zäh wie die Welt. Spinnen ist grausam.
(Sloganizer)