<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: W3C sperrt Java aus</title>
	<atom:link href="http://blog.linkwerk.com/2009/11/w3c-sperrt-java-aus/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.linkwerk.com/2009/11/w3c-sperrt-java-aus/</link>
	<description>XML, Semantic Web, Internet, Java und viel mehr</description>
	<pubDate>Sun, 01 Aug 2010 03:30:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Stefan Mintert</title>
		<link>http://blog.linkwerk.com/2009/11/w3c-sperrt-java-aus/comment-page-1/#comment-253</link>
		<dc:creator>Stefan Mintert</dc:creator>
		<pubDate>Sun, 22 Nov 2009 12:43:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.linkwerk.com/?p=144#comment-253</guid>
		<description>Vielen Dank für die Erwiderung; dazu noch von derart fachkundiger Seite! Das gibt mir Gelegenheit, einige Dinge zu präzisieren, die ich im Blogartikel nicht klar genug formuliert habe. 

Ich verstehe den System Identifier auch nicht als Anweisung zur Validierung. Allerdings ist in der XML-Spezifikation an der fraglichen Stelle (http://www.w3.org/TR/REC-xml/#NT-ExternalID) schon deutlich die Rede vom Zugriff auf die Ressource: "Attempts to retrieve the resource identified by a URI may be redirected at the parser level (for example, in an entity resolver) or below (at the protocol level, for example, via an HTTP Location: header)." Das ist für mich ein deutlicher Unterschied zu z.B. Namensraum-URIs, die keine Ressource bezeichnen. Zusätzlich zu meinem Verständnis der Angelegenheit bei SGML, hat diese Stelle der XML-Spezifikation meine Vorstellung geprägt, der System Identifier diene explizit dem Zugriff.

Darüber hinaus verstehe ich voll und ganz, dass und weshalb das W3C den Zugriff wie im Artikel beschrieben, blockiert. Nebenbei: Der provokante Titel war natürlich Absicht, um die Aufmerksamkeit der Leser zu wecken.

Und abschließend: Ich stimme voll damit überein, dass es Aufgabe der XSLT-Engine wäre, sich mit einer vernünftigen User-Agent-Kennung auszuweisen. (Es handelte sich bei meinen Versuchen übrigens um einen nicht ganz aktuellen Saxon 9.x in Zusammenarbeit mit dem "Apache Commons"-Resolver; ich gehe davon aus, dass der Resolver für die unpräzise User-Agent-Angabe verantwortlich ist, da ich den Saxon mit der Option -x:org.apache.xml.resolver.tools.ResolvingXMLReader aufgerufen habe.)

Ich hoffe, dass auch andere Entwickler auf dieses Problem stoßen und sie Lösungen suchen, die den meiner Meinung nach sowieso unnötigen Netzzugriff umgehen; vielleicht ein Katalog oder der "caching proxy"...</description>
		<content:encoded><![CDATA[<p>Vielen Dank für die Erwiderung; dazu noch von derart fachkundiger Seite! Das gibt mir Gelegenheit, einige Dinge zu präzisieren, die ich im Blogartikel nicht klar genug formuliert habe. </p>
<p>Ich verstehe den System Identifier auch nicht als Anweisung zur Validierung. Allerdings ist in der XML-Spezifikation an der fraglichen Stelle (http://www.w3.org/TR/REC-xml/#NT-ExternalID) schon deutlich die Rede vom Zugriff auf die Ressource: &#8220;Attempts to retrieve the resource identified by a URI may be redirected at the parser level (for example, in an entity resolver) or below (at the protocol level, for example, via an HTTP Location: header).&#8221; Das ist für mich ein deutlicher Unterschied zu z.B. Namensraum-URIs, die keine Ressource bezeichnen. Zusätzlich zu meinem Verständnis der Angelegenheit bei SGML, hat diese Stelle der XML-Spezifikation meine Vorstellung geprägt, der System Identifier diene explizit dem Zugriff.</p>
<p>Darüber hinaus verstehe ich voll und ganz, dass und weshalb das W3C den Zugriff wie im Artikel beschrieben, blockiert. Nebenbei: Der provokante Titel war natürlich Absicht, um die Aufmerksamkeit der Leser zu wecken.</p>
<p>Und abschließend: Ich stimme voll damit überein, dass es Aufgabe der XSLT-Engine wäre, sich mit einer vernünftigen User-Agent-Kennung auszuweisen. (Es handelte sich bei meinen Versuchen übrigens um einen nicht ganz aktuellen Saxon 9.x in Zusammenarbeit mit dem &#8220;Apache Commons&#8221;-Resolver; ich gehe davon aus, dass der Resolver für die unpräzise User-Agent-Angabe verantwortlich ist, da ich den Saxon mit der Option -x:org.apache.xml.resolver.tools.ResolvingXMLReader aufgerufen habe.)</p>
<p>Ich hoffe, dass auch andere Entwickler auf dieses Problem stoßen und sie Lösungen suchen, die den meiner Meinung nach sowieso unnötigen Netzzugriff umgehen; vielleicht ein Katalog oder der &#8220;caching proxy&#8221;&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: C. M. Sperberg-McQueen</title>
		<link>http://blog.linkwerk.com/2009/11/w3c-sperrt-java-aus/comment-page-1/#comment-252</link>
		<dc:creator>C. M. Sperberg-McQueen</dc:creator>
		<pubDate>Fri, 20 Nov 2009 19:04:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.linkwerk.com/?p=144#comment-252</guid>
		<description>Ausgezeichnete Beschreibung der Problematik.  Bravo!

Ich sehe allerdings die Frage von Zugriff / Identifikation etwas anderes:  ob zugegriffen werden soll oder muss, hängt m.E. weniger von der Art des Bezeichners als von der Art des Verweises ab.  

Die Anwesenheit einer Dokumenttypvereinbarung hat eine rein deklarative Bedeutung, sagt etwas über das Dokument aus, und bildet in sich noch keine Anweisung an die Software, das Dokument gegen die DTD zu validieren.  (Das ist für Webbrowser wesentlich, und ich verstehe die Äusserungen des W3C in diesem Sinne.) Auch wenn man validieren will, hat der externe Verweis eine deklarative Bedeutung, der man u.U. ohne erneuten Zugriff auf den Server genügen kann (z.B. mittels eines Katalogs oder eines Caches).

Dass man auf den Server gelegentlich zugreifen muss und soll, will auch das W3C nicht bestreiten.  Aber wenn bei einem Programm etwas schiefgeht, und das Programm auf dieselbe Ressource wiederholt zugreift, ist es sehr nützlich, eine User-Agent-Angabe zu haben, die das Programm identifiziert.  Die Erfahrung hat gelehrt, dass nachzufragen, wer an einem bestimmten Netzknote gestern mit 'Java/1.6.0_16' gearbeitet, nichts bringt, denn alle haben das.  Die XSLT-Engine, die Sie anwenden, täte besser, sich selbst als User-Agent zu nennen.  (Man hat mir gesagt, das sei bei den geläufigen Java Libraries nicht schwierig; ich habe es noch nicht selber probiert.)</description>
		<content:encoded><![CDATA[<p>Ausgezeichnete Beschreibung der Problematik.  Bravo!</p>
<p>Ich sehe allerdings die Frage von Zugriff / Identifikation etwas anderes:  ob zugegriffen werden soll oder muss, hängt m.E. weniger von der Art des Bezeichners als von der Art des Verweises ab.  </p>
<p>Die Anwesenheit einer Dokumenttypvereinbarung hat eine rein deklarative Bedeutung, sagt etwas über das Dokument aus, und bildet in sich noch keine Anweisung an die Software, das Dokument gegen die DTD zu validieren.  (Das ist für Webbrowser wesentlich, und ich verstehe die Äusserungen des W3C in diesem Sinne.) Auch wenn man validieren will, hat der externe Verweis eine deklarative Bedeutung, der man u.U. ohne erneuten Zugriff auf den Server genügen kann (z.B. mittels eines Katalogs oder eines Caches).</p>
<p>Dass man auf den Server gelegentlich zugreifen muss und soll, will auch das W3C nicht bestreiten.  Aber wenn bei einem Programm etwas schiefgeht, und das Programm auf dieselbe Ressource wiederholt zugreift, ist es sehr nützlich, eine User-Agent-Angabe zu haben, die das Programm identifiziert.  Die Erfahrung hat gelehrt, dass nachzufragen, wer an einem bestimmten Netzknote gestern mit &#8216;Java/1.6.0_16&#8242; gearbeitet, nichts bringt, denn alle haben das.  Die XSLT-Engine, die Sie anwenden, täte besser, sich selbst als User-Agent zu nennen.  (Man hat mir gesagt, das sei bei den geläufigen Java Libraries nicht schwierig; ich habe es noch nicht selber probiert.)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
