Extensible Markup Language

Toplinks zu diesem Thema:
Sprachen, Daten, Dokument, Enthalten, Enzyklopaedie, Gps, Grafik, Informationen, Inhalt, Speicher, Sprache, Start, Arbeit, Besteht aus, Beziehung, Browser, Buch, Dokumentation, Englisch, Exchange, Familie, Immobilien, Information, Java, Kinder, Konzept, Modelle, Online, Owl, Print

Der Artikel Extensible Markup Language gehört zur Kategorie: Beschreibungssprachen, Datenformat, XML
Die Extensible Markup Language, abgekürzt XML, ist ein Standard zur Erstellung maschinen- und menschenlesbarer Dokumente in Form einer Baumstruktur. XML definiert dabei die Regeln für den Aufbau solcher Dokumente. Für einen konkreten Anwendungsfall ("XML-Anwendung") müssen die Details der jeweiligen Dokumente spezifiziert werden. Dies betrifft insbesondere die Festlegung der Strukturelemente und ihre Anordnung innerhalb des Dokumentenbaums. XML ist damit ein Standard zur Definition von beliebigen, in ihrer Grundstruktur jedoch stark verwandten Auszeichnungssprachen. Eine Sprache zur Definition anderer Sprachen nennt man Metasprache. XML ist eine vereinfachte Teilmenge von SGML.

Die Namen der Strukturelemente (XML-Elemente) für eine XML-Anwendung lassen sich frei wählen. Ein XML-Element kann ganz unterschiedliche Daten enthalten und beschreiben, als prominentestes Beispiel Text, aber auch Grafiken oder abstraktes Wissen. Ein Grundgedanke hinter XML ist es, Daten und ihre Repräsentation zu trennen, also beispielsweise Wetterdaten einmal als Tabelle und einmal als Grafik auszugeben, aber für beide Anwendungen die gleiche Datenbasis im XML-Format zu nutzen.

Fachtermini

Wohlgeformtheit: Ein XML-Dokument ist wohlgeformt (well formed), falls es sämtliche Regeln für XML einhält. Beispielsweise muss für jedes öffnende Element (z.B. <item>) ein schließendes Element vorhanden sein (z.B. </item>).

Gültigkeit: Soll XML für den Datenaustausch verwendet werden, ist es von Vorteil, wenn das Format mittels einer Grammatik (z.B. einer Dokumenttypdefinition (DTD) oder eines XML-Schemas) definiert ist. Ein XML-Dokument, welches wohlgeformt ist und ein durch eine Grammatik beschriebenes Format einhält, heißt gültig (valid).

Parser: Programme oder Programmteile, die XML-Daten auslesen, interpretieren und ggf. auf Gültigkeit prüfen, nennt man XML-Parser.

Aufbau eines XML-Dokuments

Beispiel einer XML-Datei 

 <?xml version="1.0" standalone="yes" encoding="UTF-8"?>
 <enzyklopaedie>
      <titel>Wikipedia Städteverzeichnis</titel>
      <eintrag>
           <stichwort>Genf </stichwort>
           <eintragstext>Genf ist der Sitz von...</eintragstext>
      </eintrag>
      <eintrag>
           <stichwort>Köln </stichwort>
           <eintragstext>Köln ist eine Stadt, die ...</eintragstext>
      </eintrag>
 </enzyklopaedie>

XML-Dokumente besitzen einen physischen und einen logischen Aufbau.

