nicht angemeldet
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