DOM Parse XML source

Hallo,

ich habe gerade festgestellt, dass durch Verwenden des Befehls “DOM Parse XML source” der Inhalt der XML-Datei verändert wird. Es werden Leerzeichen und Umbrüche eingefügt.
Im folgenden Beispiel werden vor die Inline-Elemente im p-Element Umbrüche eingefügt. Lässt sich das verhindern?
4D v16.3 unter MAC OS 10.12.6

aus

Weitere Informationen zu DG…C…1, Anschluss Eingangsdruck pu, und DG…C…9, Anschluss Zwischraumdruck pz, siehe.


wird

<body>
    <p pstyle="Normal">Weitere Informationen zu DG..C..1, Anschluss Eingangsdruck p
  <sub>u,</sub> und DG..C..9, Anschluss Zwischraumdruck p
  <sub>z</sub>, siehe
  <xref keyref="id_mod_reh_20181025_161901" scope="doc"/>.
</p>
</body>

Lieben Gruß
Michael Rehkamp

Das Ergebnis hängt vom Parser ab, richtig. 4D verwendet den XERCES Parser, andere könnten andere Ergebnisse bringen, ob Sie damit aber glücklicher werden ist offen.

Der Parser nimmt den Wert eines Eintrags unverändert.
Allerdings haben Sie nicht einen Eintrag sondern viele. Wie Einzelwerte zusammen gesetzt werden, ist nun nicht vorgegeben, der Parser ist da recht frei.

Sie müssen entweder die Subelemente entfernen und alles in einen Text schreiben.
Oder den gesamten Block als CDATA kennzeichnen.
(Aus Wikipedia: Mit CDATA werden Zeichendaten gekennzeichnet, deren Inhalt vom Parser nicht analysiert wird.)
Oder encodieren, damit diese nicht mehr als XML Tags gewertet werden.
Oder falls Sie sicher wissen das diese nur Text ohne Leerzeichen, Umbruch, Tab, darstellen, parsen Sie rekursiv und setzen die Inhalte zu einem durchgängigen Text zusammen.

Sie könnten alternativ auch den SAX Parser testen, allerdings empfehle ich das nicht, weil das Verhalten eben nicht definiert ist - und somit nicht sichergestellt ist, das sich das Verhalten nicht irgendwann ändert (falls es denn überhaupt heute passen würde).
Es könnte sein, weil der DOM Parser eben einen DOM Baum aufbaut, und der ist schön ausgerichtet. Der SAX Parser geht recht primitiv Knoten per Knoten durch. Nicht so bequem, dafür, weil simpler, viel schneller.

Ich habe in V17.1 folgendes beobachtet:

$url_t:=“http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml

$root_t:=DOM Parse XML source($url_t) //meldet ab V17.x (!) XML Dokument als nicht ‘well formed’ (OK=0)

//über diesen Umweg geht es:

$status_l:=HTTP Get($url_t;$response_t) //kann das XML laden
$root_t:=DOM Parse XML variable($response_t) //und ohne Probleme parsen

Unter V16.5 konnte DOM Parse XML source diese URL noch direkt parsen

Parsen von XML wird von der Library Xerces durchgeführt. In v16 wurde Version 3.1.4 benutzt, ab v17 3.2.1.
Diese verhält sich offensichtlich anders bei HTTP 301 Meldungen und folgt diesen nicht mehr automatisch, ich vermute aus Sicherheitsgründen.

Wenn Sie dagegen HTTP Get verwenden, wird automatisch einem Redirect gefolgt.

Sie können das mit curl vergleichen, im Terminal (unter Mac) eingeben:

curl http://www.ecb.europa.eu/stats/eurofxref/eurofxref-daily.xml

(mit -L würde curl automatisch dem redirect folgen)

Direkt das Redirect (auf HTTPS) nutzen führt aber auch nicht zum Ziel, da das Ergebnis wieder eine „ungültige“ URL enthält:
xmlns=“http://www.ecb.int/vocabulary/2002-08-01/eurofxref”>

probiert man die aus, führt der Server wieder ein Redirect auf https aus – und das liefert 404 zurück.

Vermutlich hat der Web-Admin einen Zwangs-Redirekt für alle Seiten von HTTP auf HTTPS eingerichtet und dabei vergessen das es einige XML Dienste gibt - und diese nicht angepasst.

Durch den Umweg über HTTP Get können Sie das entschärfen, die Sicherheit von lokalen XML Daten wird von Xerces anders eingestuft.

Hi Thomas,

Sorry for the reply in english.

Thanks for the information about the change of behavior in Xerces (due to change of version).

Just a comment about xmlns…

Code :
A namespace-uri serves the purpose of identifying a
specific XML-based language – by having all of the
element names of this labguage in the same namespace
(making all of them have that same namespace-uri).

Other than that, a namespace uri has no additional
purpose.
It’s not a URL, it’s a URI. That is, it’s an
identifier (a name), not a location (an address).

In other words, having a xmlns with a url returning a 404 should not be a problem.

https://stackoverflow.com/questions/11600924/what-is-the-meaning-of-xmlns-url-in-xml-document

HTH

yes, I agree. I did not analysed the process in detail, to check what exactly failed.
To do so, you need to use a tool (such as Wireshark) able to read/decode the TLS encrypted communication to follow. Possible, but time consuming.

The full error message from Xerces reports pointers in schema not resolvable. When I noticed the redirect to HTTPS I thought it is related and stopped further investigation, as we could not solve it anyway…