Erweiterbarkeit literaler XML-Elemente steuern (SAP-Bibliothek

Erweiterbarkeit literaler XML-Elemente steuern

Bei der Deserialisierung führen XML-Elemente im Eingabestrom, die im ST-Programm nicht angegeben sind, normalerweise zu einem Fehler. Wenn das verarbeitete XML-Format erweiterbar sein soll, können nicht explizit angegebene Elemente durch die Angabe des optionalen Attributs tt:extensible ohne weitere Verarbeitung überlesen werden. Das Attribut kann folgende Werte annehmen:

... ″on″|″deep-static″|″deep-dynamic″|″off″|″deep-off″...

Der Wert ″on″ drückt aus, dass das aktuelle Element direkte Unterelemente haben darf, die nicht explizit angegeben sind und entspricht der Standardeinstellung. Die Werte ″deep-static″ und ″deep-dynamic″ drücken aus, dass das aktuelle Element und seine Unterelemente erweiterbar sind. Mit dem Wert ″off″ wird die Erweiterbarkeit für das aktuelle Element aber nicht für seine Unterelemente deaktiviert; d.h. es ist selbst nicht um direkte Unterelemente erweiterbar, jedoch seine (angegebenen) Unterelemente sind es wieder. Mit dem Wert ″deep-off″ wird die Erweiterbarkeit für das aktuelle Element und seine Unterelemente abgeschaltet. Diese Einstellungen können in einzelnen Unterelementen lokal überschrieben werden.

Die Werte ″deep-static″ und ″deep-dynamic″ unterscheiden sich in ihrem Gültigkeitsbereich: ″deep-static″ wirkt nur innerhalb des Programmstücks, in dem es gesetzt ist; ″deep-dynamic″über Template-Aufrufe mit tt:apply und tt:call hinweg.

Die mit ″deep-static″ und ″deep-dynamic″ eingestellte tiefe Erweiterbarkeit wirkt auch in Fallunterscheidungen mit tt:switch und Gruppierungen mit tt:group, indem unerwartete (nicht durch einen Fall abgedeckte) Elemente übersprungen werden.

Beispiel

Dieses Beispiel zeigt, dass Erweiterbarkeit im Zusammenspiel mit optionalen Elementen (z.B. Elemente, die nur beim Eintreten einer Bedingung deserialisiert werden) problematisch ist, da die Erweiterbarkeit im allgemeinen dazu führt, dass solche optionalen Elemente nicht gefunden werden. Beispielsweise würde das folgende Programmstück

mit dem Eingabestrom

<r> <x/> <a>1</a> <b>2</b> </r>

nicht zur Deserialisierung A=1 führen, da das unerwartete Element x die Bedingung mit a negativ entscheidet. Sowohl x als auch a werden als "Erweiterungselemente" überlesen, und erst das nicht-optionale Element b wird als B=2 deserialisiert. Unter Verwendung von tt:group kann das Problem gelöst werden, allerdings wird damit auch die Reihenfolge von a und b aufgelöst: