Hallo Nachtmensch ;-)
Was Du geschrieben hast funktioniert einwandfrei (!) aber (und jetzt bitte nicht lachen oder weinen ;-) ) nicht bei mir.
Wenn ich das was ich gelesen habe richtig verstanden habe, liegt das wohl daran, dass ich bisher keine id's für li-Elemente habe (obgleich diese ja durch generate-id(.) (zumindest für den Ausgabeknoten) erzeugt werden)?
Daran wird es nicht liegen.
gernerate-id() erzeugt einen ID für eine Element, erstmal intern zu "runtime". Natürlich kann man dann diese ID auch für die Ausgabe verwenden.
Dazu noch eine Frage nebenbei: Könnte es in dem Kontext Konflikte geben, wenn ich in meinem Schema an mehreren Stellen Attribute namens "id" definiert habe, die allerdings nicht vom Typ ID sind?
Es wird immer wieder empfohlen id wirklich als Typ ID zu benutzen.
Aber ein Konflikt sollte es deshalb nicht geben.
Was mich noch etwas verwirrt ist folgendes:
Zum testen habe ich das Template in einem neuen und ansonsten leeren XSL probiert und da funktionierte es natürlich wie es soll.Im XSL, in dem ich es verwenden möchte hingegen scheitert es, bei ansonsten identischen Bedingungen (gleiches Schema und XML) an der Auswertung von "li[generate-id(.) = generate-id(key('likey', .)[1])]".
Was genau passiert da?
Gibt es eine Ausgabe - wenn auch eine falsche - oder wird nichts dargestellt?
Gegebenfalls muss du mehr von deinem "einsatzt" XSL zeigen.
Erfolgreich hingegen ist, dass ich nun doch einen Ausdruck gefunden habe mit dem ich mit for-each die Knotenmenge so selektieren kann, dass ich nachträglich nicht mehr filtern muss:
"ul/li[not(. = preceding-sibling::li)]"
Das deutet aber darauf hin, dass du nicht im Template mit match="litlist/ul" bist, oder dass dein XML etwas anders aussieht. ;-)
Damit funktioniert es jetzt ganz gut.
Nun, dann passt es eigentlich ;-)
Grüße
Thomas