Hi,
Die XML-Datei:
Daß das kaputt ist, wurde Dir ja schon gesagt.
Das Parsen mit einer XSL-Datei:
<xsl:template match="xyz">
Da es kein Element xyz gibt, wird dieses template niemals matchen.
(ok, solange das XML kaputt ist, wird es niemals bis zur Transformation kommen)
<html>
<head>
[...]
</body>
</html>
</xsl:template>
Wenn es zur Anwendung käme, würde es ein fast vollständiges HTML-Dokument erzeugen.
Die Ausgabe mittels einer PHP-Datei (nur dieser Ausschnitt ist auch dargestellt):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<Html>
<HEAD>
Die zweite und dritte Zeile passen nicht zur ersten Zeile (in XHTML werden Elementnamen kleingeschrieben).
Hier beginnst Du also ein (X)HTML-Dokument.
<?php
$xsltproc = xslt_create();
$html1 = xslt_process($xsltproc, 'news.xml', 'news.xsl');
$html2 = xslt_process($xsltproc, 'news2.xml', 'news2.xsl');
if (!$html1) die('XSLT processing error: '.xslt_error($xsltproc));
xslt_free($xsltproc);
echo html_entity_decode($html1,ENT_QUOTES);
Wenn Dein Template für das xyz-Element benutzt würde, würdest Du hier mitten in Deinem XHTML-Dokument ein fast vollständiges HTML-Dokument unterbringen, Du hättest also ein html-Element mitten im html-Element, außerdem natürlich Inkonsistenzen wegen HTML-Elementen im XHTML-Dokument (<img ...> statt <img ... /> usw.).
Damit wäre nun der Zusammenhang hergestellt mit dem Problem, dass die Website Frontend PHP-Datei die XML-Dokumente unformatiert darstellt.
Ich hab keine Erfahrung mit xslt_process, aber vielleicht liefert das im Fehlerfall (nicht-xml als Eingabe) einfach das Quell-(Nicht-)XML zurück?
cu,
Andreas
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.