edition W3C.de

Extensible Markup Language (XML) 1.1

Deutsche Übersetzung

Diese Version:
http://www.edition-w3c.de/TR/2002/CR-xml11-20021015
Aktuelle Version:
http://www.edition-w3c.de/TR/xml11/
Übersetzer:
Stefan Mintert, mintert.com <stefan@mintert.com>

Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern . Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.

Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.

Diese Veröffentlichung ist eine Vorveröffentlichung. Kein Teil dieses Textes darf kopiert werden. Alle Rechte vorbehalten. Nach Abschluss der Arbeit wird das endgültige Dokument unter der oben angegebenen Adresse veröffentlicht. Die jetzige Veröffentlichung während der laufenden Arbeit dient zur Information von Interessierten und zur Prüfung durch die Fachöffentlichkeit. Sollten Sie Fehler finden oder Verbesserungsvorschläge haben, schicken Sie diese bitte per Mail an Stefan Mintert.

W3C

Extensible Markup Language (XML) 1.1

W3C Candidate Recommendation, 15. Oktober 2002

Diese Version:
http://www.w3.org/TR/2002/CR-xml11-20021015
Aktuelle Version:
http://www.w3.org/TR/xml11/
Vorherige Version:
http://www.w3.org/TR/2002/WD-xml11-20020425/
Herausgber:
John Cowan, Reuters < jcowan@reutershealth.com >

