XML Extensible Markup Language Hype or Hope ?. © [email protected] Problem Wie können...

XML

Extensible Markup Language

Hype or Hope ?

© [email protected]

Problem Wie können Informationen gespeichert werden ?

unabhängig von verwendeter Software standardisiert erweiterbar dauerhaft (technisch) einfach (technisch) migrationsfähig

binär (z.B. Serialisierung) ASCII (rel.) Datenbank So nicht !


Eigenschaften XML ist standardisiert XML ist eine Methode strukturierte Information

zu speichern XML ist HTML ähnlich (aber sehr anders) XML ist Text, der nicht zum Lesen gedacht ist XML ist ausführlich XML ist eine Familie von Technologien (XSLT...) XML ist neu! (oder doch nicht?) XML ist lizenzfrei, Plattform unabhängig,

unterstützt standardisierte XML-Programmierschnittstellen (SAX, DOM)

XML-Applikationen sind nicht standardisiert!


standardisiert Aufbau von XML-Dokumenten ist standardisiert

Struktur natürlich (?) nicht

Was bringt's ? Werkzeuge, APIs,... brauchen nur einmal entwickelt (gekauft) werden

TCP/IP

SMTP

email ClientAnwendung

Datenmodell

DarstellungXML

DTD


strukturierte Information Nicht Freitext, sondern Struktur + Daten Strukturierung durch Tags Daten und Metadaten2423|4567|100|21502122|4567|50|29906456|4567|10|19900

<ORDER><ARTIKEL ID="2423"><KUNDE ID="4567"><POSITION MENGE="100" PREIS="2150"/></KUNDE></ARTIKEL><ARTIKEL ID="2122"><KUNDE ID="4567"><POSITION MENGE="50" PREIS="2990"/></KUNDE></ARTIKEL><ARTIKEL ID="6456"><KUNDE ID="4567"><POSITION MENGE="10" PREIS="19900"/></KUNDE></ARTIKEL></ORDER>


EDIFACT

UNH+1+ORDERS:D:96A:UN'BGM+220+AGL153+9+AB'DTM+137:20000310:102'DTM+61:20000410:102'NAD+BY+++PLAYFIELD BOOKS+34 FOUNTAIN SQUARE PLAZA+CINCINNATI+OH+45202+US'NAD+SE+++QUE+201 WEST 103RD STREET+INDIANAPOLIS+IN+46290+US'LIN+1'PIA+5+0789722429:IB'QTY+21:5'PRI+AAA:24.99::SRP'LIN+2'PIA+5+0789724308:IB'QTY+21:10'PRI+AAA:42.50::SRP'UNS+S'CNT+3:2'UNT+17+1'


XML

<?xml version="1.0"?><Order confirm="true"> <Date>2000-03-10</Date> <Reference>AGL153</Reference> <DeliverBy>2000-04-10</DeliverBy> <Buyer> <Name>Playfield Books</Name> <Address> <Street>34 Fountain Square Plaza</Street> <Locality>Cincinnati</Locality> <PostalCode>45202</PostalCode> <Region>OH</Region> <Country>US</Country> </Address> </Buyer> <Seller> <Name>QUE</Name> <Address> <Street>201 West 103RD Street</Street> <Locality>Indianapolis</Locality> <PostalCode>46290</PostalCode> <Region>IN</Region> <Country>US</Country> </Address> </Seller>

<Lines> <Product> <Code type="ISBN">0789722429</Code> <Description>

XML by Example</Description>

<Quantity>5</Quantity> <Price>24.99</Price> </Product> <Product> <Code type="ISBN">0789724308</Code> <Description>

Developing XML Solutions</Description>

<Quantity>10</Quantity> <Price>42.50</Price> </Product> </Lines></Order>


HTML ähnlich The hypertext markup language is an SGML format(Tim Berners-Lee, 1991)

Hypertext spezielle Anwendung feste Tags

Markup Language Gruppen werden durch Kommandos (Markup) getrennt/identifiziert

auch Daten+Metadaten<h1>Ganz wichtig</h1>

heute eher HTMFADL Hypertext Markup, Formatting and Application Development Language ;-)


nicht zum Lesen ! Beispiel: ausführlich geschwätzig ! XML ist nicht geeignet zur

Darstellung manuellen Bearbeitung wer bearbeitet schon TCP-Pakete von Hand !

XML ist geeignet zur maschinellen Bearbeitung !!! zur Speicherung zum Datenaustausch


Familie von Technologien Editoren

nicht standardisiert/allgemein verfügbar

Transformationen XSLT, Stylesheets,...

Programmierwerkzeuge Parser, SAX, DOM

