XML-Programmierung mit XDuce Bearbeitet von: Daniel Beck Taoufik Romdhane Logische Aspekte von XML Proseminar im Sommersemester 2003 Prof. Gert Smolka
Inhalt Was ist XDuce? Typaspekte Pattern Matching Restriktionen und Probleme Zusammenfassung
Was ist XDuce? Man spricht “Transduce” aus ;) Eine funktionale Programmiersprache Typen sehen der DTD ähnlich aus (Document Type Definition) XML Dokumente sind Werte Statisch typisiert Ähnlich zu ML
Typaspekte Beispiel Typdefinition für ein Adressbuch : type Addrbook = addrbook[(Name, Addr, Tel?)*] type Name = name[String] type Addr = addr[String] type Tel = tel[String] Entsprechendes DTD: <!ELEMENT addrbook (name, addr, tel?)*> <!ELEMENT name #PCDATA> <!ELEMENT addr #PCDATA> <!ELEMENT tel #PCDATA>
Typen Mächtiges Typsystem: Typen werden als reguläre Ausdrücke angegeben (DTD) Typsystem entspricht den regulären Baumautomaten Strukturelles Subtyping Statisches Typechecking Typen als Menge von Werten Später mehr zur Grammatik
Typdefinition T ::= X Variable B Basistyp () leere Sequenz l[T] Label T,T Konkatenation T|T Vereinigung KFG Daniel Restriktionen
Was ist mit *, + und ? Kleenesche Stern wird rekursiv definiert: T* = T,T* | () + und ? sind Abkürzungen für: T+ = T,T* T? = T|()
Typen als Menge von Werten Funktion [[.]]: nimmt einen Typ und eine Umgebung ρ, die Typvariablen auf Mengen von Werten bildet gibt eine Menge von Werte zurück
Subtyping-Relation Es gibt Typen, die in andere „enthalten“ sind (Teilmenge- Relation): a <: a+ a „ist Teilmenge von“ a+ Ein Typ ist ein Subtyp von einem anderen, wenn der erste eine Teilmenge vom letzten beschreibt Die Werte die links enthalten sind, sind auch rechts enthalten Noch umaendern … Menge reinbringen !
Subtyping-Relation Addressbuch-Beispiel (1) Beispiel: Der Wert „mybook“ val mybook = addrbook[ name[“Peter”], addr[“Berlin”], name[“Hans”], addr[“Bonn”], tel[“123-34-2312”]] Zur Erinnerung: Definition vom Typ Addressbuch: type Addrbook = addrbook[(Name, Addr, Tel?)*] type Name = name[String] type Addr = addr[String] type Tel = tel[String]
Subtyping-Relation Addressbuch-Beispiel (3) Kann man dem Wert „mybook“ den Typ „Addrbook“ zuweisen? val mybook = addrbook[ name[“Peter”], addr[“Berlin”], name[“Hans”], addr[“Bonn”], tel[“123-34-2312”]] „mybook“ hat den Typ: addrbook[Name,Addr,Name,Addr,Tel] Und: <: addrbook[(Name,Addr,Tel?)*] := Addrbook Warum klappt die Zuweisung daoben
Typrekursion Bis jetzt wurde das Typsystem als kontextfreie Sprache definiert Aber: Subtyping wäre dann nicht entscheidbar Deswegen: Restriktion auf Rechts- Rekursion Jetzt: gleich mächtig mit den regulären Baumautomaten Beispiel type X = Int, X, String | () warum???
Pattern Matching Sehr ähnlich zu dem aus ML, aber durch reguläre Ausdrücke mächtiger Beispiel: erstes Tripel finden fun firstTriple: (Name,Addr,Tel?)* -> (Name,Addr,Tel)? = ps:(Name,Addr)* , t:(Name,Addr,Tel), rest:(Name,Addr,Tel?)* -> t | whole:(Name,Addr,Tel?)* -> () Pattern Matching besteht aus 2 Fälle: (Name ,Addr)* werden übersprungen, t wird das erste Tripel zugewiesen Sonst gibt der zweite Fall () zurück.
Pattern Matching Regeln „first matching policy“: Ambiguität: ps:(Name,Addr)* -> ps | t: (Name,Addr) -> t Mehrere Patterns "matchen" dieselbe Eingabe Lösung: Nimm erstes passendes Pattern
Pattern Matching Regeln „longest match“: Ambiguität: ps:(Name,Addr,Tel?)*, t:(Name,Addr,Tel), rest:(Name,Addr,Tel?)* Ein Pattern kann eine Eingabe unterschiedlich „matchen“ Welcher Tripel ist nun mit t gemeint? Lösung: Das früher auftretende Pattern hat höhere Priorität Jedes Pattern darf so viel wie möglich „matchen“ Deswegen „matcht“ t das letzte Tripel in der Eingabe ??
Pattern Matching Exhaustiveness Mit Subtyping wird geprüft, ob ein Pattern erschöpfend („exhaustive”) ist Im Beispiel der Tripelsuche: fun firstTriple: (Name,Addr,Tel?)* -> (Name,Addr,Tel)? = ps:(Name,Addr)* , t:(Name,Addr,Tel), rest:(Name,Addr,Tel?)* -> t | whole:(Name,Addr,Tel?)* -> () Muss folgendes gelten: (Name,Addr,Tel?)* <: ((Name,Addr)*,(Name,Addr,Tel),(Name,Addr,Tel?)*) | (Name,Addr,Tel?)*
Restriktionen der Sprache XDuce wird weiter entwickelt. Zur Zeit fehlen wichtige Features: Funktionen höherer Ordnung Polymorphismus Parametrisierte Typen (Typkonstruktoren) … : Funktionen dessen Argumente auch Funktionen sein können (wie in ML) Fn (String,a) -> a*
Probleme der Sprache Pattern- und Typsystem gleich mächtig wie Baumautomaten Operationen sind sehr teuer (Typechecking: EXPTIME)
Zusammenfassung Funktionale und typisierte Sprache mit XML- Dokumenten als primitive Werte Schwerpunkte: Strukturelle Typen mit regulären Ausdrücken Pattern Matching mit regulären Ausdrücken Was noch fehlt: (geplant) Funktionen hoeherer Ordnung (Parametrischer) Polymorphismus Object-Orientierte Features (wie in den XML Spezifikationen vom W3C) Effizienz?
Anwendungen Beispiele von Progammen, die in XDuce geschrieben sind: HTML2Latex : Ein Konverter (264 Zeilen) Diff: zeigt an ob sich eine XML Datei verändert hat (300 Zeilen)
Alternativen zu XDuce CDuce YAT XMLambda Basiert auf XDuce First-class Funktionen Noch besseres Pattern Matching Subtyping-Algorithmus ohne Backtracking Man kann auch Typen unter Schnitt, und Komplement bilden YAT vom Prinzip her XDuce sehr nah XMLambda Funktionen höherer Ordnung Parametrisches Polymorphismus Subtyping-Algorithmus ohne Backtracking gucken
Referenzen Haruo Hosoya and Benjamin C. Pierce: Regular expression pattern matching for XML. A typed XML processing language (preliminary report). Unter : http://xduce.sourceforge.net/papers.html Uwe Schöning, Theoretische Informatik – kurzgefasst. Um mehr über XDuce zu wissen: xduce.sourceforge.net/ XMLambda www.cse.ogi.edu/~mbs/pub/xmlambda/