Namenräume und Validierung: Nachtrag

[fjh]

Hallo zusammen,

eigentlich gehört das Folgende hier zu einem Thread, der nun entweder im Archiv gelandet oder im Nirvana verschwunden ist.

Dabei ging es um die Probleme, die das Konzept der XML-Namensräume und das Konzept der Validierbarkeit von XML-Dokumenten mit sich bringen. Es gab ein wenig Konfusion, was die Möglichkeit angeht, Elementtypen mit Namensraum-Präfix (html:h1) in einer DTD deklarieren zu können. Dass es geht, ist klar, aber irgendwie haben mir die Details dann keine Ruhe mehr gelassen, zumal am nächsten Tag ein Kollege ein ähnliches Problem hatte. Ich habe nochmal rumprobiert, nachgelesen und gebe es "kurz" zum Besten, falls es mal jemand gebrauchen kann (ich vote dann auch für mich selbst, damit's ins Archiv wandert ;-):

XML-Namensräume dienen dazu, Namenskonflikte und Mehrdeutigkeiten in XML-Dokumenten zu vermeiden, die Elemente aus zwei (oder mehr) DTDs enthalten. Will ich zum Beispiel einem XML-Dokument mit der Adresse einer Geschäftsstelle, die Rechner der Geschäftsstelle hinzufügen, kann es zu einem Namenskonflikt bezüglich der Verwendung des Elements <adresse> kommen (Rechneradresse!). Um diesen zu vermeiden, deklariere ich zwei unterschiedliche Namensräume für die Elemente aus den verschiedenen DTDs:

<geschäftsstelle
       xmlns:adr="http://www.myServer.de/adresse"
       xmlns:rech="http://www.myServer.de/rechner">
  <name>Superladen 22</name>
  adr:adresse
    adr:strasseWiener Str. 23</adr:strasse>
    adr:ortBerlin</adr:ort>
    adr:landGermany</adr:land>
  </adr:adresse>
  edv:rechner
    edv:typFileserver</edv:typ>
    edv:bezLena 2</edv:bez>
    edv:adresse123.54.51.8</edv:adresse>
  </edv:rechner>
</geschäftsstelle>

Soweit so gut, aber wie sieht es nun mit der Gültigkeit dieses Dokuments aus. Nehmen wir an, ich hatte vorher ein gültiges Dokument ohne das <rechner>-Element und ohne Namensraum-Präfixe. Ich füge nun die Namenraum-Deklarationen hinzu.

Zunächst einmal verweisen die beiden Namensraum-Deklarationen nicht auf dahinterliegende Schemata oder DTDs. Sie dienen lediglich als eindeutige Identifizierungs-IDs. Ich könnte nun versuchen meine rechner-DTD über eine zweite Dokumenttyp-Deklaration (<!DOCTYPE ...>) einzubinden. Aber dies ist in XML nicht zulässig. Möglich wäre (wie der untere Thread gezeigt hat) aber eine Einbindung der zweiten DTD über ein externes Parameter-Entity innerhalb meiner ersten DTD.

Aber auch dies reicht nicht, selbst wenn alle hinzukommenden Elementtypen deklariert sind. Grund: Elemente tragen ja nun Namensraum-Präfixe und müssen deswegen auch MIT diesen deklariert werden.

Also:

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ELEMENT foo (#PCDATA)>
]>
adr:foo
  Geschreibsel
</adr:foo>

ist kein gültiges Dokument.

Deklariere ich nun den Elementtyp mit Namensraumpräfix:

<?xml version="1.0"?>
<!DOCTYPE adr:foo [
  <!ELEMENT adr:foo (#PCDATA)>
]>
adr:foo
  Geschreibsel
</adr:foo>

habe ich zwar ein gültiges Dokument, aber der Namensraum ist nicht deklariert (Gültigkeit hat nichts zu tun mit korrektem Gebrauch von Namensräumen!). OK, füge ich eine Namensraum-Deklaration hinzu:

<?xml version="1.0"?>
<!DOCTYPE adr:foo [
  <!ELEMENT adr:foo (#PCDATA)>
]>
<adr:foo xmlns:adr="http://www.myServer.de/adresse">
  Geschreibsel
</adr:foo>

Tja, nun ist aber mein Dokument nicht mehr gültig, weil das Attribut xmlns:adr nicht deklariert ist. (Wobei dies Parser-abhängig ist: Der msxml3-Parser im IE beschwert sich korrekterweise über die fehlende Attributlisten-Deklaration, während Xerces 1.4 nichts auszusetzen hat). Also muss die ganze Geschichte so aussehen:

<?xml version="1.0"?>
<!DOCTYPE adr:foo [
  <!ELEMENT adr:foo (#PCDATA)>
    <!ATTLIST adr:foo
          xmlns:adr CDATA #FIXED "http://www.myServer.de/adresse">
]>
adr:fooGeschreibsel</adr:foo>

Die Deklaration des Attributs als FIXED funktioniert nicht in allen Parsern (hier ist es z.B. umgekehrt: der IE meckert trotz allem [fälschlicherweise], dass der Namensraum adr nicht deklariert sei, mit Xerces 1.4 funktioniert es aber tadellos). Wer auf Nummer sicher gehen will, muss deswegen wohl immer den Namensraum auch noch im Wurzelelement deklarieren.

Die Übertragung auf das Rechner-Adressen-Beispiel ist klar...

Zu beachten ist dabei, dass die Namensräume nicht in der DTD anwendbar sind. D.h.für den Parser sind die Namensraum-Präfixe in der DTD nicht Stellvertreter des Namensraum-URI, sondern lediglich ein Teil des Element- oder Attributnamen. Mit anderen Worten: eine DTD, in der Elemente aus zwei Namensräumen Verwendung finden, weiss nix davon, dass sie es hier mit zwei Namensräumen zu tun hat. (Thomas: Vielleicht meintest du das ?) Folgendes Dokument ist also gültig:

<?xml version="1.0"?>
<!DOCTYPE adr:foo [
  <!ELEMENT adr:foo (edv:foo)>
    <!ATTLIST adr:foo
              xmlns:adr CDATA #FIXED "http://www.myServer.de/">
  <!ELEMENT edv:foo (#PCDATA)>
    <!ATTLIST edv:foo
              xmlns:edv CDATA #FIXED "http://www.myServer.de/">
]>
adr:foo
  edv:fooGeschreibsel</edv:foo>
</adr:foo>

Würden innerhalb einer DTD die Attributlisten-Deklarationen als Namensraum-Deklarationen aufgefasst und dann die qualifizierten Namen der Elementtypen beim Parsen aufgelöst zu expandierten Namen ("http://www.myServer.de:foo"), dann wären beide gleich und das Dokument ungültig, da laut http://www.w3.org/TR/REC-xml#elemdecls ein Elementtyp nicht mehr als einmal deklariert werden darf. Dem ist aber nicht so.

Gruß
Franz

[Thomas J.S.]

Hallo Franz!

eigentlich gehört das Folgende hier zu einem Thread, der nun entweder im Archiv gelandet oder im Nirvana verschwunden ist.

Ich habe nochmal rumprobiert, nachgelesen und gebe es "kurz" zum Besten, falls es mal jemand gebrauchen kann (ich vote dann auch für mich selbst, damit's ins Archiv wandert ;-):

Danke!!!

Ich vote auch jetzt (einige male *fg*) damit dein Beitrag erhalten bleibt; denn so kann man sich einige zukünftige Erklärungen sparen, nach dem du jetzt die Sachlage so gut erklärt hat.

Warum gibt es nicht mehr von "dir" hier im Forum?

Grüße
Thomas

[Oli]

Hallo Franz!
Auch von meiner Seite nochmals vielen Dank für Deine ausführlichen Worte. Nun hab es sogar ich verstanden :-)
Eine gute Nacht wünscht Dir
Oli

[Bernhard Peissl]

Grüssi,

Ich habe noch ein eher konzeptionelles Problem mit Namespaces! Wofüt braucht man diese denn nun?

XML-Namensräume dienen dazu, Namenskonflikte und Mehrdeutigkeiten in XML-Dokumenten zu vermeiden, die Elemente aus zwei (oder mehr) DTDs enthalten.

Ist das nicht eher ein "Seiteneffekt". Ich dachte immer es gehe mehr darum, die logische Zugehörigkeit eines Elements zu einem Schema auszudrücken. Wenn etwa zwei Geschäftspartner sich in XML unterhalten, dass zu jeder Zeit klar ist, was ein Element "bedeutet". In welchem "Kontext" es gesehen werden muss? Da es entweder in seinem eigenen, dem Schema des Partners, z.b.: vf, oder einem Allgemeingültigen Dritt-Schema (z.b. 'erf') definiert ist.

<erf:rechnung
          xmlns:erf="http://domain/EinheitlichesRechnungsFormat">

<erf:verkaeufer id="erf:019R74SF43HG">
  erf:firmaName der Firma</erf:firma>
  erf:adresseNirgendwo 1erf:adresse
  erf:kontaktPerson@firma</kontakt>
 </erf:verkaeufer>

<erf:kaeufer erf:id="947S75ER34">
  erf:firmaName der Firma</erf:firma>
  erf:adresseRoad to Hellerf:adresse
  erf:kontaktPerson@firma</kontakt>
 </erf:kaeufer>

erf:bestellung
  <vf:artikel erf:menge="1"
          xmlns:fi="http://domain/VerkaeuferFirma">
   vf:artnr12345</vf:artnr>
   <vf:preis erf:steuer="inklusive" erf:waehrung="EUR">12</vf:preis>
   vf:nameArtikelbezeichnung</vf:name>
   vf:beschreibung...</vf:beschreibung>
  </vf:artikel>
  vf:artikel [...] </vf:artikel>
  <erf:bestellsumme erf:steuer="inklusive" erf:waehrung="EUR">
   123
  </erf:bestellsumme>
 </erf:bestellung>

</erf:rechnung>

Beispielsweise! Der Sinn hinter den Namespaces stellt sich mir hier nicht so sehr, dass keine Namen doppelt vorkommen, sondern eher dass der Parser die Elemente, Attribute, und deren Werte auf ihre Richtigkeit prüfen kann. Da stellt sich mir eigentlich nur die Frage: Holen sich die Parser ein (mit xmlns) eingebundenes Schema von der angegebenen URL? Validieren sie es? Laut deinem Posting tun sie das, wenn ich richtig gelesen habe.

lg bernhard

[fjh]

Hallo Bernhard,

Ich habe noch ein eher konzeptionelles Problem mit Namespaces! Wofüt braucht man diese denn nun?

XML-Namensräume dienen dazu, Namenskonflikte und Mehrdeutigkeiten in XML-Dokumenten zu vermeiden, die Elemente aus zwei (oder mehr) DTDs enthalten.

Doch genau dazu, viel mehr steckt da nicht dahinter! Es ist ein notwendiges Konzept, geht aber vielen nicht weit genug und es hat deswegen auch eine Menge Kritik gegeben. Aber Namespaces werden nun allseitig unterstützt und sind fester Bestandteil von DOM2 und SAX2. Sie sind z.B. unerläßlich geworden durch die Mischung von verschiedenen XML-Sprachen wie XML, XSLT, XML-Schema und auch zunehmend und v.a. Dingen im Datenaustausch-Bereich.
Wenn man z.B. sicher sein könnte, dass Elementnamen wie <sort>, <if> usw. in keinem XML-Dokument der Welt vorkommen könnten, wäre es unnötig in einem XSLT-Stylesheet jedesmal xsl:sort zu schreiben, damit der XSLT-Prozessor erkennt, dass er dies als Anweisung zu verstehen hat, und nicht das Element 1:1 in den Ergebnisbaum schreiben soll.

Ist das nicht eher ein "Seiteneffekt".

Nein, es ist vielmehr die einzige Funktion von Namensräumen. Anders formuliert: kannst du sicher sein, keine Namenskonflikte zu erwarten, dann brauchst du streng genommen auch keine Namensräume. OK, mag ja sein, dass du aus irgendeinem Grund deine Elemente und Atribute trotzdem in einer Form markieren willst, die sie voneinander abgrenzen. Aber dann grenzt du zwei Namensräume ab, die in keinerlei Verbindung zu einer DTD stehen.

Ich dachte immer es gehe mehr darum, die logische Zugehörigkeit eines Elements zu einem Schema auszudrücken.

Eben nicht. Es wird die Zugehörigkeit zu einem NAMENSRAUM ausgedrückt.

Wenn etwa zwei Geschäftspartner sich in XML unterhalten, dass zu jeder Zeit klar ist, was ein Element "bedeutet". In welchem "Kontext" es gesehen werden muss? Da es entweder in seinem eigenen, dem Schema des Partners, z.b.: vf, oder einem Allgemeingültigen Dritt-Schema (z.b. 'erf') definiert ist.

Hm, Semantik, Bedeutung, schwer zu sagen. Wirkliche Bedeutung verstehen Anwendungen auch mit XML nicht. Sie verstehen nur das, was auch in der Anwendung "reincodiert" ist, meist also eine Zuordnung von Element- oder Attributnamen zu "Aktionen". Erst wenn die Tagnamen gleich sind kommt es zu Missverständnissen. Und da helfen eben XML-Namensräume.
Ich denke ein Großteil der Verwirrung im Feld Namensräume resultiert aus der Tatsache, dass man immer irgendwie mehr dahinter vermutet. Faktum ist, dass mittels einer Namensraum-Deklaration lediglich ein eindeutiger Bezeichner für Elemente und Attribute festgelegt wird (nicht für Entities und Verarbeitungsanweisungen). Damit hat man die Möglichkeit eine Kollektion von Elementen und Attributen einem Namensraum (nicht einem Schema!) zuzuordnen. Das Validierungskonzept (und damit auch die DTDs) von XML bleiben davon unberührt. Daher muss man ja oben Beschriebenes beachten.

Beispielsweise! Der Sinn hinter den Namespaces stellt sich mir hier nicht so sehr, dass keine Namen doppelt vorkommen, sondern eher dass der Parser die Elemente, Attribute, und deren Werte auf ihre Richtigkeit prüfen kann. Da stellt sich mir eigentlich nur die Frage: Holen sich die Parser ein (mit xmlns) eingebundenes Schema von der angegebenen URL? Validieren sie es? Laut deinem Posting tun sie das, wenn ich richtig gelesen habe.

Nein, auch wenn sich das mancher wünschen mag! Die URL als Form eines URI ist lediglich ein eindeutiger Bezeichner. Bei XML-Schema kannst du jedoch mehrere Ziel-Namensräume angeben und da wird dann im Grunde das Namensraumkonzept stillschweigend (aber mit gutem Grund) umgangen. Aber das ist eben XML-Schema, nicht XML + DTD (also "plain" XML).
In diesem Zusammenhang interessant: http://www.openhealth.org/RDDL/

Gruß
Franz

[Bernhard Peissl]

Hallo Franz,

Wenn ich das also jetzt richtig interpretiert habe, sind Namespaces eigentlich nicht viel mehr als ein Aufkleber am Element, der sagt "Dieses Element gehört bitte schön mir. mfG [URI]" Mehr macht er nicht. Es ist also kein Schema/DTD damit verbunden. foo:bar sagt dem Parser genausoviel/wenig wie <bingo>. Sich das schema (über die Namespace-URI) zu besorgen ist Aufgabe der Applikation oder wie? Für mich stellt das aber irgendwie eine Lücke im System dar. Einerseits braucht man das Schema/DTD des referenzierten Namespace-URI, um ein valides xml-Dokument zu erzeugen, andererseits wird aber kein Mechanismus angeboten, der das erledigt.

Man kann ja nicht einfach hergehen, und z.b. dem Element foo:bar das Attribut "typ" zuordnen, obwohl <bar> in der (Original-)DTD ein "type"-Attribut verlangt; dass man also die DTD selber reinschreibt, und in diesem Zuge Änderungen vornehmen kann, obwohl der Namespace auf eine eindeutige URI zeigt, was ja wohl heisst, dass bitte sehr dieses eine Schema zu verwenden ist, und nicht ob der Blindheit des Parsers einfach die Dokumentstrukur geändert werden kann. Was gerade beim elektronischen Datenaustausch wichtig ist. Es muss ja auf beiden Seiten dem selben Schema Genüge getan werden. Wenn eine Seite die xml-Datei anders interpretiert als die andere, gibts bekanntlich Stunk! Daher mein Beispiel aus der Wirtschaft, und nicht aus dem Web-publishing, wo dieses Problem vielleicht weniger wichtig scheint.

Hm, Semantik, Bedeutung, schwer zu sagen. Wirkliche Bedeutung verstehen Anwendungen auch mit XML nicht. Sie verstehen nur das, was auch in der Anwendung "reincodiert" ist, meist also eine Zuordnung von Element- oder Attributnamen zu "Aktionen". Erst wenn die Tagnamen gleich sind kommt es zu Missverständnissen. Und da helfen eben XML-Namensräume.

Semantik im Sinne "Diese Nummer ist als Bestellnummer der Rechnung zu verstehen", eine andere <nr> könnte allerdings "Telefonnummer der Kontaktperson" sein. Zwei Grundverschiedene Semantiken, beide - im worst case - mit <nr> bezeichnet, kann man nun mit Namespaces trennen in z.b.: bestell:nr und kontakt:nr. Schön und auch gut, aber die Elemente können aber nun gänzlich verschieden aufgebaut sein. Für die Bestellnr muss beispielsweise eine 5-stellige interger-Zahl drinstehen, die kontakt:nr ist alerdings ein String, kann beliebig oft vorkommen als Kind eines kontakt:telefon. Da kann uns nur die Zuordnung eines Schemas zum Namespace vor dem nahenden Unglück retten ;-) Und genau da liegt meine Verständnisproblem: Wenn Namespaces nun _kein_ Schema referenzieren, sondern nur besagte Aufkleber sind, dann sind sie doch ziemlich wertlos. Ob man nun in der eingebundenen DTD foo:bar definiert oder <bingo> ist dem Parser egal, wenn der Namespace-URI dann auch nicht ausgewertet wird, bleibt es sich doch wirklich gleich oder? Man müsste den Elementen ihre ursprüngliche Bedeutung zukommen lassen! Wozu will man denn sonst gleichnamige Elemente auseinanderhalten? Doch nur, weil sie eine andere Bedeutung haben! Allerdings wird diese Bedeutung (von XML) nicht mitgeliefert :-( Ich hatte eben geglaubt, dass "xmlns" ein von XML selbst zur Verfügung gestelltes "reserviertes" Wort ist, ein Befehl quasi, diese URL aufzulösen (= zu expandieren?).

Wenn man z.B. sicher sein könnte, dass Elementnamen wie <sort>, <if> usw. in keinem XML-Dokument der Welt vorkommen könnten, wäre es unnötig in einem XSLT-Stylesheet jedesmal xsl:sort zu schreiben, damit der XSLT-Prozessor erkennt, dass er dies als Anweisung zu verstehen hat, und nicht das Element 1:1 in den Ergebnisbaum schreiben soll.

das ist ein interessanter Punkt. Allerdings ist XSL, bzw. dessen ausführender Arm (Parser), eben nur eine einzelne Anwendung, die _ihren eigenen_ Namespace erkennt, um ihre Befehle vom restlichen XML-Kauderwelsch auseinanderhalten kann. Aber wenn ich das von mir gebrachte Beispiel nochmal ansprechen darf: Angenommen die Käuferfirma (K) bekommt von der Verkäuferfirma (V) eine Rechnung wie vorher beschrieben. So muss die Applikation der Firma K den Namesspace der Firma V "deuten" können, es muss also das Schema in der Applikation "drinnen" sein, und mit dem Namespace-URI identifiziert werden, so wie ein XSL-Transformator eben die Bedeutung der Elementnamen "drinnen" haben muss. Da es aber anscheinend ziemlich schwierig ist einen xslt-processor zu bauen, der mehr als einen XSL-Namespace-URI annimmt, frage ich mich wie um alles in der Welt solche Applikationen dann hunderte Namespace-URIs (allein schon von jedem Lieferanten eine) verwalten soll? Wenn z.b: Chrysler bei Siemens irgendeinen tollen Chip für irgendein tolles neues Feature bestellen will? Der IE verlangt eine andere URI wie Sablotron, und der wieder eine andere wie ... naja u.s.w.

Es ist doch auch möglich z.b. mit XLink Teile eines Dokuments in ein anderes Dokument einzubinden? Wieso ist es dann nicht möglich ein Schema aus einer URL (!) zu laden, und einzubinden?

Der Vorteil von XML wäre ja genau dieser generische Austausch von Daten, dass man sich nicht vorher auf ein einheitliches Format/Schema einigen muss, um dann Daten austauschen zu können, sondern einfach in einem Namespace-URI eine Referenz auf das besagte Schema angegeben wird, welches auf der anderen Seite validiert werden kann. Und nicht erst sich 2 Techniker, und zwei Prozess-Analysten aus beiden Firmen für eine Woche zusammensetzen müssen, um einen gemeinsamen Standard auszutüfteln, so wie es bei EDI(FACT) doch bisher war. XML wäre da dann um nix besser, ausser dass man (als Mensch) die Daten leichter lesen kann, was aber wiederum nicht der Sinn der Sache ist, sondern wie der Name schon sagt, dass die Maschinen sich _verstehen_, darum gehts.

Ich weiss nicht ob ich mich klar ausgedrückt habe, und fürchte fast dass das ganze mit den Namespaces selber nur noch periphär was zu tun hat, allerdings ist es mir nichtsdestotrotz unklar, und ich würde mich freuen, wenn mir da jemand noch ein paar Denkanstösse liefern könnte, in welche Richtung ich meine Hirnwindungen ausrichten muss, damit ich den Fehler in meiner Aussage entdecken kann ;-)

Ich bin jetzt fast zwei Stunden an diesem Posting gesessen, mittlerweile weiss ich schon selber nicht mehr, was ich eigentlich wissen will, und was ich vielleicht besser anders fragen sollte *fg* Mir geht einfach nicht ein, warum xml dieses "Einbinden" von DTDs nicht unterstützt, von dem ich bis dato angenommen habe dass es so ist, und wie auf XML aufbauende Applikationen dann zu diesen DTDs kommen sollen. Den Link den du gepostet hast, hab ich mir freilich angesehen, aber so richtig dahintergekommen bin ich noch nicht, aber ich werde mir das Thema RDDL noch mal durch den Kopf gehen lassen, da mich dieser "Bug" wirklich wurmt :-(

lg bernhard

[Thomas J.S.]

Hallo Berhrad, Hallo Franz,

Wenn ich das also jetzt richtig interpretiert habe, sind Namespaces eigentlich nicht viel mehr als ein Aufkleber am Element, der sagt "Dieses Element gehört bitte schön mir. mfG [URI]" Mehr macht er nicht.

Genau. Du ordnest ducht den Prefix die so definierte Elemente deinem Namensraum zu. Aber weil ja auch andere diesen Prefix gewählt haben könnten, muss du deinen Namasraum eindeutig benennen, diese Benennung erfolgt dann durch die URI, die eindeutig ist.
Es ist richtg, das der Namesnraumprefix einem XML Parser nichts sagt, der Prefix wird vom Parser (intern) durch die URI ersetzt. Der Prexif ist eigentlich egal (xhtml, bla, foo, sup, etc.) wichtig ist die URI dahinter.

Man kann ja nicht einfach hergehen, und z.b. dem Element foo:bar das Attribut "typ" zuordnen, obwohl <bar> in der (Original-)DTD ein "type"-Attribut verlangt; dass man also die DTD selber reinschreibt, und in diesem Zuge Änderungen vornehmen kann, obwohl der Namespace auf eine eindeutige URI zeigt, was ja wohl heisst, dass bitte sehr dieses eine Schema zu verwenden ist, und nicht ob der Blindheit des Parsers einfach die Dokumentstrukur geändert werden kann. Was gerade beim elektronischen Datenaustausch wichtig ist. Es muss ja auf beiden Seiten dem selben Schema Genüge getan werden. Wenn eine Seite die xml-Datei anders interpretiert als die andere, gibts bekanntlich Stunk! Daher mein Beispiel aus der Wirtschaft, und nicht aus dem Web-publishing, wo dieses Problem vielleicht weniger wichtig scheint.

Du muss Schema und DTD auseinanderhalten.
XML Dokumente (vorausgesetzt es wird eine validirender Parser verwendet) werden gegen die DTD's validiert, also der Parser holt die DTD von der Angegebenen URI.
<am rande>
ich habe das beim cocoon 1.8 erlebt, wo es eine w3c DTD holen wollte, die es nicht mehr gab (xml in html) und deshalb die Parsing mit Fehlermeldung abbrach.
</am rande>

Hm, Semantik, Bedeutung, schwer zu sagen. Wirkliche Bedeutung verstehen Anwendungen auch mit XML nicht. Sie verstehen nur das, was auch in der Anwendung "reincodiert" ist, meist also eine Zuordnung von Element- oder Attributnamen zu "Aktionen". Erst wenn die Tagnamen gleich sind kommt es zu Missverständnissen. Und da helfen eben XML-Namensräume.

Und genau da liegt meine Verständnisproblem: Wenn Namespaces nun _kein_ Schema referenzieren, sondern nur besagte Aufkleber sind, dann sind sie doch ziemlich wertlos.

Nein. Wieder muss du Nemansraum und die Referenzierung eines Schemas auseinadnerhalten.
Es wurde schon gesagt wozu Namensräume gut sind. Die Spez. sagt dazu, dass es nicht Ziel von der Namensraum-URI ist, direkt für die Abfrage einer Schema, wenn einer existiert.
Es ist aber auch nicht verboten, dass hinter der URI auch eine Schema existiert. Damit kann man dann über die "einfache" Identifizierung hinaus einiges sagen: also nicht nur mein:element von dein:element unterschieden, aber ihm auch eine Bedeutung geben, also Aussagen über das Element selbst machen. Für was wird es benützt, hat es Attribute, was kann es Beinhalten, etc. Sematik wird hier natürlich nur im Sinne von Computer verwendet, denn es wird kein Schema leisten können, was ein Mensch kann (also ich sage "Tisch" und du weist wwas ich meine, auch wenn wir zwei verschiede Tische vor augen haben).

Wozu will man denn sonst gleichnamige Elemente auseinanderhalten? Doch nur, weil sie eine andere Bedeutung haben! Allerdings wird diese Bedeutung (von XML) nicht mitgeliefert :-(

Das kann ja kein Computer so we du dir es vorstellt. Es kann dir keine Maschine die Farbe "Blau" erklären.

Ich hatte eben geglaubt, dass "xmlns" ein von XML selbst zur Verfügung gestelltes "reserviertes" Wort ist, ein Befehl quasi, diese URL aufzulösen (= zu expandieren?).

Das ist es ja auch.
<books xmlns:buch="http://www.foo.com/buch">
durh das Attribut 'xmlns' weiss der Parser, dass hier eine Namensraumdeklaration (Prefix und Namensraum) erfolgt.
Dadurch wird es später möglich sein Elemente wie: buch:titleLife is Life</buch:title> zu nützen. Snst müsste man statt buch:title
<{http://www.foo.com/buch} title> schreiben, (übrigens dies nennt man 'fully-qualified names') was aber in XML nicht sein darf.

das ist ein interessanter Punkt. Allerdings ist XSL, bzw. dessen ausführender Arm (Parser), eben nur eine einzelne Anwendung, die _ihren eigenen_ Namespace erkennt, um ihre Befehle vom restlichen XML-Kauderwelsch auseinanderhalten kann. Aber wenn ich das von mir gebrachte Beispiel nochmal ansprechen darf: Angenommen die Käuferfirma (K) bekommt von der Verkäuferfirma (V) eine Rechnung wie vorher beschrieben. So muss die Applikation der Firma K den Namesspace der Firma V "deuten" können, es muss also das Schema in der Applikation "drinnen" sein, und mit dem Namespace-URI identifiziert werden, so wie ein XSL-Transformator eben die Bedeutung der Elementnamen "drinnen" haben muss. Da es aber anscheinend ziemlich schwierig ist einen xslt-processor zu bauen, der mehr als einen XSL-Namespace-URI annimmt,

du kannst auch mit XSLT Nemesnräume Unterscheiden:
(ich habe die xml/xsl datei für cocoon vorbereitet)
-----die xml datei -----

<?xml version="1.0"?>
<?xml-stylesheet href="namespace.xsl" type="text/xsl"?>
<?cocoon-process type="xslt"?>
<books xmlns:buch="http://www.foo.com/buch"
         xmlns:author="http://www.doublefoo.com/author">
<book>
buch:titleLife is Life</buch:title>
author:titleThe Good Boy</author:title>
</book>

<book>
buch:titleNix is Fix</buch:title>
author:titleThe Bad Boy</author:title>
</book>

<book>
<title>Ein Titel</title>
</book>
</books>
------------------
----- die xsl datei --------------
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:buch="http://www.foo.com/buch"
                xmlns:author="http://www.doublefoo.com/author"
                version="1.0">
 <xsl:template match="books">
  <xsl:processing-instruction name="cocoon-format">type="text/plain"</xsl:processing-instruction>
  <html>
  <body>
   Namespace nodes:
    <xsl:for-each select="namespace::*">
      <xsl:value-of select="name()"/>xsl:text </xsl:text>
    </xsl:for-each>
    xsl:apply-templates/
    </body>
   </html>
  </xsl:template>

<xsl:template match="book">
xsl:apply-templates/
</xsl:template>

<xsl:template match="buch:title">
   Finde buch titel.
  name          <xsl:value-of select="name()"/>
  local-name    <xsl:value-of select="local-name()"/>
  namespace-uri <xsl:value-of select="namespace-uri()"/>
  contents      xsl:apply-templates/
  </xsl:template>

<xsl:template match="author:*">
   Finde ein author node:
  name          <xsl:value-of select="name(.)"/>
  local-name    <xsl:value-of select="local-name(.)"/>
  namespace-uri <xsl:value-of select="namespace-uri(.)"/>
  contents      xsl:apply-templates/
  </xsl:template>

<xsl:template match="title">
   Finde einen titel vom default namespace:
  name          <xsl:value-of select="name(.)"/>
  local-name    <xsl:value-of select="local-name(.)"/>
  namespace-uri <xsl:value-of select="namespace-uri(.)"/>
  contents      xsl:apply-templates/
  </xsl:template>

<xsl:template match="*"/>

</xsl:stylesheet>

------------------------
-------- die erzeugte ausgabe --------------

Namespace nodes:
    xmlns:author xmlns:buch

Finde buch titel.
         name          buch:title
         local-name    title
         namespace-uri http://www.foo.com/buch
         contents      Life is Life

Finde ein author node:
         name          author:title
         local-name    title
         namespace-uri http://www.doublefoo.com/author
         contents      The Good Boy

Finde buch titel.
         name          buch:title
         local-name    title
         namespace-uri http://www.foo.com/buch
         contents      Nix is Fix

Finde ein author node:
         name          author:title
         local-name    title
         namespace-uri http://www.doublefoo.com/author
         contents      The Bad Boy

Finde einen titel vom default namespace:
         name          title
         local-name    title
         namespace-uri
         contents      Ein Titel

-----------

Grüße
Thomas

[fjh]

Hallo Bernhard, Hallo Thomas,

Du muss Schema und DTD auseinanderhalten.

Lediglich eine kleine Anmerkung:
Der allgemeine Begriff Schema steht für eine Inhalts- und Strukturbeschreibung, sei es ein Datenbank-Schema, eine DTD oder ein XML-Schema.
Ein XML-Schema und DTD sind also beide Schemata, aber dennoch auseinanderzuhalten; insbesondere auch was die Behandlung von Namensräumen angeht. In XML-Schema kann man nämlich sogenannte Zielnamensräume angeben, für die bestimmte Deklarationen gelten sollen, und so eben Schemata mit Namensräumen verknüpfen.

Gruß
Franz

[Stefan Muenz]

Hallo fjh

Klasse! Dieser Beitrag ist allerdings fast schon zu bedeutend und ausgereift fuer ein Forumsposting. Haettest du Interesse, den Text als Feature-Artikel aufzubereiten?

viele Gruesse
  Stefan Muenz