<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.whatwg.org/index.php?action=history&amp;feed=atom&amp;title=Talk%3AValidator.nu_Web_Service_Interface</id>
	<title>Talk:Validator.nu Web Service Interface - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.whatwg.org/index.php?action=history&amp;feed=atom&amp;title=Talk%3AValidator.nu_Web_Service_Interface"/>
	<link rel="alternate" type="text/html" href="https://wiki.whatwg.org/index.php?title=Talk:Validator.nu_Web_Service_Interface&amp;action=history"/>
	<updated>2026-05-23T05:54:24Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.39.3</generator>
	<entry>
		<id>https://wiki.whatwg.org/index.php?title=Talk:Validator.nu_Web_Service_Interface&amp;diff=3194&amp;oldid=prev</id>
		<title>KornelLesinski: implementation feedback</title>
		<link rel="alternate" type="text/html" href="https://wiki.whatwg.org/index.php?title=Talk:Validator.nu_Web_Service_Interface&amp;diff=3194&amp;oldid=prev"/>
		<updated>2008-06-18T00:58:29Z</updated>

		<summary type="html">&lt;p&gt;implementation feedback&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;== Implementation feedback ==&lt;br /&gt;
Just for fun I&amp;#039;ve added sort-of compatible interface to the [http://hcard.geekhood.net hCard Validator].&lt;br /&gt;
&lt;br /&gt;
My Suggestions:&lt;br /&gt;
&lt;br /&gt;
* id field for messages, that uniquely identifies each problem (e.g &amp;quot;unknown-attribute&amp;quot;). This may allow clients to ignore certain warnings and accurately aggregate error statistics even if error message contains variable data or simply wording changes.&lt;br /&gt;
* if message contains variable data (e.g. &amp;quot;&amp;#039;div&amp;#039; not allowed in &amp;#039;span&amp;#039;&amp;quot;), the data could be additionally given in a separate array ([&amp;quot;div&amp;quot;,&amp;quot;span&amp;quot;]), to allow clients to localize messages using id + arguments.&lt;br /&gt;
* combinations of error types and subtypes are weird. It could be orthogonal severity {fatal|error|warning|info} and type {document|i/o|unsupported}, this way you could e.g. warn about i/o problems (like downgrading of https to http).&lt;br /&gt;
* message_html field to allow formatted messages (messages may contain code fragments, abbreviations or links and I&amp;#039;d like to display these nicely to the user)&lt;br /&gt;
* field for additional, more verbose message or hint how to fix the problem (html formatted too)&lt;br /&gt;
* field for url to the relevant part of the specification&lt;br /&gt;
* possibility to specify non-line-oriented error location (in my implementation I don&amp;#039;t track line numbers, but I could generate XPath path to the element)&lt;br /&gt;
* parse tree might contain code property which is just an XML serialisation of DOM (this is good enough for spotting misinterpreted markup)&lt;br /&gt;
* field or naming scheme for implementation-specific data?&lt;/div&gt;</summary>
		<author><name>KornelLesinski</name></author>
	</entry>
</feed>