Datenbanken Parser erlauben nur das Lesen von XML-Dokumenten

Bearbeitung (z.B. Suchen, Filtern,...) manuell Datenbankfunktionalität auf XML-Dokumenten noch kaum verfügbar/verbreitet/verläßlich


Neu ! W3C working group seit Juli 1996 Verbesserung/Nachfolger von HTML

If you are doing catalogs, you need a <PRICE> Tag; for repair manuals you need <PARTNUM>; [...] I want to be able to create new information structures [...] This is why C++ lets you make your own classes (imagine a development environment that didn't!)(Dave Hollander)

SGML Standard Generalized Markup Language Textverarbeitungen, Ende 60er Jahre IBM: GML (Goldfarb, Mosher, Lorie), ISO 8897

Vereinfachtes SGML A slimmed-down SGML is not a new concept

(W3C XML ERB, 1997)


Standards,... sind so toll, daß jeder seinen eigenen haben sollte

Applikationen sind NICHT standardisiert

<ORDER><ARTIKEL ID="2423"><KUNDE ID="4567"><POSITION MENGE="100" PREIS="2150"/></KUNDE></ARTIKEL><ARTIKEL ID="2122"><KUNDE ID="4567"><POSITION MENGE="50" PREIS="2990"/></KUNDE></ARTIKEL><ARTIKEL ID="6456"><KUNDE ID="4567"><POSITION MENGE="10" PREIS="19900"/></KUNDE></ARTIKEL></ORDER>

<AUFTRAG><ARTIKEL ID="2423"><KUNDE>4567<MENGE>100</MENGE><PREIS WAEHRUNG="DM">2150</PREIS></KUNDE></AUFTRAG>

Namespaces Firma A benutzt <ARTIKEL> Tag, Firma B auch (mit anderer Sematik)

beide wollen gemeinsames Dokument erstellen

Konflikt ! Namespaces: Tags erhalten Namespace zugewiesen

<Auftrag xmlns="http://www.FirmaA.de" xmlns:FB="http://www.FirmaB.de">

<Artikel> .... </Artikel> 

<FB:Artikel> .... </FB:Artikel> 

</Auftrag>

Wichtig, wir arbeiten aber nur mit einem, lassen Namespaces also weg.


Zusammenfassung XML ist

Methode zur Speicherung/Übertragung von Informationen

standardisiert einfach (jedenfalls einfacher als SGML) neu (gut)

XML ist nicht Allheilmittel zum Datenaustausch

Struktur der Dokumente muß (vom Anwender) standardisiert werden

einfach (zu lesen,...) neu (gut)


XML Dokument besteht aus Tags (Metadaten) und Text (Daten) Tags haben einen Namen werden durch <> begrenzt

<Artikel>

zu jedem Tag gehört ein Ende-Tag </Artikel>

Tags können Attribute haben <Artikel ID="4711"> Attributwerte müssen in Anführungszeichen stehen

Bei Tags ohne Daten (leere Elemente) Abkürzung <Artikel ID="4711"/> statt <Artikel ID="4711"></Artikel>


XML Dokument contd. Tags können geschachtelt sein

<Person ID="[email protected]"><Name>

<First>Till</First><Last>Hänisch</Last>

</Name></Person>

Aber richtig, nicht so:<Person ID="[email protected]">

<Name><First>Till</First><Last>Hänisch</Last>

</Person></Name>

Welche Informationen als Attribut, welche als Daten

Keine generellen Regeln Daten, die das Element beschreiben/modifizieren als Attribut

sonst als Daten


Welche Tags ? Im Prinzip frei, aber wer sorgt dann dafür, daß die Dokumente korrekt sind ?

alle nötigen Informationen da richtige Schreibweise,....

DTD Document Type Definition legt fest, welche Tags wo möglich sind Instrument zur Standardisierung Validierung

Überprüfung eines Dokuments, ob mit DTD konform

Parser

Aufbau eines Dokuments

Zunächst die verwendete XML Version und Zeichensatz (XML-Deklaration)<?xml version="1.0" encoding="ISO-8859-1"?>Dann die DTD zum Dokument, hier als URL<!DOCTYPE DLmeta SYSTEM "http://www.dlmeta.de/dlmeta/2000/DLmeta.dtd">oder als Datei<!DOCTYPE CONTACTLIST SYSTEM "contactlist.dtd">Hier wird auch festgelegt, daß das äußerste Tag (Root) CONTACTLIST ist

Jetzt kommen die Tags<CONTACTLIST><!-- Ein Kommentar --!>

<CONTACT><NAME email="[email protected]">

<FIRSTNAME>Hans

</FIRSTNAME><LASTNAME>

Mustermann</LASTNAME>

</NAME></CONTACT>

</CONTACTLIST>


Beispiel Kontaktliste

Liste mit Kontakten (Name, Adresse,...) jede Liste hat Eigentümer

Tags <CONTACTLIST> - die ganze Liste <OWNER> - der Eigentümer <CONTACT> - ein Kontakt <NAME> - eine Person <FIRSTNAME> - Vorname <LASTNAME> - Nachname

als PK wird die email Adresse verwendet


DTD

<?xml version="1.0" encoding="ISO-8859-1"?>

<!ELEMENT CONTACTLIST (OWNER,CONTACT+)>

<!ELEMENT OWNER (NAME)>

<!ELEMENT CONTACT (NAME)>

<!ELEMENT NAME (FIRSTNAME?,LASTNAME)><!ATTLIST NAME email CDATA #REQUIRED>

<!ELEMENT FIRSTNAME (#PCDATA)>

<!ELEMENT LASTNAME (#PCDATA)>


Schritt für Schritt: 1<?xml version="1.0" encoding="ISO-8859-1"?>

DTD ist auch ein XML Dokument oder doch nicht ? (XML-Schema)

Zeichensatz ISO-8859-1 ISO Latin 1 <!ELEMENT CONTACTLIST (OWNER,CONTACT+)>

Tag CONTACTLIST Eigentlich reden wir von ELEMENTen, die vom Start- und Ende-Tag begrenzt werden

CONTACTLIST muß zuerst genau ein OWNER Element, dann ein oder mehrere CONTACT Elemente enthalten

CONTACT? hieße null oder eins CONTACT* hieße beliebig viele (auch null) (OWNER|CONTACT) hieße entweder OWNER oder CONTACT


2<!ELEMENT NAME (FIRSTNAME?,LASTNAME)><!ATTLIST NAME email CDATA #REQUIRED>

Element NAME kann kein oder ein FIRSTNAME Element und ein LASTNAME Element enthalten

hat ein Attribut (email), daß angegeben werden muß (#REQUIRED) und aus Text besteht (CDATA)

Attributlisten können ein oder mehrere Attribute umfassen Aufbau jedes Eintrags:

<!ATTLIST Element Attributname Typ Default> z.B.<ATTLIST Artikel Menge CDATA "0"><ATTLIST Artikel Gruppe (Papier|Stoff) #REQUIRED><ATTLIST Artikel Gruppe (Papier|Stoff) #IMPLIED><ATTLIST Datum Jahr CDATA #FIXED "2001">


3<!ELEMENT FIRSTNAME (#PCDATA)>

<!ELEMENT LASTNAME (#PCDATA)>

<!ELEMENT CONTACT (NAME)>

Elemente FIRSTNAME und LASTNAME enthalten Text (PCDATA: Parsed Character DATA), keine Tags !

Element CONTACT enthält ein NAME Element andere Typen

ANY - beliebige Tags<!ELEMENT Titel ANY>

EMPTY - leeres Tag<!ELEMENT Statuscode EMPTY>


Entities entsprechen etwa Makros

<!ENTITY Name "Ersetzungszeichen"><!ENTITY Copyright "&#xA9">

Benutzung (Entity-Referenz) mit &Entity;&Copyright;

> <

auch externe Entities<!ENTITY adr SYSTEM "http://www.daten.de/adr.xml">

<document>

&adr;

</document>

fügt die angegebene URI in das Dokument ein

Parameter Entities (mit %) - Makro in DTD

Dokument<!DOCTYPE CONTACTLIST SYSTEM "contactlist.dtd"><CONTACTLIST>

<CONTACT><NAME email="[email protected]">

<FIRSTNAME>Hans</FIRSTNAME><LASTNAME>Mustermann</LASTNAME>

</NAME></CONTACT><CONTACT>

<NAME email="[email protected]"><LASTNAME>du</LASTNAME>

</NAME></CONTACT>

</CONTACTLIST>

Entspricht das Dokument der DTD ? Validierung durch Parser, z.B. mit Xerces Sample SAXCountjava sax.SAXCount -v name


Was tun mit XML ? Daten müssen/sollen verwendet/gelesen werden

XML für Menschen ungeeignet transformieren XSLT

wandelt XML in irgendwas anderes um meistens wieder in XML oder in HTML

hier nur kurz: Umwandlung in HTML


XSLT Transformationen XSL (Extensible Stylesheet Language) Skript mit Formatierungsregeln

in XML geschrieben Umwandlung von XML in irgendwas (Text, XML, HTML)

Welche Regeln für welche XML-Elemente ? Pattern matching auf Pfade

/ - Dokument Root /CONTACTLIST - Element CONTACTLIST

Mächtige Konstrukte für z.B. Bedingungen,...

hier nur einfaches Beispieljava org.apache.xalan.xslt.Process -IN XML-Datei -XSL Stylesheet -OUT Zieldatei


Beispiel<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="html" indent="yes"/> <xsl:template match="/"> <xsl:apply-templates/> </xsl:template>

<xsl:template match="CONTACTLIST"> <html> <head><title>Kontakte von <xsl:value-of select="OWNER"/></title></head> <body bgcolor="#ffffff" text="#000000">

<h1>Kontakte von <xsl:value-of select="OWNER"/></h1> <xsl:apply-templates select="CONTACT"/> </body> </html> </xsl:template>

<xsl:template match="NAME"><xsl:value-of select="@email"/><xsl:value-of select="."/><BR/></xsl:template>

</xsl:stylesheet>


XML-Anwendungen Speicherung

z.B. Konfigurationsdateien

Datenaustausch RPC

SOAP

Darstellungsunabhängige Informationen Content Negotiation Web Anwendungen

u. v. a. m. Annotationen (RISOURCE) P2P (jaxp)


Konfigurationsdateien Warum mit XML ? "Jeder" kann XML

Anwender Werkzeuge (Parser,...)

hierarchische Strukturen bieten sich hier an Beispiel Remote Management, Plausibilitätsprüfung,...

<CONFIGURATION><SERVER>

<BASEURL>http://www.sonstwas.de/servlet

</BASEURL></SERVER><DB>

<DRIVER>jdbc:oracle:thin</DRIVER><SERVER>walker:1521:till</SERVER><USER>scott</USER><PASSWORD>tiger</PASSWORD>

</DB></CONFIGURATION>


Informationsaustausch eCommerce z.B. papierlose Bestellung

ORDER Beispiel von vorher Alternative z.B. EDIFACT

Probleme Standardisierung: DTD's (+Semantik) muß für verschiedene Anwender festgelegt werden, z.B. http://www.xml.org/

Andererseits: Transformationen sind einfach (XSLT,...)

bisher: Austausch von Daten, aber: wie werden Funktionen im Zielsystem "aufgerufen" ?

z.B. "Bestellung ausführen" oder "stornieren" ?


SOAP verteilte Anwendungen

Austausch von Daten Aufruf von Methoden entfernter Objekte "klassisch": RPC, CORBA, DCOM, RMI,...

Alternative: SOAP XML-kodierter RPC

standardisierter Nachfolger von XML-RPC portabel (da XML, HTTP basiert) einfach/problemlos (s. o.) (+) stateless (Transaktionen,...) (-) Overhead (gegenüber RPC, CORBA,...)

Beispiel: Lagerbestand abfragen


SOAP Beispiel Frage:

<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body>

<till:getBestand xmlns:till="http://www.tillh.de/xmlns/shop" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<Hersteller>Tefal</Hersteller><Artikel>4711</Artikel>

</till:getBestand></SOAP-ENV:Body></SOAP-ENV:Envelope>

und Antwort<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body>

<till:getBestandResponse xmlns:till="http://www.tillh.de/xmlns/shop"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><Bestand>

<Hersteller>Tefal</Hersteller><Artikel>4711</Artikel><Bestand Mengeneinheit="stk">42</Bestand>

</Bestand></till:getBestandResponse>

</SOAP-ENV:Body></SOAP-ENV:Envelope>


Web Anwendungen Content Negotiation

Darstellung im Web (HTML) Als Ausdruck (PDF) Auf Handy (WML)

Web-Anwendungen (z.B. Intranet) komplexes HTML für Anwender schwierig zu pflegen Layout-Änderungen aufwendig (an vielen Stellen)

z.B. in HTML-Dateien, CGI-Scripts,... Trennung von Inhalt (XML) und Darstellung (HTML) Teamarbeit bei Erstellung

Programmierer/Content-Lieferanten <--> Designer

Content Management


Zusammenfassung XML Dokumente enthalten Elemente, die durch Tags begrenzt werden

Einfache Regeln (Passende öffnende und schließende Tags, Attributwerte in "",...)

Struktur kann durch DTD beschrieben werden muß aber nicht - Gegensatz zu SGML

Überprüfung durch Validierung (Parser) Transformation durch XSLT Namespaces vermeiden Kollisionen weites Feld

XML Extensible Markup Language Hype or Hope ?. © [email protected] Problem Wie können...

Documents

Transcript of XML Extensible Markup Language Hype or Hope ?. © [email protected] Problem Wie können...