Der physische Aufbau eines XML-Dokumentes besteht aus

  • Entitäten. Die erste Entität ist die Hauptdatei des XML-Dokuments. Weitere mögliche Entitäten sind über
    • Entitätenreferenzen (&name; für das Dokument bzw. %name; für die Dokumenttypdefinition) eingebundene Zeichenketten, eventuell auch ganze Dateien, sowie
    • Referenzen auf Zeichenentitäten zur Einbindung einzelner Zeichen, die über ihre Nummer referenziert wurden (&#Dezimalzahl;, oder &#xHexadezimalzahl;).
  • Eine XML-Deklaration wird optional verwendet, um XML-Version, Zeichenkodierung und Verarbeitbarkeit ohne Dokumenttypdefinition zu spezifizieren.
  • Eine Dokumenttypdefinition wird optional verwendet, um Entitäten sowie den erlaubten logischen Aufbau zu spezifizieren.

Der logische Aufbau eines XML-Dokumentes ist ein hierarchisch strukturierter Baum. Als Baumknoten gibt es:

  • Elemente, deren physische Auszeichnung mittels
    • einem passenden Paar aus Start-Tag (<Tag-Name>) und End-Tag (</Tag-Name>) oder
    • einem Empty-Element-Tag (<Tag-Name />) erfolgen kann,
  • Attribute als bei einem Start-Tag oder Empty-Element-Tag geschriebene Schlüsselwort-Werte-Paare (Attribut-Name="Attribut-Wert") für Zusatz-Informationen über Elemente (eine Art Meta-Information),
  • Verarbeitungsanweisungen (<?Ziel-Name Parameter ?>, Engl. Processing Instruction)
  • Kommentare (<!-- Kommentar-Text -->)
  • Text, welcher als normaler Text oder in Form eines CDATA-Abschnittes (<![CDATA[ beliebiger Text ]]>) auftreten kann.

Ein XML-Dokument muss genau ein Element in der obersten Ebene enthalten. Unterhalb von diesem Dokumentelement können weitere Elemente verschachtelt werden.

Zur Spezifikation des logischen Aufbaus werden die Dokumenttypdefinitionen durch das umfangreichere XML-Schema abgelöst, welches keine Möglichkeit zur Definition von Entitäten, jedoch einen adäquaten Ersatz für Entitäten besitzt. Processing Instructions werden in der Praxis meist eingesetzt, um in XML-Dokumenten Verarbeitungsanweisungen in anderen Sprachen einzubauen. Ein Beispiel dafür ist PHP, dessen Verarbeitungsanweisungen in XML-Dokumenten mit einer PHP-Verarbeitungsanweisung, z.B. <?php print "Hello, World";?> eingebaut werden können.

Einige Web-Browser können XML-Dokumente mit Hilfe eines eingebauten XML-Parsers direkt darstellen. Dies geschieht in Verbindung mit einem Stylesheet. Diese Transformation kann die Daten in ein komplett anderes Format umwandeln, das Zielformat muss nicht einmal XML sein.

Vorgänger von XML

Obwohl der Vorgänger SGML bereits weitaus umfangreicher war, kam es nie zu einer breiten Akzeptanz in der Öffentlichkeit. Der Grund dafür liegt in der Komplexität SGMLs, die die Softwareentwicklung stark erschwert. Die Komplexität von SGML und XML kann mit der Pareto-Verteilung beschrieben werden: obwohl XML nur ca. 20% der Komplexität von SGML hat, können damit ca. 80% der Anwendungsfälle abgedeckt werden. Der Bedarf nach einem unbeschränkten weltweiten Informationsaustausch und die Popularität von HTML brachten das deutlich einfachere XML hervor.

Kerntechnologien

Die Kerntechnologien im XML-Umfeld kann man grob aufteilen in: APIs zur Verarbeitung von XML und Sprachen zur Beschreibung von XML-Dateien.

APIs zur Verarbeitung von XML

SAX
SAX (Simple API for XML) ist eine standardisierte Möglichkeit, wie eine XML-Datei durch einen Parser bearbeitet wird. Hierbei wird ein Datei-Strom in einen Strom von Ereignissen umgewandelt. Programme können sich für einzelne Ereignisse registrieren, um bei Bedarf ihre Arbeit zu verrichten. Die Eingabedaten werden rein sequentiell verarbeitet. Ein Vorteil von SAX ist, dass nicht die gesamte XML-Datei im Speicher vorgehalten werden muss. Das ist aber dann ein Nachteil, wenn man viele Informationen, die über die ganze Datei verstreut sind, zur Verarbeitung benötigt.
DOM
DOM (Document Object Model) ist der zweite Weg, um XML-Dateien auszuwerten und wurde vom W3C standardisiert. Er stellt, wie der Name schon sagt, ein standardisiertes Objektmodell zur Verfügung, mit dessen Hilfe der Inhalt der XML-Datei ausgewertet oder manipuliert werden kann. Zum Aufbauen des Objektbaumes muss jedoch zunächst die gesamte Datei eingelesen werden, wofür möglicherweise viel Speicher benötigt wird. Vorteilhaft ist hingegen, dass dann alle Elemente in einer hierarchischen Struktur vorliegen und auf alle gleichermaßen zugegriffen werden kann. Die Elemente stehen zueinander in Beziehung (Eltern, Geschwister, Kinder). Als Nachteil von DOM kann sich ein hoher Speicherbedarf erweisen; er verhält sich proportional zur Größe der Eingabedatei.

Als Beispiel sei eine Webseite erwähnt, die in XML spezifiziert ist. 100 kB sind hier schon eine beachtliche Größe, die Bearbeitung in einem DOM ist deshalb problemlos. Auf der anderen Seite kann ein Wörterbuch (3 MB Grunddaten) gegebenenfalls Probleme verursachen, wobei es weniger der Speicherplatz an sich sein dürfte sondern die Zugriffsgeschwindigkeit. Beide Modelle haben deshalb ihre Berechtigung in der Anwendung.

Metasprachen

Um die Struktur von XML-Dokumenten zu beschreiben, bedient man sich so genannter Schemasprachen. Die zwei bekanntesten sind DTD und XML Schema.
DTD
Eine DTD (Dokumenttypdefinition) ist eine Beschreibung eines XML-Dokuments. Sie wurde zusammen mit XML standardisiert. Mit einer DTD kann allerdings nicht sehr strikt beschrieben werden, wie eine XML-Datei aussehen darf. Ein weiterer Nachteil ist die Tatsache, dass die DTD in einer eigenen Sprache abgefasst werden muss.
XML-Schema (XSD)
XML-Schema ist die moderne Möglichkeit, die Struktur von XML-Dokumenten zu beschreiben. XML-Schema bietet auch die Möglichkeit, den Inhalt von Elementen und Attributen zu beschränken, z. B. auf Zahlen, Datumsangaben oder Texte, z. B. mittels regulärer Ausdrücke. Ein Schema ist selbst ein XML-Dokument, welches erlaubt, komplexere Zusammenhänge als mit einer DTD zu beschreiben.
Weitere Schemasprachen
Weitere Schemasprachen sind RELAX NG, Schematron und Examplotron.

XML-Familie

Infrastruktur

Im Zusammenhang mit XML wurden vom W3-Konsortium auf Basis von XML viele Sprachen definiert, welche XML-Ausdrücke für häufig benötigte allgemeine Funktionen anbieten wie etwa die Verknüpfung von XML-Dokumenten. Zahlreiche XML-Sprachen nutzen diese Grundbausteine.

  • Transformation von XML-Dokumenten: XSLT
  • Adressierung von Teilen eines XML-Baumes: XPath
  • standardisierte Attribute: XML Base und xml:id
  • Verknüpfung von XML-Ressourcen: XPointer, XLink und XInclude
  • Selektion von Daten aus einem XML-Datensatz: XQuery
  • Definition von XML-Datenstrukturen: XML Schema (= XSD, XML Schema Definition Language)
  • Signatur und Verschlüsselung von XML-Knoten: XML Signature und XML-Encryption

Sprachen

Während XML selbst aus SGML hervorgegangen ist, bedienen sich heute sehr viele formale Sprachen der Syntax von XML. So ist XML ein wesentliches Instrument, um – wie es das W3C vorsieht – eine offene, für Mensch und Maschine verständliche Informationslandschaft (semantisches Web) zu schaffen.

Auch die bekannte Dokumentsprache HTML wurde als »Extensible HyperText Markup Language« (XHTML) im Anschluss an die Version 4.01 in dieses Konzept integriert, sodass ihr nun XML als Definitionsbasis zu Grunde liegt. Vielfacher Grund für den Einsatz von XML ist das zahlreiche Vorhandensein von Parsern und die einfache Syntax: die Definition von SGML umfasst 500 Seiten, jene von XML nur 26.

Die folgenden Listen stellen einige dieser XML-Sprachen dar.

Text
Grafik
Geodaten
Multimedia
Sicherheit
Weitere
Darüber hinaus existieren XML-Sprachen für Webservices (z.B. SOAP und WSDL), für mathematische Formeln (MathML), für Verfahren im Bereich des Semantic Web (RDF, OWL, Topic Maps...), für Service Provisioning (SPML), für den Datenaustausch in Bereichen von der Automobilindustrie (ODX) über Landwirtschaft (AgroXML) bis zum Verlagswesen (ONIX) und viele weitere mehr.

Eine Zusammenfassung von XML-Sprachen für Office-Anwendungen findet sich im OpenDocument-Austauschformat (OASIS Open Document Format for Office Applications).

Siehe auch

Programme

  • Editoren
    • Open Source
    • Freeware
      • Peter's XML Editor
      • Crimson Editor mit XML-Syntaxfile
    • Kommerziell
      • xmlBlueprint XML Editor
      • Epic
      • XMetaL
      • XML Spy
      • Stylus Studio
      • XMLmind

  • Office
    • OpenOffice.org, KOffice
    • Microsoft Office (Seit der Version "Office 2003" ist das Editieren von speziellen XML-Dateien möglich, zuvor war nur eine unzulängliche XML-Unterstützung vorhanden
    • AbiWord
    • Adobe FrameMaker (seit V7.2 Unterstützung von DTD, Schema, XSL; komfortables Editieren auch per Drag&Drop in Baumansicht)

  • XML-Schema Dokumentation
    • Open Source
      • xsddoc
      • xs3p
    • Nicht Open Source
      • xnsdoc
      • XSDDoc

XML-Parser

XML-Parser dienen dem Auslesen eines XML-Dokuments nach bestimmten Kriterien. Beim DOM wird das gesamte Dokument in eine Struktur eingelesen, die dann weiterverarbeitet werden kann. XML-Parser sind in verschiedensten Sprachen vorhanden, z.B. Java, C, C++, C#, php, etc.

  • Übersicht von XML-Parsern
    • Xerces
    • Gnome XML-Parser
    • Crimson
    • Expat
    • SimpleXML (php5)

Literatur

  • Elliotte Rusty Harold: Die XML Bibel, mitp 2002, ISBN 3826608216
  • Stefan Mintert (Hrsg.): XML & Co - Die W3C-Spezifikationen für Dokumenten- und Datenarchitektur, Addison-Wesley, München, ISBN 3827318440
  • Erik T. Ray: Einführung in XML, O'Reilly 2004, ISBN 3897212862
  • Helmut Vonhoegen: Einstieg in XML, Galileo Computing 2005, ISBN 3-89842-630-0.
  • Frank Bitzer: XML im Unternehmen, Galileo Computing 2003, ISBN 3-89842-288-7.
  • Gunnar Fuelle, Manuel Montero Pineda, Tobias Ott: Das XML Kompendium, pagina Tübingen 2005, ISBN 3-938529-01-6.

Weblinks

Diskussion der Autoren über den Artikel: Extensible Markup Language

HTML und XML

HTML ist eigentlich kein Vorgänger von XML, da XML keine Weiterentwicklung von HTML ist. XML ist vielmehr ein allgemeiner Ansatz, mit dem sich auch das vorher schon vorhandene HTML ausdrücken läßt. HTML ist also ein Vorgänger von XHTML, was seinerseits eine Anwendung von XML ist.
BernhardWeichel 10:28, 25. Mai 2003 (CEST)

Genauer: HTML ist in SGML definiert, XHTML in XML. XML und SGML sind Sprachen, mit denen sich andere Sprachen (= Dokumententypen) beschreiben lassen. --Zenogantner 13:31, 25. Mai 2003 (CEST)

Und der wesentliche Unterschied zwischen XML und SGML ist, dass SGML jede Menge optionen hat, die bei XML einfach schon festgelegt sind. Und natürlich einige Fatures, die XML nicht mehr hat: And-Connector, Exceptions, CONLINK.
man könnte also sagen, dass bei SGML Lexikalik und Syntax definierbar ist, bei XML nur noch die Syntax.
BernhardWeichel 21:15, 25. Mai 2003 (CEST)

Muss man unbedingt hier Microsoft erwähnen. Die Jungs reden seit Jahren, davon , dass sie XML machen wollen in Office. Bis jetzt kam noch nichts vernünftiges. 2003 wird zwar wohl mehr bringen aber trotzdem sehe ich nicht ein, dass sie gleich wieder als Beispiele für Datenformate positioniert werden. Es gbit ohnehin so viele XML basierte Datenformate, dass man sich wohl schwer tun wird, überhaupt eine Auswahl zu treffen. BernhardWeichel 08:18, 31. Mai 2003 (CEST)

1. Ich denke, dass HTML durchaus ein Vorgänger für XML ist. Ohne den Erfolg von HTML und der Standardisierung durch das W3C wäre es nie möglich gewesen, XML zu erschaffen. Ich sehe es auch so, dass die zwei auf einer anderen Ebene stehen, aber ohne HTML hätte es XML nie gegeben.
2. Meiner Meinung nach sollten wir MS hier drin lassen, was sie mit Infopath im Office hingebracht haben ist erstaunlich. (Vor allem für Microsoft :-)) Man kann aber gerne noch ein paar kritische Worte zur bisher fehlenden Untersützung im Office finden, aber Infopath ist halt nicht "nur" ein Datenformat, das ist sogar recht flexibel. In dem Fall sollte man eher Openoffice entfernen, die haben zwar XML, halten sich aber mit ihrem Format an keine Standards (SVG, XSL,...) Leider...
3. Ich bin kein MS Fan, ich versuche nur die Sache objektiv zu sehen.
OliD 19:42, 13. Jun 2003 (CEST)

OliD:
1. Stimme zu, XML sollte den Datenaustausch von Dokumenten erleichtern. Es sollte dabei v.a. Fehlentwicklungen von HTML vermeiden. Was XML heute ist, ist nicht das XML, was es sein sollte - es ist noch breiter im Einsatz/Ansatz!
2. mir egal
[{Benutzer:Vinci]] 18. Jun 2003

@OliD:
1. Da muss man unterscheiden zwischen Vorgänger und Wegbereiter. HTML war inspiriert von SGML (CharlesGoldfarb im Gespräch mit TimBarnersLee). Es wurde duch nachträgliches hinzufügen einer SGML DTD stabilisiert (??). Nachdem XML von SGML abgeleitet war, wurde auch HTML in XML formuliert. Ein Wegbereiter für XML war HTML allerdings schon: Verbreitung des WWW, "Gewöhnung" an "<" ...
2. Man sollte nicht glauben, dass Infopath eine völlig neue Idee ist. Sie ist vielmehr schon seit längerem bekannt. Allerdings muss man MS zu gute halten, dass sie auf diese Weise wohl die XML-Formulare an die Massen bringen werden. OpenOffice tut nichts anderes als MS. Sie haben ein XML - Format für ihre Textverarbeitung, Spreadsheet usw. definert. Im Unterschied zu MS nutzen sie aber konsequent exisitierende Definitionen wie SVG, MATHML, DC. Import/Export-Filter werden in XSLT gemacht. Aber es ist halt noch immer eine Textverarbeitung.
3. Den versuch machen wir doch alle hier, oder ;-)
@Vinci:
da kann ich dir nur zustimmen. XML ist weit mehr als die Väter je dachten.
BernhardWeichel 12:49, 19. Jun 2003 (CEST)
Ich hab mal versucht das ganze etwas zu strukturieren. Meine Müdigkeit war aber stärker. Sachen die mir noch aufgefallen sind, die ich aber nicht mehr geändert hab: Die Erkärung von wegen XSLT hat nix beim Dateiformat zu tun. Beim Dateiformat wäre es noch nett, wenn man sagen würde, was rein muss und was nicht (mehr) rein soll. Schön wäre auch noch ein Kurzabriss über die Möglichen Einsatzgebiete. OliD 00:22, 11. Dez 2003 (CET)

