Und Ja, das reCaptcha erfordert Javascript. Es gibt auch eine Javascript-freie Variante, die aber umständlicher zu benutzen ist (siehe http://www.heise.de/ix/artikel/Turing-fuer-alle-1033340.html); aus diesem Grund verwenden wir sie für unser Blog nicht. Mir ist klar, dass es mit dem Captcha nicht ganz bequem ist, allerdings hatten wir aufgrund der Spammenge die Kommentarfunktion zuvor komplett deaktiviert — auch keine schöne Option.

edit: Ich habe Google für dieses Posting JavaScript gestatten müssen. Und das obwohl auch Google Java User-Agents aussperrt. Das Captchaelement ist aber ansonsten unsichtbar. ^^

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”…

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.)