[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ERROR verb




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.