"Jedoch, sind Programme die auf DOM basieren, im Allgemeinen einfacher zu verstehen." Ist das die Meinung eines Einzelnen oder Tatsache?

das ist imho nicht neutral - hab's gestrichen. -- D 11:52, 3. Sep 2004 (CEST)

Hype um XML

In vielen Meldungen der IT-Industrie und -Presse rund um die Etablierung des XML-Standards wird der Eindruck erweckt, dass auf einen Schlag viele Probleme der Vergangenheit gelöst würden, wenn nur möglichst zügig soviel wie möglich auf XML umgestellt würde.

Tatsächlich ist XML im wesentlichen für Programmierer hilfreich, für den Endkunden sind jedoch im wesentlichen kleine Verbesserungen in bezug auf die Interoperabilität von Anwendungen zu erwarten. Der Umfang der Dokumente nimmt bei Umstellung auf XML jedoch zu und im Verhältnis zu binärer Datenspeicherung ist mehr CPU-Leistung erforderlich, da ein textbasiertes und hochgradig abstrahiertes Format naturgemäss weniger effizient ist als spezialisierte Dateiformate).

Diesen Abschnitt habe ich hierher verschoben. Er stammt aus dem Löschkandidaten XML-Hype; ich habe den Eindruck, der Verfasser hat keinerlei Ahnung, von was er da schreibt, und auch im XML-Artikel ist dieser Abschnitt (erst recht) fehl am Platze.

Vor allem widerspricht der Abschnitt allen mir bekannten XML-Bilanzen z.B. aus c't und iX. Deshalb hier erstmal zur Diskussion gestellt. --Dingo 20:47, 24. Aug 2004 (CEST)

der Hype um XML existiert und hat eine menge schaden angerichtet, weil XML teilweise in unsinnigster weise eingesetzt wird. wo sonst, als im XML-artikel sollte man diese information unterbringen? der abschnitt ist in dieser form definitiv nicht neutral, aber er gehört in den artikel. dein eindruck, daß ich (als mitautor) keine ahnung habe bestreite ich jedenfalls energisch. -- D 17:52, 28. Aug 2004 (CEST)

Dazu muss ich jetzt doch auch mal was sagen.
1. XML ist kein Dateiformat, es ist die gemeinsame Grundlage für Dateiformate. Es ist nur eine Beschreibung, wie einzelne Inhalte strukturiert werden können, legt aber nichts über die Semantik fest. 2. Daraus folgt: XML ist ein wichtiger Schritt für die Interoperabilität von Systemen. Man kann interoperable Systeme auch ohne XML bauen, aber es ist einfacher mit. (Vorteil der Kunden: Sobald eine Schnittstelle offengelegt ist, kann er selbst (XSLT) die Umsetzung der Nachrichten bauen) 3. XML ist mit den meisten binären Formaten nicht zu vergleichen. XML Transportiert Beschreibung & Inhalt, die meisten binären Formate nur Inhalt. Binäre Formate sind für die interoperabilität der Super GAU, da viel mehr spezifiziert werden muss, als bei einem Textbasierten System. Binäre Formate eignen sich nur für den Austausch innerhalb einer Produktpallette. 4. Es ist natürlich wahr, dass XML für die unsinnigsten Dinge eingesetzt wird. Jedoch ist es sehr schwierig zu sagen, welche dies sind. Und der Einsatz von Werkzeugen zu unsinnigen Dingen sagt nichts über das Werkzeug selbst, sondern über den Anwender aus. --OliD 21:19, 29. Aug 2004 (CEST)

