[Allegro] Himmelfahrtskommando '08 : Gezeitenkräfte nutzen!

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

|> ...
|> ../nrw:nrwfield[@tag="100" and contains(., "Titelauflage")]
|> ~  - diejenige Wiederholung von #100 im aktuellen Datensatz,
|> ~    die "Titelauflage" enthaelt
|>
| Aha, also
| #100. ++ >a m>a
| ...
| #(a
| #cc c"Titelauflage"
| #)a


in etwa: Nur dass der XPATH-Ausdruck nur selektiert und nichts ausgibt
(ich koennte ja erst noch sortieren und weiterverarbeiten wollen), und
dass die Sache auch mehr als 60 Mal in einem Skript moeglich ist.



|> es gibt aber auch Operationen mit anderen Werten:
|>
|> count(preceding-sibling::record[@id=current()/@id]) = 0
|>
|> - -- wahr, wenn der aktuelle Satz der erste Datensatz mit
|> ~   gleichem id-Attribut ist (etwa bei Dublettenbereinigung)
|>
| Aha, also
| #00 +A =id
| ...     [hier weiter, wenn _gleiches_ Attribut, d.h. #00 = #uid]
| #+#
| #-A     [hier weiter, wenn _nicht gleich_ ]

Mitnichten. Nicht nur der unmittelbar vorausgehende, sondern
alle bislang (unterhalb des gemeinsamen Elternelements) gesehenen Saetze
werden untersucht. Das kann sehr ineffizient sein, es gibt aber
eine sehr maechtige Indexierungsfunktion (xsl:key) die dann hilft.
[Damit umgehen zu lernen ist zugegebenermassen nichttrivial]

In allegro kann ich zwar in Abwandlung des obigen Codes versuchen,
mir alle zuletzt gesehenen Saetze zu merken, das stoesst aber an
technische Grenzen.

[Das Beispiel entstammte folgendem Szenario: Eine Ergebnismenge wird
als XML exportiert, wg. Weiterverarbeitung und mangels Datenbankzugriff
muessen verknuepfte Aufnahmen ebenfalls als XML exportiert werden.
Dadurch entstehen massive Dubletten (x Baende exportieren
sicherheitshalber alle ihre Hauptaufnahme), die beim Export nicht
guenstig abgefangen werden koennen (s.o.), daher muss das XSLT-Skript
dann ueber XPATH die Dublettenverseuchung abfangen. Alternatives
durchsortieren zur effizienteren Dublettenbereinigung kann knifflig
werden, wenn die urspruengliche Ordnung aufrecht erhalten werden soll.


|> XPATH kann ueber die sogenannten Achsen (wie etwa "preceeding-sibling"
|> oben kreuz und quer durch das "Dokument" navigieren, das setzt
|> eigentlich eine DOM-Repraesentation voraus und ist - wenn man
|> eine komplette _Datenbank_ als Dokument ansieht, technisch nicht
|> trivial.
| Das ist milde ausgedrückt. So ein Ansatz "skaliert" nicht und ist
| deshalb indiskutabel.

Der /Ansatz/ ist eigentlich hervorragend: Wenn ich in der Verarbeitung
merke, dass ich Kategorie #20 eines anderen Datensatzes benoetige,
dann muss die herbeigeschafft werden, wozu habe ich sonst eine
Datenbank? Das programmatische Interface zur Datenbank muss dieses
"Nachladen" unterstuetzen, der Anwendungsprogrammierer muss ein
Gespuer darum entwickeln, welche Konstrukte in der Anwendung "teuer"
sind, das ist auch bei allegro nicht anders.

Das kann man so realisieren, dass ein gewisses Subset von XPATH-
Ausdruecken (eben nicht "kreuz und quer", sondern nur auf der
Kinder-Achse) eingesetzt werden kann, um sich einen Teil
der Datenbank (Satz oder Ergebnismenge) als temporaeres XML-Dokument
konstruieren zu lassen, auf dem dann volle XPATH-Operationen erlaubt
sind (XSLT kennt die document()-Funktion, kann also auf mehreren
Dokumenten operieren. Die document()-Funktion bekommt u.A. eine
URI als Parameter, die das zu ladende Dokument spezifiziert, hier
muss sich dann die Datenbank einschalten und fuer gewisse URIs
die entsprechenden Selektionen und Datenaufbereitungen vornehmen.

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSCAabGITJZieluOzAQKl9QP+M+Lx0IIoq1q0ek+mu5uvfszPpHOU0sAX
mwiMOa15RtHhxcrW+DVtlmiUjDlXmiwN4IH7V1Bw5pOtxpePX4o5oeztR5XvYcBM
v4uNIylqayHlgJV/cx/0DH93TohlnIJBhljUcKWh098J2ZlaX/AgZfjBM6hXssZ8
zGIfLOG+GMc=
=NOke
-----END PGP SIGNATURE-----