[Allegro] Vb.212: Mehr XML-Komfort / OAI-Client mit aiaqs

Mi Jan 7 22:47:22 CET 2009

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

Lieber Herr Eversberg,

Eine Nachfrage:

> Aus diesen Gruenden musste etwas geschehen, um die XML-Verarbeitung
> zu erleichtern. Und das sieht ab V29 so aus:
> 
> 1. b"<abc" und e"<abc" gehen jetzt. Das ist nicht nur fuer XML gut,
>    sondern wurde sowieso Zeit.

"gehen jetzt" bedeutet: Mit Semantik wie in der Exportsprache, d.h.
Zeichenkettenvergleich auf kleiner/Groesser "abc"?

> Aber noch viel besser, denn das wuerde noch nicht recht lohnen:
> 
> 2. Neue Manipulationsbefehle x und X spezifisch fuer XML.
>    Damit hat man eine Reihe von Moeglichkeiten:
>    (Achtung: in allen Faellen genau auf die Anfuehrungszeichen achten!)
> 
> var (x'abc')   liefert in beiden Faellen (A oder B) den  INHALT
>                aber ein  <abcd>  wird nicht beachtet.
> 
> var (X'abc')   mit grossem X
>                liefert  <abc...>INHALT
...

> Noch zwei Moeglichkeiten:
>
> var (x'abc a1="cde"')   mit kleinem x
> liefert  INHALT, aber nur, wenn das Attribut a1 mit Wert cde vorh.
> ist. Dabei muss a1 nicht das erste Attribut von <abc ... sein.

... und es macht hoffentlich keinen Unterschied, ob in den Fremddaten
al="cde" oder al='cde' steht.

> Hinweis Neu ab V29.0: Alle sog. "Whitespace"-Zeichen, also die Codes 9,
> 10, 13 und 32, werden, in welcher Anzahl und wie auch immer aufeinander
> folgend, vom Befehl "spaces" durch genau ein Leerzeichen ersetzt.