noch ein paar kommentare
  • zu 1) richtig - deshalb mein kommentar im text.
  • zu 2) steht das schon im artikel? und: es gibt keine optimierenden XSLT-compiler, daher laaaahm.
  • zu 3) XML überträgt keine beschreibung, die einer maschine irgendetwas nützt. menschen können unter umständen aus den tagnamen raten, was gemeint ist, mehr nicht. erst ein schema bringt einen da weiter.
  • zu 4) natürlich ist nicht das werkzeug schuld, dennoch finde ich es erwähnenswert, daß dieses werkzeug deutlich häufiger mißbraucht wird als andere.
-- D 21:04, 31. Aug 2004 (CEST)
zu 2) Einerseits lassen sich XSLT-Stylesheets mit XSLTC nach Java compilieren und andererseits führen XSLT-Prozessoren wie Saxon tatsächlich Optimierungen durch wie man sie von normalen Compilern her kennt.
Allgemein finde ich, dass es zwar einen Hype um XML gibt, muss in der Praxis jedoch immer wieder feststellen, dass diejenigen, die diesen Hype kritisch betrachten, meist äußerst unsachlich argumentieren und nur Halbwissen in ihre Argumentation einbringen. Ein fachlich korrekter Artikel zu XML-Hype könnte dabei wirklich so interessant und wertvoll sein. --ChristianHujer 10:34, 13. Sep 2004 (CEST)
XSLTC beherrscht gerade mal XSLT 1.0 - das ist imho nicht wirklich brauchbar. saxon scheint da weiter zu sein, da war ich wohl nicht auf dem laufenden. -- D 01:22, 27. Sep 2004 (CEST)
Nochmal zu 3.: Ich meinte mit Beschreibung die Tags. Also dass die Daten unabhängig von ihrer Position und den restlichen Daten lokalisiert werden können. (Dadurch natürlich auch eine gewisse Versionssicherheit) --OliD 16:47, 13. Sep 2004 (CEST)
100% Ack zu Deinen 1. - 4. --ChristianHujer 10:01, 14. Sep 2004 (CEST)

