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