Ich bräuchte mal die Meinung von jemandem der sich mit XML und dem
ganzen XML-Schema-Gedöns mal so richtig gut auskennt, für mich ist das
nämlich ein Buch mit sieben Siegeln.
Ich hab hier ein XML-Dokument das fängt so an:
Die komplette Datei hab ich auch mal angehängt. Ist ein offizielles
Beispiel aus der IO-Link-Spezifikation.
vscode mit der extension "XML Complete" beschwert sich mit zwei relativ
knapp gehaltenen Fehlermeldungen über "forbidden" und "not found" und
die scheinen sich irgendwie auf die schemaLocation zu beziehen. Und dann
bekomme ich kein sinnvolles Autocomplete und keine Fehler angemeckert
was ja eigentlich das einzige Ziel der ganzen Übung sein soll.
Frage:
* Ist die Zeile da oben überhaupt syntaktisch korrekt?
* Hätte die Software mit diesen Angaben das Schema finden müssen?
* Hat das Konsortium den Server falsch konfiguriert?
Bernd K. schrieb:> * Ist die Zeile da oben überhaupt syntaktisch korrekt?
Meiner Meinung nach schon.
> * Hätte die Software mit diesen Angaben das Schema finden müssen?
Sie hätte sie zumindest finden können, wenn sie sich nicht zu blöd
anstellt, denn hier:
https://io-link.com/IODD/2010/10/IODD1.1.xsd
findet sich das Schema tatsächlich.
Dass dort nicht unmittelbar eine direkte URL steht, ist offenbar nicht
unüblich, denn es könnte unter dem URL-Teil der "schemaLocation" auch
mehr als ein Schema geben, welches man von da laden kann.
Ist aber alles vage. Andere würden es so schreiben:
Generell sollten XML-Tools aber auch eine Möglichkeit haben, wie man
ihnen eine lokale Kopie des Schemas beibringt. xsi:schemaLocation wird
in diesem Falle benutzt, um die passende lokale Kopie aufzufinden.
Rein optisch sticht mir hier folgendes ins Auge:
xsi:schemaLocation="http://www.io-link.com/IODD/2010/10 IODD1.1.xsd <---
hier ist ein Blank vor IOD1.1.xsd in der URL drin (sowohl im Screenshot
als auch im Original-XML)
Bei Jörgs URL hingegen ist kein Blank zu finden. Vielleicht funktioniert
die deshalb und bei Bernds URL klappt es nicht?
Vielleicht einfach mal kurz ausprobieren, ob es sowas banales ist.
Das Leerzeichen gehört rein:
https://www.w3schools.com/XML/schema_schema.asp
"This attribute has two values, separated by a space. The first value is
the namespace to use. The second value is the location of the XML schema
to use for that namespace"
Joachim D. schrieb:> Im XML steht das ohne das 's' von 'https:'
OK, das hatte mir der Webserver dann beim Abruf des XSDs wohl
untergejubelt.
Soeren K. schrieb:> Dann mal das Leerzeichen mit %20 ersetzen
Nein. Innerhalb der Anführungszeichen müssen die beiden Komponenten
des Attributs durch ein Leerzeichen getrennt werden.
Was er versuchen kann ist, wie ich mit meinem Beispiel andeuten wollte,
dass im zweiten Teil dieses Attributs eine vollständige (absolute) URL
steht statt nur einer relativen. Beide Varianten scheinen üblich zu
sein.
Jörg W. schrieb:> Soeren K. schrieb:>> Dann mal das Leerzeichen mit %20 ersetzen>> Nein. Innerhalb der Anführungszeichen müssen die beiden Komponenten> des Attributs durch ein Leerzeichen getrennt werden.
.. Wenn aber dieses ominöse Plugin fehlerhaft umgesetzt ist..?
Edit:
Siehe hier:
https://github.com/rogalmic/vscode-xml-complete/blob/master/src/helpers/xsdloader.ts
Edit 2:
Weiterhin schreibt der Autor:
*XSD location URIs can be whitespace separated.*
Sowie:
Known Issues
This is a preview version, bugs expected...
Soeren K. schrieb:> Wenn aber dieses ominöse Plugin fehlerhaft umgesetzt ist..?
Dann sollte man es reparieren, statt syntaktisch korrektes XML zu
syntaktisch inkorrektem zu verwurschteln.
Jörg W. schrieb:> Soeren K. schrieb:>> Wenn aber dieses ominöse Plugin fehlerhaft umgesetzt ist..?>> Dann sollte man es reparieren, statt syntaktisch korrektes XML zu> syntaktisch inkorrektem zu verwurschteln.
Da hast du völlig recht, da hat der TE aber auch schon den korrekten Weg
gewählt und einen entsprechenden Bugreport gemacht. Allerdings scheint
das ja (siehe Edit) gewolltes Verhalten zu sein.
Abhilfe sollte wie gesagt das Ersetzen schaffen, dann kann der TE evtl.
weiterarbeiten.
Soeren K. schrieb:> Allerdings scheint das ja (siehe Edit) gewolltes Verhalten zu sein.
Ich bin davon noch nicht überzeugt. Ich denke nach wie vor, dass die
vorgeschlagene Variante, den zweiten Teil des Attributs auf eine
absolute URL zu ändern, einen Versuch wert wäre.
Allerdings blicke ich bei dem Code dort nicht komplett durch. Zumindest
splittet er das bei schemaLocation angegebene Attribut an vorhandenen
Leerzeichen (im XML-Parser), aber ich kann nicht nachvollziehen, was mit
dem Ergebnis dieser Operation dann im weiteren Verlauf passiert.
Jörg W. schrieb:> Ich denke nach wie vor, dass die> vorgeschlagene Variante, den zweiten Teil des Attributs auf eine> absolute URL zu ändern, einen Versuch wert wäre.
Das hab ich versucht und dann funktioniert es mit xml complete aber dann
meckert der offizielle IODD-Checker des Konsortiums daß diese Zeile
nicht wortgenau dem entspricht wie sie laut IODD-Standard sein soll.
Bernd K. schrieb:> Das hab ich versucht und dann funktioniert es mit xml complete aber dann> meckert der offizielle IODD-Checker des Konsortiums daß diese Zeile> nicht wortgenau dem entspricht wie sie laut IODD-Standard sein soll.
Irgendeinen Tod musst du halt sterben. :-/ Entweder entspricht es
wortgenau deren Vorgaben und dein Tool ist zu blöd, oder dein Tool kommt
damit zurecht, aber deren Konsistenztest nicht. Wenn du durchblickst,
was in diesen .ts-Dateien wo passiert, kannst du ja versuchen zu
erkennen, dass die XSD-URL in diesem Falle nur relativ ist und dass man
die erste Komponente des schemaLocation-Attributs der relativen URL noch
voransetzen muss, um eine fetchable URL zu erhalten.
Irgendwas lese ich da auch, was danach klingt, als würden sie die
runtergeladenen Schemas cachen. Möglicherweise scheitert der Test, ob
ein Schema bereits im Cache ist, dann aber an der gleichen Stelle
(absolute vs. relative URL matchen nicht, sodass er immer wieder neu
versucht, sie zu laden).
Eigentlich sollten XML-Tools auch eine Möglichkeit haben, Schemas
manuell bereitzustellen. Dass in der schemaLocation eine Location im
Internet angegeben wird, ist zwar naheliegend, aber nicht zwingend
erforderlich.
Jörg W. schrieb:> Eigentlich sollten XML-Tools auch eine Möglichkeit haben, Schemas> manuell bereitzustellen.
Ja, hab diese Möglichkeit mittlerweile gefunden, da kann man Namespaces
und absolute Pfade zu Schema-Dateien zuordnen die dann auch verwendet
werden.
Trotzdem hoff ich daß die vielleicht noch ne Heuristik einbauen die noch
schnell an den wahrscheinlichsten Orten nachschaut (Namespace ist eine
URL) ob sie nicht zufällig dort herum liegt.
Aber das akute Problem ist jetzt erstmal gelöst.
Bernd K. schrieb:> Trotzdem hoff ich daß die vielleicht noch ne Heuristik einbauen die noch> schnell an den wahrscheinlichsten Orten nachschaut (Namespace ist eine> URL) ob sie nicht zufällig dort herum liegt.
Der Namespace-Name hat wie eine UR_I_ auszusehen, ist aber eben nur ein
Name für einen Namespace. Daß mit ihm Resourcen ausfindig gemacht werden
können oder sollen, ist nirgendwo spezifiziert.
Der Namespace könnte z.B. auch
tel:+1-816-555-1212
heißen. Niemand wird einem unter dortiger Telefonummer dann aber die XSD
laut vorlesen.
EDIT: wozu soll ein Rechner für eine XSD das Internet besuchen. Die muß
man schon selbst lokal dort ablegen, wo sie der Parser erwartet. Es gibt
ja genug Anwendungen, die XML lesen, aber nicht am Internet hängen oder
gar hängen dürfen. Was würden sich solche Parser alles an Müll statt
XSDs reinladen.
Markus L. schrieb:> Daß mit ihm Resourcen ausfindig gemacht werden können oder sollen, ist> nirgendwo spezifiziert.
Ist es nicht, aber W3C schrieb (aus der Erinnerung, sinngemäß) dass
dieses Attribut einen Hinweis darauf geben soll oder kann, wie man zum
XSD gelangt. Ansonsten wäre das Attribut "schemaLocation" ja auch wenig
sinnvoll, denn der Name des Schemas selbst steht ja bereits bei "xmlns".
Jörg W. schrieb:> denn der Name des Schemas selbst steht ja bereits bei "xmlns"
Nö, das ist der Name des default Namespace für Elemente ohne expliziten
Namespace-Prefix. In "schemaLocation" steht dann wo das zum
entsprechenden Namespace passende Schema liegt.
Prinzipiell könnte man auch "xmlns" weglassen und
"xsi:noNamespaceSchemaLocation" verwenden.