Einleitungssatz: menschenlesbar vs maschinenlesbar

Ich habe zweimal die Änderung eines anons von "menschenlesbar" auf "maschinenlesbar" revertiert und halte jene Änderungen weiterhin für einen Verfälschungsversuch.

Die "Kompromissformel" von Dnaber "maschinen- und menschenlesbarer" erscheint mir nicht den Kern der Sache zu treffen: ZUm einen sind alle, und insbesondere strukturierte, Dateien maschinenlesbar, zum anderen ist Menschenlesbarkeit, eine wichtige Komponente des Erfolgs und ein Grund, dass XML sich weit über den Bereich des Markups ausgedehnt hat, zum Beispiel in Konkurrenz zu ASN.1. --Pjacobi 01:12, 11. Nov 2004 (CET)

Es sind aber nicht alle Dateien maschinenlesbar in dem Sinne wie XML: nämlich so, dass man 1) über ein Standard-API darauf zugreifen kann und 2) der Parse-Prozess zumindest teilweise was über die Semantik versteht (hierarchische Relationen). Das geht bei einem Bild z.B. nicht. Wenn dort nur "menschenlesbar" steht, ist das schon *sehr* irritierend, schließlich ist das nur was für Entwicklung+Debugging, kaum ein normaler Anwender würde XML-Dateien intuitiv als "menschenlesbar" bezeichnen. Dnaber 23:51, 11. Nov 2004 (CET)