XPath ( http://www.w3.org/TR/xpath ) ist die relevante Spezifikation
zum Adressieren von Elementen in XML-Dokumenten, hier gibt es eine
Funktion "normalize-spaces()" die dasselbe tut, jedoch zusaetzlich
Spatien am Anfang und Ende von Text entfernt:

Im Beispiel:

<datafield tag="245" ind1="0" ind2="0">
  <subfield code="a">Shakespeare</subfield>
  <subfield code="b">Der Dichter und sein Werk. In 2 Bden</subfield>
  <subfield code="c">Max J Wolff</subfield>
</datafield>

gibt es zwar innerhalb der "subfield"-Elemente keinen ueberzaehligen
Leerraum, der textuelle Inhalt des "datafield"-Elements ist allerdings

"
  Shakespeare
  Der Dichter und sein Werk. In 2 Bden
  Max J Wolff"

hat also nicht nur Zeilenumbrueche und Mehrfachspatien zwischen den
einzelnen Bestandteilen, sondern auch komplett unerwuenschten Leerraum
vor "Shakespeare".

> Mehrfach-Felder!?
> -----------------
> Und was ist, wenn ein XML-Tag mehrfach auftritt, mit oder ohne
> differenzierende Attribute? Dann geschieht folgendes:
> var (x"abc")
> liefert in der iV saemtliche Inhalte der evtl. mehreren Tags <abc>,
> getrennt durch ;;;. (Im Quelltext koennen sie beliebig verstreut sein.)

Das halte ich fuer ungeschickt: XML Version 1.0 erlaubt z.B. von
den Zeichen < 32 nur 9, 10 und 13, das Zeichen 20 ("¶") waere also
ein eindeutiger Trenner, der nicht aus den Fremddaten stammen
kann. ";;;" hingegen wird bestimmt einmal vorkommen, weil es so
huebsch ornamental ist...

viele Gruesse
Thomas Berger

P.S.: Ich halte die neuen Funktionen fuer halbwegs tragfaehig, was
"historisches" XML angeht, enthalten die Fremddaten jedoch
Namespace-Praefixe (etwa zwingend in OAI-PMH, wo verschiedene,
unabaengige Formate ineinandergeschachtelt werden), greift dieser
flex-x-"Parser" nicht, denn die konkrete Zeichenkette fuer das
Praefix ist streng genommen nur eine temporaere interne Verabredung des
konkreten Dokuments. Es kann sein, dass das einmal ein Problem sein
kann und dann doch mit XML-Methoden vorverarbeitet weren muss...

Ich bin ausserdem noch nicht ueberzeugt davon, dass man komplexe Importe
mit der Flex-Sprache effizient hinbekommt: Die Import-Sprache ist zwar
enorm kleinschrittig (man verliert schnell den Ueberblick, ich halte sie
aus der Perspektive nicht fuer wirklich effizient), hat aber
interessante Positionier- und Trunkierbefehle. Bislang gibt es nur
die Flex-Loesung zum z-Client in a99, die in einer Datei diverse Formate
kreuz diverse Zeichencodierungen importiert, m.E. eher grob. Es waere
interessant, einmal einen richtig ausgefeilten Import (etwa von D-MARC
nach $A) zu sehen.

Zu bedenken ist auch, dass m.W. auf allen Plattformen funktionierende
XML-Parser bzw. XSLT-Transformatoren zur Verfuegung stehen, fuer
Capriccio habe ich z.B. neulich einen Import aus dem DNB-Datenshop
realisiert, der auch MABXML beherrscht, indem XML-Daten in etwas
"klassisches" zurueckgewandelt werden: Solange ISO2709-artige
Formate und XML-Formate koexistieren, hat man dann im wesentlichen
nur einen Import (der klassischerweise schon seit Jahren vorhanden
ist). Sofern sich flexbasierte "Direktimporte" aus XML-Formaten
als besser, besser gepflegt und besser pflegbar erweisen, kann man
natuerlich mittelfristig den Schuh umdrehen und wuerde ISO-Dateien
erst einmal mit den dafuer existierenden Konvertern nach XML umwandeln.

Tendenziell sind die traditionellen Datenformate niedrigdimensional,
d.h. in einer Datei sind viele Datensatze, darin viele Datenfelder,
diese sind (bezogen auf die gleiche Feldnummer) wiederholbar,
sie enthalten beliebige Unterfelder, diese sind (bezogen auf
gleichen Unterfeldcode) wiederholbar, und intern sind die Felder
und Unterfelder evtl. noch textuell substrukturiert. Genuine
XML-Daten hingegen koennen ganz gewaltig geschachtelt sein und
damit zusammengehoerendes viel besser zusammenhalten, dafuer wird
man sich nicht unbedingt eine $A-format oder MAB-Diskettenartige
Textdateienstruktur ausdenken bzw. damit gluecklich werden. (Finde
ich, obwohl hier vor einiger Zeit ja auch JSON propagiert worden
ist)

Konkret fuer MABXML-1:
Hier wandle ich per XSLT die MABXML-Daten in eine Art MAB-Diskette
um, d.h. Zeilenumbrueche und alles wie MAB-Diskette, Zeichencodierung
jedoch UTF-8, wobei die Steuerzeichen wegen der oben erwaehnten
Beschraenkung nicht so wie definiert (also etwa Unterfeld als Zeichen
31) umgesetzt werden koennen, sondern "visualisiert" sind (d.h.
Unterfeld als Dreieck). Darauf wird ein Import angewandt, der im
wesentlichen MAB-Diskette ist, jedoch die UTF-8-Codierung sowie die
visualiserten Steuerzeichen beruecksichtigt:

Fragment der Steuerdatei:

rem Download derzeit (2008-12-12) kein XML, muss erst hergestellt werden
for /F %%s in ("<datei>") do echo %%s> pre.tmp
for /F %%s in ("</datei>") do echo %%s> post.tmp
copy /B pre.tmp+%dsfile%+post.tmp %dsfile%.xml
del pre.tmp
del post.tmp

set dsfile=%dsfile%.xml
rem Import.exe kann kein natives XML, wir konvertieren
rem zunaechst in ein diskettenartiges Format
cscript %-P%\xsltproc.js //Nologo -o dnbds.tmp %-P%\mabxml2mab.xsl %dsfile%

... Verarbeitung wie MAB (vgl. etwa
http://svn.gymel.com/acxt/produkt/mabimpdir/mabproc.bat )

"cscript" ist dabei der Aufruf des Windows-Scripting Host,

xsltproc.js habe ich aus dem Internet geklaut und etwas erweitert, damit
koennen die systemseitigen Active-X-Objekte (oder wie sie heissen
moegen) mit der Aufrufsyntax des bekannten Programms xsltproc
angesprochen werden. Bezug ueber

http://svn.gymel.com/repos/allegro/acxt/mabimp/trunk/xsltproc.js

(Systemvoraussetzungen sind MSXML6.0, keine Ahnung, ob das mit
Installation von IE 6 erfuellt ist oder mit irgendeiner Version des
.NET-Frameworks)

mabxml2mab.xsl ist ein triviales Stylesheet zur Umwandlung von MABXML
in Text, fuer MARCXML ist es m.W. sogar noch trivialer.

http://svn.gymel.com/repos/allegro/acxt/mabimp/trunk/mabxml2mab.xsl

"Homepage" fuer die zugehoerigen Parameterdateien ist

http://svn.gymel.com/acxt/produkt/mabimpdir/

bzw.

http://svn.gymel.com/acxt/produkt/

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

iQCVAwUBSWUi6mITJZieluOzAQJF7wQAt+vX+3+SRE4zFfpZM7PLa84XdY9isAOG
SJxk+JpEpcibb8rBcvSiAsTrwi/qB8bDL1wqP3LrXqMf9szXQduJJlq8V5QKTNve
37gVlkNnaSixGtkWwOHxe641bbpC5JoVIsCTkQc76cxWVgYspCIjuHjz6EEpCl67
9TVgW+axxUk=
=YIFV
-----END PGP SIGNATURE-----