[Allegro] FLEX-Probleme mit hierarchischen Untersätzen

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

Am 14.01.2014 10:39, schrieb Bernhard Eversberg:
> Am 13.01.2014 08:23, schrieb Bernhard Eversberg:
>>
>> Nicht nur der Befehl "var" hat diese Eigenheit, auch "if" ist damit
>> behaftet: (Für acon gilt dies nicht!)
>>
>> if #41 mes Zum Kuckuck
>>
>> bringt die Message "Zum Kuckuck" AUCH DANN, wenn #41 nur in einem der
>> hierarchischen Untersätze vorkommt.
>>
> Dies stimmt, wie wir inzwischen feststellen mußten, nicht, sondern acon
> ist in gleicher Weise betroffen. (Die Funktionen sind intern identisch.)
> 
> Wir werden das für beide Programme richten, V34.0 arbeitet dann
> entsprechend der Doku und sicher auch gemäß der Erwartung.
> Ein Flag, das dazu dienen würde, das bisherige Verhalten einzustellen,
> scheint uns im Moment eher unnötig, aber wir könnten uns da irren.
> Jedenfalls ist es in den Zusammenhängen, in denen  var #... und if #...
> auftritt, wohl kaum jemals erwünscht, daß nachfolgende hierarchische
> Sätze gleich mit durchsucht werden. Vorstellen kann man sich's aber
> doch, daß das mal erwünscht sein könnte. Kann sich jemand an Fälle
> erinnern, wo das der Fall war?

Tja, eigentlich(?) werden die hierarchischen Saetze ja so
aufgefasst, dass fehlende Daten aus /hoeheren/ Stufen implizit
zu ergaenzen sind, also gewissen, /vorausgehenden/ Untersaetzen
und der Hauptaufnahme (Richtung dabei rueckwaerts, also vom
Spezifischen zum Allgemeinen)

Allerdings ist mir schon mehrfach begegnet, dass Erscheinungsjahre
nur "bei den Baenden" eingetragen wurden und nach meinem Hinweis,
dass aber eigentlich jede Aufnahme eine Datierung benoetigt, damit
Kurzanzeigen und Restriktionen "funktionieren", entstand das
Desiderat, fehlende Daten aus (der ersten) Unteraufnahme zu
ermitteln, also aus konkret zugeordneten niedrigeren Stufen,
d.h. gewisse nachfolgende Untersaetze sind zu betrachten, aber
nicht alle. Richtung dabei vorwaerts, also vom Allgemeinen zum
Speziellen (eines der Beispiele, das ich im Sinn habe, hatte
uebrigens verknuepfte Untersaetze).

Das von Ihnen beschriebene Verhalten der Standardaktion "#" bzw. "!"
>>>
FALLS jedoch vorher mit  sub #01 3  auf den Untersatz mit #01 3
geschaltet wurde, ergeben die Befehle nur dann etwas, wenn das betr.
Feld in diesem Untersatz oder einem der nachfolgenden auftritt. Das
ist erst recht ominös.
<<<
laesst den Rueckschluss zu, dass der gesamte Satz ab der aktuellen
Position bis zum Ende untersucht wird, das macht fuer die Hauptaufnahme
Sinn (wenn man auf das Szenario des vorigen Absatzes abzielt), fuer
Untersaetze fast: Das Durchsuchen muesste einfach stoppen, sobald
dabei eine Unteraufnahme gleicher Hierarchiestufe wie die Ausgangs-
Unteraufnahme erreicht wird.


Die Exportsprache kennt neben den Befehlskennern / Kategorie-Identifikator-
Praefixen "#" und "!" auch noch Modifikatoren dafuer, naemlich
(10.2.6.1)

#^

#_

#<Alt+25>

und aus den zugehoerigen Beschreibungen wird leider wenig klar, fuer
jede der vier Varianten ist eigentlich zu notieren, was in den
Kombinationen folgender Faelle passiert:
Aktuell ist Hauptaufnahme / Untersatz
Aktuell ist mit/ohne der Kategorie
Irgendwo uebergeordnet ist ein Untersatz mit/ohne die Kategorie
Echt uebergeordnet ist Hauptaufnahme mit/ohne die Kategorie
Echt untergeordnet ist ein Untersatz mit/ohne die Kategorie

Zum Vergleich: XPath, also eine Adressierungssprache fuer XML-Dokumente,
die ja wie die hierarchischen Aufnahmen Baum-artig organisiert sind,
kennt mehrere (genauer: 13 verschiedene) Achsen
< http://www.w3.org/TR/xpath/#axes >:

Die von mir geschilderten Use-Cases entsprechen dabei "ancestor-or-self"
bzw. "descendant-or-self", das Standardverhalten von "#" deutet auf
die Vereinigung aus "descendant-or-self" und "following" hin (wobei das
"following" nicht gut ist), koennen Sie fuer die drei modifizierten
Zugriffsvarianten angeben, welchen XPath-Achsen das entspricht (bzw.
wenn es nicht passt, wird es umso interessanter)?

viele Gruesse
Thomas Berger