XML-Schema (XSD) with sequence constraint

[bernardkessler]

We have encountered a problem with a XML-Schema (XSD) that was generated with ili2c.

If the sequence of elements (e.g. the sequence of attributes within a class) in a XTF-file does not match the sequence given by the XSD, the validation of the XTF against the XSD fails. This is probably due to the xsd:sequence constraint in the XSD.

Is there any posibility to generate a XSD without this constraint?

[edigonzales]

Interessehalber: Warum prüft ihr gegen das XSD?

Im Kern ist es glaub ein XtfReader o.ä., der leider die Reihenfolge nicht wirklich gut handeln kann und darum auch ilivalidator wohl den Fehler nicht finden kann.

[bernardkessler]

Die genauen Hintergründe kenne ich ehrlich gesagt auch nicht. Es geht aber um eine Software, die speziell für den digitalen Genehmigungsprozess der Nutzungsplanung entwickelt wurde und beim Datenimport auf dieses XSD aufbaut und es auch zur Struktur-Prüfung des eingereichten XTF nutzt.

Das Problem ist nun, dass verschiedene Softwares wohl ein unterschiedliches Verständnis davon haben, wie die Attributreihenfolge aussehen müsste (v.a. bei verschachtelten Klassen mit abstrakten Basis-Klassen).
Wir selber verwenden FME und haben keine Probleme beim Einlesen unterschiedlicher Attribut-Reihenfolgen, aber für diese spezielle Software ist es eben ein Problem.

Ich habe mich schon gefragt, ob ich im XSD einfach alle xsd:sequence constraints durch xsd:all ersetzen könnte, wollte mich aber zuerst erkundigen, ob es vielleicht einen offiziellen Weg gibt.

[claeis]

Die Reihenfolge ist im INTERLIS-Referenzhandbuch definiert/geregelt (Kap. 3.3.7 Codierung von Klassen); darum macht xsd:sequence Sinn. Dass der ilivalidator das (noch) nicht richtig prüft, ist ein Mangel im ilivalidator (claeis/ilivalidator#86). Das im Generieren des XSD anzupassen/oder zu ändern, scheint mir falsch, weil damit eine einfache Validierung mit xsd-Werkzeugen entfallen würde.

[bernardkessler]

In Ordnung, vielen Dank für die Information. Dass die Reihenfolge der Attribute klar geregelt ist, war mir tatsächlich nicht bewusst. Dann werden wir nach anderen Lösungen suchen und der Issue kann aus meiner Sicht geschlossen werden. Besten Dank.

[bernardkessler]

Es ist doch noch eine Frage aufgetaucht, nämlich ob ili2c in unserem Fall ein korrektes XSD generiert.

Das Originalmodell, auf das ich mich beziehe, findet sich unter: https://models.geo.be.ch/Grundlagen_und_Planung/Raumplanung_Grundstueckskataster/Nutzungsplanung_BE_V1_0.ili

Nachfolgend versuche ich das entscheidende Konstrukt und die daraus folgende Problematik schematisch aufzuzeigen:

CLASS BasisKlasse (ABSTRACT) =
Attr1 : MANDATORY TEXT100;
Attr2 : TEXT100;
Attr3 : MANDATORY TEXT*100;
END BasisKlasse;

ASSOCIATION BasisKlasse_Zusatz (ABSTRACT) =
ZusatzAttr (ABSTRACT) -- {0..1} Zusatz;
RefBasisKlasse (ABSTRACT) -- {0..*} BasisKlasse;
END BasisKlasse_Zusatz;

CLASS KonkreteKlasse EXTENDS BasisKlasse =
Attr2 (EXTENDED) : MANDATORY TEXT100;
Attr4 : TEXT100;
Attr5 : TEXT*100;
END KonkreteKlasse;

ASSOCIATION KonkreteKlasse_Zusatz EXTENDS BasisKlasse_Zusatz =
ZusatzAttr (EXTENDED) -- {1} Zusatz;
RefKonkreteKlasse (ABSTRACT) -- {0..*} KonkreteKlasse;
END BasisKlasse_Zusatz;

ili2c generiert daraus ein XSD mit folgender, zwingend einzuhaltender Attributreihenfolge:

• Attr1
• Attr2
• Attr3
• ZusatzAttr
• Attr4
• Attr5

Wenn ich es richtig verstehe, entspricht diese Reihenfolge der Regelung gemäss Kap. 3.3.7 im Referenzhandbuch.
Nun gibt es aber offenbar eine Relativierung gemäss Kap. 3.3.9, die mein eigenes Interlis-Verständnis übersteigt, aber wohl darauf hinausläuft, dass man zum Zeitpunkt der Definition von "ASSOCIATION BasisKlasse_Zusatz (ABSTRACT)" noch nicht weiss, wie die ASSOCIATION erweitert wird und die Möglichkeit besteht, dass sie gar nicht eingebettet wird. Deshalb wird die ASSOCIATION in einigen Systemen erst eingebettet, wenn feststeht, dass sie eingebettet werden kann, was wiederum zu folgender Reihenfolge führt:

• Attr1
• Attr2
• Attr3
• Attr4
• Attr5
• ZusatzAttr

Ich hoffe, ich habe alles richtig und einigermassen verständlich wiedergegeben. Jedenfalls stellen wir uns nun folgende Fragen:

1. Gibt es hinsichtlich Attributreihenfolge einen eindeutigen Standard, den theoretisch jedes Interlis-System erfüllen können müsste, oder gibt es Spielraum für unterschiedliche Interpretationsweisen?
2. Falls es einen eindeutigen Standard gibt, wird dieser im ili2c Schema korrekt umgesetzt?

[claeis]

m.E. ist das RefHB eindeutig.

In Bezug auf obiges Beispiel: Die ASSOCIATION BasisKlasse_Zusatz wird eingebettet bei CLASS BasisKlasse (dass die konkreten Zielklassen noch nicht klar sind, spielt keine Rolle). Die Definition der ASSOCIATION KonkreteKlasse_Zusatz ändert daran nichts mehr (auch mit dieser ASSOCIATION sind ja auch immer noch Erweiterungen der Zielklassen möglich, so dass weitere/andere Objekte referenziert werden könnten (auch das würde an der Einbettung/Reihenfolge der Rolle ZusatzAttr bei BasisKlasse nichts ändern)).