Natürlich ist eine Bilddatei maschinenlesbar. Ansonsten könnte der Computer sie doch kaum anzeigen.
Wenn man eine XML Datei doppelklickt wird sie auf vielen Systemen im Browser dargestellt, zur menschlichen Begutachtung. Wenn man eine ASN.1 Datei doppelklickt eher nicht, zum Beispiel weil es gar keine konventionelle Extension gibt und weil (zumindest für PER), ohne Kenntnis des Schemas sowieso nichts vernünftiges anzeigbar ist. --Pjacobi 00:20, 12. Nov 2004 (CET)

Und wo ist das sprachübergreifende API, mit dem ich auf Bilder zugreifen kann? Wo ist die Semantik, wenn der Computer einfach nur ein Pixel nach dem anderen auf dem Bildschirm erscheinen lässt? Was bei einem Doppelklick passiert finde ich nicht relevant, schließlich kann sich jeder seine eigenen Verknüpfungen erstellen und seine eigenen Viewer schreiben. Dnaber 01:15, 12. Nov 2004 (CET)

(Pixel)Bilddateien haben für den Computer nur die Semantik ein 2D Array von Farbwerten zu liefern. Genause wie sich die Semenatik des XML-Dokuments im Allgemeinen Fall dem Computer nicht erschließt. Ein sprachübergreifendes API ist auch kein Bestandteil der XML REC sondern post hoc enstanden. --Pjacobi 10:59, 12. Nov 2004 (CET)

Das sprachübergreifende API ist aber doch ganz entscheidend für den Erfolg von XML, völlig egal, ob es in der XML Rec. drinsteht (der Artikel behandelt "XML", nicht "die XML-Spezifikation"). Ich bleibe dabei: da muss unbedingt auch "maschinenlesbar" stehen, alles andere ist irreführend (selbst "menschenlesbar" halte ich zwar für irritierend formuliert, aber ich weiß ja wie es gemeint ist und stimme auch zu). Vielleicht kann sich ja noch jemand anders äußern, da dies mein letzter Beitrag zu dieser Diskussion ist. Dnaber 13:26, 12. Nov 2004 (CET)

Ich habe ja auch nachdem ich Deine Begründung gelesen habe, dass "maschinenlesbar" nicht wegrevertiert wie ein Irrer, obwohl ich weiterhin das "menschenlesbar" für das kennzeichnende Merkmal halte, insbesondere als Erklärung für den großen Erfolg in "Märkten" die bei objektiver Betrachtung eher zu ASN.1 passen würden. Und als weiteres Beispiel, ist der Unterschied zwischen SVG und Flash, dass ersteres menschenlesbar ist.
Warten wir also an der Stelle mal ab, ob sich noch jemand anderes für die Frage interessiert. --Pjacobi 14:25, 12. Nov 2004 (CET)

Ja, jemand anderes interessiert sich auch für die Frage: Eines der wichtigen Designprinzipien von XML ist die Menschenlesbarkeit. Maschinenlesbarkeit ist bei einer Metasprache für Datenstrukturmodelle (das ist XML) eine absolute Trivialität und sollte nicht extra erwähnt werden. Um des lieben Friedens will kann man die Selbstverständlichkeit aber drin stehen lassen.

Die Diskussion geht mE am Kern vorbei. Am besten ließe man beides ganz raus.
Etwas digital Codiertes, das nicht maschinenlesbar ist, möchte ich mal sehen.
Menschenlesbarkeit ist eine Sache der Interpretation. Als Chinese hätte ich schon Schwierigkeiten mit HTML. Also lesbar für Menschen, die den entsprechenden Zeichensatz beherrschen. Aber damit noch lange nicht richtig interpretierbar. < a > bedeutet ??? Also lesbar und interpretierbar, wenn man weiß, was es heißen soll. Und das gilt für Beliebiges, nur ist es mal leichter und mal schwerer.
Übrig bleibt, dass XML die Möglichkeit bietet hierarchisch aufgebaute Strukturen zu definieren. Ob sich Menschen oder Maschinen damit herumschlagen, ist egal.-- Erlanger 13:18, 31. Mai 2005 (CEST)

