Die XML-Instanz Gamut

Wenn Sie Software schreiben, die XML-Dokumente ausliefert oder XML-Dokumente konsumiert - und wenn Sie diesen Beitrag lesen, ist die Wahrscheinlichkeit groß, dass Sie das tun -, dann gibt es immer eine große Herausforderung: Wie stellen Sie sicher, dass Ihr Dienst oder Ihr Client mit allen XML-Dokumenten umgehen kann, die Sie möglicherweise erwarten?

Und wenn Sie zufällig aus der testgetriebenen Welt kommen, lautet die Antwort natürlich: indem Sie es testen. Aber wenn Sie das tun, könnte es schwieriger werden, als Sie zunächst erwarten.

Was ist mit Schemata?

Ich erinnere mich noch gut daran, dass wir den Google Local Search Service integrieren mussten. Wir schafften es, dass sie uns ihr Schema schickten, aber das Schema war nur illustrativ und nicht normativ. Tatsächlich wurde es nicht einmal richtig 'geparst'. Es sollte eigentlich eine DTD sein, aber in Wirklichkeit war es keine. In diesem Fall sind Sie im Grunde verloren. Das Einzige, was Sie wirklich tun können, ist 'testen, indem Sie herumstochern' und versuchen, herauszufinden, was der Webdienst antworten wird, und dies dann in Ihr Test-Harness einarbeiten.

Wenn Sie es jedoch schaffen, ein Schema zu erstellen, dann sind Sie noch nicht fertig. Sicher, wenn es sich um SOAP-basierte Webservices handelt, dann können Sie vielleicht Stubs und Skelette generieren, und diese Stubs und Skelette würden Ihnen eine gewisse Garantie geben, dass Sie die meisten Fälle abdecken. Es besteht jedoch immer noch die Möglichkeit, dass Sie nicht alle Fälle abdecken, da es innerhalb Ihres XML-Dokuments Alternativen für Inhaltsmodelle geben könnte und Sie sich bei der Implementierung Ihres Dienstes nur mit einem von ihnen befassen.
Wenn das Schema klein ist, können Sie es wahrscheinlich durch sorgfältige Prüfung herausfinden. Wenn das Schema jedoch sehr umfangreich ist, wird dies angesichts der Vielfalt der XML-Dokumente, die Sie möglicherweise erhalten, unmöglich sein. Und selbst wenn Sie das Schema selbst erstellt haben, kann es sein, dass es eine größere Bandbreite an Optionen abdeckt, als Sie erwartet haben. (Ich bin mir sicher, dass ich nicht der Einzige bin, der diese Erfahrung gemacht hat. ;-))

<XML-Instanz-Generator als Retter in der Not

Also, zurück zu testorientiert. Die gute Nachricht ist, dass es Tools gibt, die aus einem Schema zufällige Instanzen erzeugen und dabei im Grunde alle Optionen durchspielen. Xmlgen ist eines dieser Tools. Heutzutage ist es etwas schwer zu finden. Wenn Sie dem Link 'XML Instance Generator' auf der Homepage von Kohsuke folgen, landen Sie im Niemandsland. Ich habe ein wenig weiter gegraben und herausgefunden, dass es derzeit bei Sun'sdev.java.net gehostet wird.
Xmlgen ist extrem einfach.

Es nimmt ein Schema (eine beliebige Schemasprache) und generiert daraus eine beliebige Anzahl von Beispieldokumenten. Es ist genau das, was Sie wollen, außer... Es unterstützt nicht alle Datentypen, die in der XML Schema Datatypes Spezifikation definiert sind. Und das ist etwas, auf das ich schon häufiger gestoßen bin.

Ich habe schon einige Male versucht, xmlgen zu verwenden, und jedes Mal scheiterte es an der fehlenden Unterstützung für xs:dateTime oder xs:pattern-Einschränkungen. Und es sieht nicht so aus, als ob in xmlgen besonders viel Arbeit investiert wurde, um das zu beheben.

XML-Instanz-Generator reparieren

Also dachte ich mir, dass ich das selbst in Ordnung bringen würde. Es stellte sich heraus, dass es gar nicht so schwer war, Unterstützung für dateTime hinzuzufügen, obwohl xmlgen eigentlich keine Erweiterungspunkte hat, die man implementieren kann. Also bleibt Ihnen im Grunde nur die Möglichkeit, a) den Quellcode im großen Stil zu hacken oder b) ihn nur ein wenig zu hacken, um Plugpoints hinzuzufügen und dann etwas anderes zu haben, das diesen Plugpoint implementiert - was ich getan habe.

Hoppla, xs:patternDas Hinzufügenvon Unterstützung für xs:pattern erwies sich als etwas knifflig. Wenn Sie mit dieser Art von Einschränkung noch nicht vertraut sind, sollten Sie wissen, dass es darum geht, Inhalte so einzuschränken, dass sie einem bestimmten regulären Ausdruck entsprechen, wie unten dargestellt.

[xml]
<simpleType name='better-us-zipcode'>
<restriction base='string'>
<pattern value='[0-9]{5}(-[0-9]{4})?'/>
</restriction>
</simpleType>
[/xml]

Wenn Sie nun den Wunsch haben, gültige Daten für diese Einschränkung zu generieren, dann sollten Sie in der Lage sein, Text aus diesem regulären Ausdruck zu erzeugen. Es hat sich herausgestellt, dass es eine ganze Reihe von Java-Bibliotheken gibt, die in der Lage sind, Text abzugleichen, aber es gibt überhaupt nichts, um Text zu erzeugen. Also habe ich meine eigene implementiert. Ich habe hier darüber gebloggt, und sie ist hier zu finden.

Danach war es ein Leichtes, xmlgen um die Unterstützung von xs:pattern-Einschränkungen zu erweitern. Das bedeutet, dass ich jetzt - mit nur wenigen Änderungen - in der Lage bin, einen Testsatz für ein ziemlich kompliziertes Schema zu erzeugen. Und ich bin mir ziemlich sicher, dass damit alle Fälle abgedeckt werden, solange ich die Anzahl der Instanzdokumente groß genug mache.
So, und nun zu einer Einschränkung wie dieser:

[xml]
<xsd:simpleType name = "TimeValue">
<xsd:restriction base = "xsd:string">
<xsd:pattern value = "[0-2][0-9]:[0-5] [0-5][0-9]0-9?"/>
</xsd:restriction>
</xsd:simpleType>
[/xml]

... erzeugt es Instanzen wie diese:

• 07:36
• 10:16:26
• usw.