W3C home > Mailing lists > Public > public-webarch-comments@w3.org > January to March 2004

LC Comment, 1.2.3

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Fri, 5 Mar 2004 20:04:26 +0100
Message-Id: <EC419660-6ED7-11D8-BF98-0003939E0B44@isr.umd.edu>
To: public-webarch-comments@w3.org

"""A user agent acts on behalf of the user and therefore is expected to  
help the user understand the nature of errors, and possibly overcome  
them. User agents that correct errors without the consent of the user  
are not acting on the user's behalf.

Principle: Error recovery

Silent recovery from error is harmful."""

I suspect this has been done to death, but here goes.

If someone acts on my behalf, they act as my representative. It's  
possible for someone to do so without my consent, e.g., if I'm  
incapacitated.

Actually, it seems that the term might be even weaker:
	http://www.tiscali.co.uk/reference/dictionaries/english/data/ 
d0081633.html

"""behalf
  To act or speak on behalf of someone or on someone's behalf is to do  
so as their representative. On behalf of should not be confused with on  
the part of: a speech on behalf of the Chairman is made by someone  
else, expressing the Chairman's thoughts: a speech on the part of the  
Chairman is one he makes himself.

In American English behalf is also used with in, to mean 'in someone's  
interest', 'for someone's benefit': Several people argued in his  
behalf."""

So the connection between lack of consent and lack of acting on the  
user's behalf isn't there.

Also, if I consent to silent error recovery, is the agent acting on my  
behalf?

Finally, I don't see the connection between the initial paragraph and  
the principle. *Who* is harmed by silent error recovery? Me? My agent?  
The web? Martians? Frolicking wildlife?

What counts as silent? Is being very unobtrusive not at all harmful? Or  
must the error recovery trumpet itself?

I'm honestly puzzled how to apply this principle *even though I think I  
believe it*, at least for some contexts. Trapping all cast exceptions  
and just continuing can seriously bite one in the butt, particularly if  
one is trying to debug things. On the other hand, it seems useful in  
places. (Indeed, there are people (the Erlang folks) who've elevated  
into a way of life, so called Let It Crash Programming  
(http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf). (Hmm. Upon  
rereading that section, I'm not sure it's quite as applicable as I  
hoped. He *defines* error to be an exception that the programmer  
doesn't know how to handle.)

Of course, the classic contrary experience is DWIM in Interlisp (or  
Microsoft Word's autocorrect).
	http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=dwim&action=Search

"""Experience with the cost of building a user agent to handle the  
diverse forms of ill-formed HTML content convinced the authors of the  
XML specification to require that agents fail deterministically upon  
encountering ill-formed content. Because users are unlikely to tolerate  
such failures, this design choice has pressured all parties into  
respecting XML's constraints, to the benefit of all.""""

Well, doesn't it shift the burdens around? I still get non-wellformed  
xml, and having Internet Explorer fail deterministically but in an  
extremely non-helpful way isn't particularly helpful to me. Even if  
silent error recovery is harmful, not all ways of not being silent are  
helpful, or even non harmful.

So, to try to be crisp:
	1) The first paragraph suggests that the problem with silent error  
recovery is a *wrong* (not necessarily an agent) done
	to a user by her agent
	2) The principle doesn't specify who is harmed or what is sufficient  
to avoid harm.
	3) At least one example suggests that harm to some people is ok so  
long as there is an overall benefit. But the overall
	benefit is merely asserted. The actual benefit seems to be to   
builders of user agents.

Cheers,
Bijan Parsia.
Received on Friday, 5 March 2004 14:04:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:37:30 GMT