Noch ein paar andere Sachen: XML ist nicht eigentlich dafür da, Baumstrukturen herzustellen. XML ist dazu da, dass man komplexe Dokumente (mittels deskriptiven tags) auszeichnen kann. Diese Auszeichnung kann dann (zufällig auch) als Baum dargestellt werden. Der Baum ist EINE Sicht auf ein XML-Dokument.

Ich finde diesen Satz nicht ganz optimal: "Ein XML-Element kann ganz unterschiedliche Daten enthalten bzw. beschreiben, als prominentestes Beispiel Text, aber auch Grafiken oder abstraktes Wissen". Man müsste unterscheiden, auf welcher Ebene man das beschreiben will: inhaltlich oder formal. Ich würde sagen (und das ist jetzt formal, entspricht aber den Formulierungen in den meisten XML-Büchern): "Ein XML-Element kann Textdaten enthalten oder weitere Elemente oder eine Mischung von beidem".

Parser: streng genommen sind Parser Programme, die XML-Dokumente auf Wohlgeformtheit oder Gültigkeit prüfen oder eine Baumsicht der Dokumente erzeugen oder für die weitere Verarbeitung aufbereiten. "Verarbeiten" selbst finde ich ein wenig zu allgemein. Ist die Darstellnug in einem Browser oder Editor nicht schließlich auch eine Form von Verarbeitung?

HTML als Vorgänger von XML. Habe gerade einen 30-Zeilen-Beitrag zu der Frage geschrieben, jetzt aber wieder gelöscht, weil der Artikel-Text hier so geändert worden ist (ich hatte mich noch auf die Diskussion oben bezogen), dass ich eigentlich zufrieden bin.

Ich finde die Bezeichnung "Metasprachen" für DTD und Schema nicht so glücklich! SGML und XML sind Metasprachen. Wie nennen die Handbücher die?

Absatzname "XML-Anwendungen" fraglich

Meines Wissens nach ist eine XML-Anwendung alles das was XML verwendet. Daher ist der Begriff meiner Meinug nach nicht gerechtfertigt. Wie wärs mit "XML-Programme"? --PhilippWeissenbacher 20:17, 20. Apr 2005 (CEST)

Zugematscht

Der Artikel ist zugematscht. Statt überflüssiger Beispiele für XML-basierter Sprachen und Software sollten Beispiel für XML-Daten gebracht werden. Zeichnungen sind auch hilfreich. -- JakobVoss 16:25, 27. Apr 2005 (CEST)

Structured Data Exchange Format

Inwiefern hängt das mit XML zusammmen? Das scheint mir sehr verwandt zu sein. Der Artikel hat eine Unverständlichkeitsbeurteilung. Vielleicht mag sich wer darum kümmern? --Erlanger 13:18, 31. Mai 2005 (CEST)

Einbindung einer Navigationsleiste für XML-Sprachfamilie

Ich kam auf die Idee das so etwas vielleicht ganz sinnvol wäre, würde die Leiste auch schreiben weiß aber nicht ob das nicht unerwünscht wäre. -- Unit66 3. Jul 2005 19:19 (CEST)

Datenbanken-Kontext?

Hallo, in vielen Lehrveranstaltungen zu Datenbanksystemen wird XML als Brücke bzw. Kompromiss zwischen dem streng formalen relationalen Datenmodell und HTML dargestellt. Dieser Kontext und der Begriff der semistrukturierten Daten fehlt hier ein bisschen.

Weblinks

Ich werde am Sonntag so richtig Zeit haben. Darum die provilaktische Bitte vorweg: Kürzt die Linkliste, sonst tu ich es!--Cyper 16:01, 25. Aug 2005 (CEST)

Kritik

Was ich im XML-Artikel vermisse sind die Vor- und Nachteile von XML.


Diese Definition bzw. Erklärung des Begriff Extensible Markup Language und dessen Bedeutung wurde zuletzt am 8.2.2006 aktualisiert (Glossar Lexikon Enzyklopädie).


Wikipedia GNU FDL Artikel anzeigen Artikel bearbeiten