Copyright © 2002 W3C ® ( MIT , INRIA , Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Zusammenfassung

Dieses Dokument beschreibt XML 1.1, ein Erzeugnis der XML Core Working Group gemäß Definition der XML Blueberry Requirements. XML 1.1 war zuvor unter dem Namen XML-Blueberry bekannt. Dieses Dokument besteht aus einer Reihe von Änderungen der XML-1.0-Empfehlung [XML1.0], und seine nummerierten Abschnitte entsprechen denen der XML-1.0-Empfehlung. Abschnitte jener Empfehlung, die nicht in diesem Dokument erscheinen, bleiben in XML 1.1 unverändert.

Status dieses Dokument

Dieser Abschnitt beschreibt den Status dieses Dokuments zum Zeitpunkt seiner Veröffentlichung. Andere Dokumente können dieses Dokument ablösen. Der aktuelle Stand dieser Dokumentenreihe wird beim W3C verwaltet.

Diese Spezifikation wird als W3C Candidate Recommendation von XML 1.1 veröffentlicht. W3C veröffentlich einen technischen Bericht als Candidate Recommendation , um zu zeigen, dass das Dokument als stabil angesehen wird und um die Entwicklergemeinde zu Implementierungen zu ermutigen. Der Status einer Candidate Recommendation status ist in Abschnitt 5.2.3 des Prozess-Dokuments beschrieben.

Die XML Core Working Group (Teil der XML Activity, siehe Zusammenfassung) erwartet, dass sie den Direktor auffordern wird, diese Spezifikation zu einer Proposed Recommendation auszurufen, nachdem die XML Core Working Group mindestens zwei interoperable Implementierungen nachweisen kann. Die beiden Implementierungen müssen von zwei verschiedenen Organisationen hergestellt worden sein.

Der aktuelle Bericht über Implementierungen enthält Rückmeldungen bezüglich der Implementierung, die wir bis zum jeweiligen Zeitpunkt bekommen haben.

Die Veröffentlichung einer Candidate Recommendation bedeutet keine Zustimmung durch die W3C-Mitgliedschaft. Dies ist ein Arbeitsdokument und kann zu jedem Zeitpunkt durch andere Dokumente aktualisiert, ersetzt oder überholt werden. Es ist nicht korrekt, dieses Dokument anders zu referenzieren als in Arbeit befindlich.

Während diese und folgende Entwürfe dieser Spezifikation als Folge von Änderungen der XML 1.0 Recommendation geschrieben werden, um Edierung und Begutachtung zu erlauben, ist es wahrscheinlich, dass die endgültige XML-1.1-Empfehlung die Form einer integrierten Revision der XML-1.0-Spezifikation annehmen wird.

Documentation of intellectual property possibly relevant to this recommendation may be found at the Working Group's public IPR disclosure page.

We explicitly invite comments on this draft. The Candidate Recommendation review period ends at 2359 UTC on 14 February 2003.  Comments should be sent to www-xml-blueberry-comments@w3.org . This is the preferred method of providing feedback. Public comments and their responses can be accessed at http://lists.w3.org/Archives/Public/www-xml-blueberry-comments/.

Publication of this document does not imply endorsement by the W3C membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite a W3C Candidate Recommendation as anything other than a "work in progress."A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Table of Contents

Einführung

Die XML-1.0-Empfehlung des W3C, zuerst ausgegeben im Jahre 1998, blieb trotz der zahlreichen Errata, die zu einer zweiten Auflage im Jahre 2000 führten, in Bezug auf die Frage, was ist wohlgeformtes XML und was nicht, (bewusst) unverändert. Die Stabilität war für die Interoperatibilität besonders wertvoll. Dennoch, der Unicode-Standard, auf die Zeichenspezifikationen von XML 1.0 basieren, blieb nicht unverändert, sondern entwickelte sich von Version 2.0 zu Version 3.1 und darüber hinaus. Zeichen, die in Unicode 2.0 nicht vorhanden sind, dürfen bereits in Zeichendaten in XML 1.0 verwendet werden. Sie sind jedoch nicht in XML-Namen, wie Elementtypnamen, Attributnamen, Aufzählungswerten von Attributen, Zielnamen von Verabeitungsanweisungen usw. erlaubt. Darüber hinaus sind einige Zeichen, die in XML-Namen zugelassen sein sollten, aufgrund von Versehen und Inkonsistenzen in Unicode 2.0 nicht zugelassen.

Die gesamte Philosophie von Namen hat sich seit XML 1.0 verändert. Während XML 1.0 eine strenge Definition von Namen vorgeschrieben hat, worin alles, was nicht erlaubt war, verboten war, sind XML-1.1-Namen so entworfen, dass alles, was nicht (aus bestimmten Gründen) verboten ist, erlaubt ist. Da sich Unicode über Version 3.1 hinaus entwickeln wird, können zukünftige Änderungen an XML vermieden werden, indem fast alle Zeichen in Namen erlaubt werden, einschließlich jener, die noch nicht zugewiesen sind.

Des weiteren versucht XML 1.0 die Zeilenende-Konventionen der verschiedenen modernen Computer-Systeme zu berücksichtigen, diskriminiert aber die Konventionen, die auf IBM- und IBM-kompatiblen Mainframes verwendet werden. In Folge dessen sind XML-Dokumente auf Mainframes keine reinen Textdateien gemäß den lokalen Konventionen. XML-1.0-Dokumente, die auf Mainframes erzeugt wurden, müssen entweder die lokalen Zeilenende-Konventionen verletzen, oder sie erfordern unnötige Übersetzungsphasen vor dem Parsing und nach der Erzeugung. Eine unmittelbare Interoperabilität ist besonders wichtig, wenn gespeicherte Daten zwischen Mainframe und Nicht-Mainframe-Systemen gemeinsam benutzt werden (im Gegensatz zum Kopieren von einem zum anderen). Daher ergänzt XML 1.1 NEL (#x85) zur Liste der Zeilenende-Zeichen. Der Vollständigkeit halber wird auch das Unicode-Zeilentrennzeichen #x2028 unterstützt.

Schließlich besteht hinreichend viel Bedarf für eine standardisierte Darstellung beliebiger Unicode-Zeichen in XML-Dokumenten. Deshalb erlaubt XML 1.1 die Verwendung von Zeichenreferenzen für die Steuerzeichen #x1 bis #x1F, von denen die meisten in XML 1.0 verboten sind. Aus Gründen der Robustheit können diese Zeichen jedoch immer noch nicht direkt in Dokumenten verwendet werden. Um die Zuverlässigkeit der Erkennung von Zeichenkodierungen zu verbessern, dürfen die zusätzlichen Steuerzeichen #x7F bis #x9F, die in XML-1.0-Dokumenten beliebig erlaubt waren, nun auch ausschließlich als Zeichenreferenzen auftreten. (Eine Ausnahme sind selbstverständlich Leerraumzeichen.) Die kleine Verletzung der Abwärtskompatibilität wird als nicht bedeutend erachtet. Wegen potentieller Probleme mit APIs ist #x0 weiterhin verboten, sowohl direkt als auch als Zeichenreferenz.

Da die Änderungen die Definition von wohlgeformten Dokumenten berühren, wird eine neue XML-Version erstellt, anstelle einer Sammlung von Errata für XML 1.0. XML-1.0-Prozessoren müssen weiterhin Dokumente zurückweisen, die neue Zeichen in XML-Namen, neue Zeilenende-Konventionen und Referenzen auf Steuerzeichen enthalten. Die Unterscheidung zwischen XML-1.0- XML-1.1-Dokumenten erfolgt durch die Angabe der Versionsnummer in der XML-Deklaration zu Beginn jedes Dokuments.

2.2 Zeichen

Ändere Produktionsregel [2]:

 [2]     Char    ::=    #x9 | #xA | #xD | [#x20-#x7E] | #x85 | [#xA0-#xD7FF]
                      | [#xE000-#xFFFD] | [#x10000-#x10FFFF]

Ändere den entsprechenden Kommentar zu:

jedes Unicode-Zeichen mit Ausnahme der meisten ISO controls, die Ersatzblöcke, FFFE und FFFF

2.3 Allgemeine syntaktische Konstrukte

Ändere Produktionsregel [4] und ergänze neue Produktionsregel [4a]:

 [4]     NameStartChar := ":" | [A-Z] | "_" | [a-z] |
         [#xC0-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] |
         [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] |
         [#x3001-#xD7FF] | [#xF900-#xEFFFF]
 [4a]    NameChar := NameStartChar | "-" | "." | [0-9] | #xB7 |
         [#x0300-#x036F] | [#x203F-#x2040]

Ändere Produktionsregel [5] zu:

 [5]     Name    ::=   NameStartChar NameChar*

Füge die folgenden drei Absätze nach Produktionsregel 5 ein:

Das erste Zeichen eines Name muss ein NameStartChar, jedes andere Zeichen muss ein NameChars sein. Dieser Mechanismus verhindert, dass Namen mit einer lateinischen (ASCII) Ziffer oder mit einem Basic Combining Character beginnen. Fast alle Zeichen sind in Namen erlaubt, mit Ausnahme derer, die entweder als Begrenzungszeichen verwendet werden oder sinnvollerweise verwendet werden könnten. Die Absicht ist es, einschließend statt ausschließend zu sein, so dass Schriftsysteme, die noch nicht in Unicode kodiert sind, in XML-Namen verwendet werden können. Siehe Anhang B für Empfehlung zum Aufbau von Namen.

Dokumentautoren werden ermutigt, Namen zu verwenden, die bedeutungsvolle Worte oder Kombinationen von Worten in natürlichen Sprachen darstellen, und Symbole oder Leeraumzeichen in Namen zu vermeiden. Beachten Sie, dass Doppelpunkt (COLON), Minuszeichen (HYPHEN-MINUS), Punkt (FULL STOP), Unterstrich (LOW LINE) und mittelhoher Punkt (MIDDLE DOT) ausdrücklich erlaubt sind.

Die ASCII-Symbole und Interpunktionszeichen sind gemeinsam mit einer ziemlich großen Menge von Unicode-Symbolzeichen von XML-Namen ausgeschlossen, das sie nützlicher als Begrenzer in Kontexten sind, in denen XML-Namen außerhalb von XML-Dokumenten benutzt werden; vorausgesetzt jene Menge gibt diesen Kontexten verlässliche Garantien darüber, was nicht Teil eines XML-Namens sein kann. Das zeichen #x037E (Griechisches Fragezeichen, GREEK QUESTION MARK) ist ausgenommen, weil es bei Normalisierung zu einem Semikolon wird, was die Bedeutung von Entity-Referenzen verändern kann.

Ändere Produktionsregel [7] zu:

 [7]     Nmtoken    ::=   NameChar+

2.8 Prolog und Dokumenttyp-Deklaration

Ändere überall "1.0" zu "1.1"

Ergänze folgenden Absatz:

XML-1.1-Prozessoren sollten auch XML-1.0-Dokumente akzeptieren. Wenn ein Dokument wohlgeformtes oder gültiges XML 1.0 ist und vorausgesetzt es enthält keine anderen Zeichen des Bereichs [#x7F-#x9F] als Zeichen-Escape-Sequenzen, darf es durch einfache Änderung der Versionsnummer zu wohlgeformtem, respektive gültigem XML 1.1 gemacht werden.

2.11 Behandlung des Zeilenendes

Ersetze den zweiten Absatz mit:

Um die Aufgabe von Anwendungen zu vereinfachen, müssen die Zeichen, die von einem XML-Prozessor an eine Anwendung weitergegeben werden, so sein als ob der XML-Prozessor alle Zeilenumbrüche in externen analysierten (parsed) Entities (inklusive des Dokumenten-Entity) beim Einlesen und vor dem Parsing dadurch normalisiert hätte, dass er jedes der folgenden zeichen in ein einfach #xA-Zeichen gewandelt hätte:

2.13 Test auf Normalisierung [Neu]

Alle analysierten XML-Entities (inklusive des Dokument-Entity) sollten gemäß Definition in [Charmod] volständig normalisiert sein, ergänzt um die folgenden Definitionen relevanter Konstrukte für XML:

Ein Dokument ist jedoch auch dann noch wohlgeformt, wenn es nicht vollständig normalisiert ist. XML-Prozessoren sollten eine Benutzeroption anbieten, die die Überprüfung, ob ein zu verarbeitendes Dokument in vollständig normalisierter Form vorliegt, und sie sollten die Anwendung darüber informieren, ob das so ist oder nicht. Die Option, die Überprüfung nicht durchzuführen, sollte nur dann gewählt werden, wenn der Eingabetext gemäß Definition in [Charmod] geprüft ist (certified).

Der Test auf vollständige Normalisierung muss so ausgeführt werden, als ob zuerst getestet wird, dass das Entity in include-normalisierter Form gemäß Definition in [Charmod] vorliegt; anschließend muss getestet werden, dass keines der oben genannten relevanten Konstrukte (nach der Auflösung von Zeichenreferenzen) mit einem Composing-Zeichen gemäß Definition in [Charmod] beginnt. Nicht-validierende Prozessoren müssen mögliche Abweichungen von der Normalisierung ignorieren, falls sie durch Einlesen von externen Entities, die sie nicht lesen, entstehen würden.

Hinweis: Die Composing-Zeichen umfassen alle Unicode-Zeichen der non-zero combining class, plus eine kleine Zahl von class-zero-Zeichen, die nichtsdestotrotz als Nicht-Anfangszeichen in bestimmten Unicode canonical decompositions auftreten.  Da diese Zeichen den base characters folgen sollten, setzt die Einschränkung, dass relevante Konstrukte (einschließlich Inhalt) nicht mit einem composing character anfangen dürfen, die Ausdrucksfähigkeit von XML nicht wesentlich herab.

Falls ein Prozessor während des Tests auf vollständige Normalisierung ein Zeichen vorfindet, für das er die Normalisierungseigenschaften nicht bestimmen kann (z.B. Zeichen, die von einer Version von [Unicode] eingeführt wurden, die jünger ist als die, die zur Implementierung des Prozessors herangezogen wurde), dann kann der Prozessor benutzeroptional all potentiellen Denormalisierungen, die durch diese Zeichen hervorgerufen werden, ignorieren. Die Option, solche Denormalisierungen zu ignorieren, sollte von Anwendungen nicht ausgeübt werden, wenn Verlässlichkeit oder Sicherheit ein kritischer Faktor sind.

XML-Prozessoren dürfen keine Umwandlung durchführen, um die Eingabe in vollständig normalisierte Form zu überführen. XML-Anwendungen, die XML-1.1-Ausgaben entweder aus XML-1.1- oder XML-1.0-Eingaben erzeugen, sollten sicherstellen, dass die Ausgabe vollständig normalisiert ist. Es ist für interne Verarbeitungszwecke nicht notwendig, vollständig normalisiert zu arbeiten.

Der Zweck dieses Abschnitts es es, XML-Prozessoren nachdrücklich aufzufordern, sicherzustellen, dass die Erzeuger XML-Dokumente ordentlich normalisiert haben, damit XML-Anwendungen Tests wie den Gleicheitstest von Zeichenketten durchführen können, ohne sich über die verschiedenen möglichen Schreibweisen von Zeichenketten, die Unicode erlaubt, Gedanken machen zu müssen.

4.1 Zeichen- und Entity-Referenzen

Ändere die Wohlgeformtheitsbeschränkung: Erlaubtes Zeichen in:

Zeichen, auf die mittels einer Zeichenreferenz verwiesen wird, müssen entweder zu der Produktion für Char passen, oder müssen eines der ISO-Steuerzeichen im Bereich [#x1-#x1F] oder [#x7F-#x9F] sein.

4.3.4 Versionsinformation in Entities [NEW]

Jedes Entity, einschließlich des Dokument-Entity, kann unabhängig als XML 1.0 oder XML 1.1 deklariert werden. Die Versionsdeklarierung im Dokument-Entity bestimmt die Version des gesamten Dokuments. Ein XML-1.1-Dokument darf externe XML-1.0-Entities aufrufen, so dass ansonsten doppelte Versionen von externen Entities, insbesondere DTD-Teilmengen, nicht gepflegt werden müssen. In so einem Fall werden die Regeln von XML 1.1 auf das gesamte Dokument angewendet.

Wenn ein Entity (einschließlich des Dokument-Entity) nicht mit einer Versionsnummer versehen ist, wird es behandelt, als wäre es mit der Versionsnummer 1.0 versehen.

Anhang A: Referenzen

Ergänze die folgenden normativen Referenzen:

[XML1.0]
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler (editors): Extensible Markup Language (XML) 1.0 (Second Edition), 6 October 2000.  (Siehe http://www.edition-w3c.de/TR/REC-xml .)
[Charmod]
Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Asmus Freytag, Tex Texin: Character Model for the World Wide Web, W3C Working Draft, 30 April 2002.   (Siehe http://www.edition-w3c.de/TR/charmod/.)

Anhang B: Empfehlungen für XML-Namen (Nicht Normative)

Anhang B wird von einem normativen Anhang mit dem Titel Zeichenklassen

zu einem nicht normativen Anhang namens Empfehlungen für XML-Namen mit dem folgenden Inhalt geändert:

Die folgenden Empfehlungen definieren das, was sich als beste Praxis beim Bilden von XML-Namen für Elementnamen, Attributnamen, Zielen von Verarbeitungsanweisungen, Entity-Namen, Namen für Notationen und die Werte von Attribute vom Typ ID. Sie sind als Richtlinie für Dokumentautoren und Schema-Designer gedacht. Alle Bezüge auf Unicode verstehen sich als Verweis auf eine bestimmte Version des Unicode Standard größer oder gleich 3.0. Es liegt im Ermessen des Dokumentautors oder Schema-Designers, welche Version benutzt werden sollte.

Die beiden ersten Empfehlungen leiten sich direkt aus den Regeln für Bezeichner im Unicode Standard, Version 3.0, ab, und schließen alle Steuerzeichen einschließlich nonspacing marks, nicht dezimale Zahlen, private-use characters, Interpunktionszeichen (mit den genannten Ausnahmen), Symbolzeichen, unassigned codepoints und Leerraumzeichen. Die anderen Empfehlungen sind überwiegend aus XML 1.0, Anhang B abgeleitet.