Re: ERROR verb

[Henry Story <henry.story@xxxxxxxxxxx>]

So let me make a first attempt at a rock solid case:

1. XML has very strict compliance rules.
2. The W3C does not want these to be broken (or we are back to HTML 
hell)
3. Currently there is no way to automatically and easily notify a 
server that the XML+header it generates is not compliant.
4. For popular XML formats this leads to clients being written that 
work their way around limitation (1), to gain market share.
5. Attempting to gain market share is a business necessity
6. (4)&(5) lead to competition of clients towards a spiral of 
non-conformance.
7. (6) implies that breaking (1) cannot be stopped. Going against W3C 
desire (2)

Hence currently the W3C has a structure in place that is not 
maintainable. A simple change could fix it. Therefore the fix should be 
implemented.

Why would the ERR fix the problem?
It would break the spiral of non-conformance at (6).
As clients report errors to the servers, the server owners will be able 
to quickly fix the problem.

Why this over a specialized solution with a URL for reporting problems? 
This solution is the most conformant to the REST architecture of the 
web. Not only can clients send ERR messages, proxies could also do 
this, leading to a virtuous circle of compliance.

Furthermore ERR already works by default. An ERR request will already 
log an error in the error log of the most popular web server, as 
expected. Empirical research is needed for other servers. But I no of 
no server that does not generate log files!

It is worth pursuing this first in Atom, then wider. It does not matter 
if it takes time, because the problem we are dealing with is a wider 
problem. For us the option of this solution, gives us a retort to those 
who because of widespread XML compliance issue want to bypass all of 
XML compliance. We can now say: deal with the problem as you see fit, 
but you MUST send an ERR request when you come across a problem.




On 19 Jun 2004, at 16:05, Bill de hÓra wrote:
> That's the case that needs to be made. If it is made then it could be 
> brought to the W3C TAG perhaps. But as I said the case needs to be 
> cast-iron; web arch folks are very tough about mucking with interface 
> unformity.