RE: New issue: error recovery practices (Re: Proposed TAG Finding : Internet Media Type registration, consistency of use)

From: Al Gilman [mailto:asgilman@iamdigex.net]

>To do this, you have to serve the customers who are ready and willing to complain.  

The MS dialog notes the error condition, then asks the user if they want to send the 
information it collected automatically.  That is the right way to go about it.  The 
web architects and the web users have to accept this and that given the state of 
practice, only partial improvements are possible.  One doesn't know what MS does 
when it receives the error.  On the other hand, a TR filed to us requires a 
reaction by contract.  Different kinds of business rules govern this.  I don't 
think that the way we do this works for laissez faire web browsing but might 
be applicable to web services under contract.  This feels to me like the wrong 
scope for the TAG.  If the web architecture is to field this, it probably is 
at a high level for the commodity protocols and at the strict levels of applying 
a web language such as XML *within* its applications because of semantic variations.  
See below.

>- file a complaint scriptlet that makes complaining a one-button operation.

Sure.  That is not too different from how non-web systems work.  It is a common trouble report.

>- service site that helps the user prepare a trouble report that is readily 
>understood and acted on by the recipient of the complaint.  

SOP.  The 'reaction' is an admin issue.  Most reports filed by external parties to 
any database go through the admin interface where a human evaluates it and determines the 
classification and reaction, if any.  They can't be compelled at that point unless a contract 
is in place to do so.  Few will sign up for that unless a fiduciary arrangement is in place.

>By default validation is done at this server, and not in the browser.  

That makes sense, but I quite like a browser that enables me to validate content.  It has a 
lot of benefits.  I can determine given laissez faire content that I have a quality exemplar. 
One reason HTML succeeded was the view source/copy and paste functionality for learning to 
create content.   A validator is a big help if the intent is to improve the content and the 
content creator competence.  A Draconian approach to that would have defeated this by 
raising the barriers too high too soon.  Simply expressing an opinion that validators should be 
common to browsers as well as authoring tools and servers as just in time QA would be 
of value and improve the situation.  Instead, HTML and XML took the opposite approach 
in promoting well-formed and tag stacking applications.   This is further complicated 
by the fact that for HTML, the kinds of content are mixed together (eg, scriptable 
forms in the same entity as paragraphs and lists).   It is one thing for a form to fail; 
another for a paragraph to disappear or be displayed in some ugly presentation. 

This isn't, "what we know now".  Most of us knew then.  Accepting it was a cost of emergence 
for a global hypermedia system being developed simultaneously and in parallel by independent 
sources.  SGML required validation for sensible reasons in open systems. 

Should the application "crash and burn" on *any* error?  

No.  It should complain if asked for minor nits and 
crash only if the error is severe, that is, can produce side effects that are 
predictably harmful. SGML systems work like that for validation.

The problem here is that validation errors, eg, what can 
be caught using off the shelf DTD or XML Schema or RELAX NG validation varies 
in severity by the semantic of the application.  So, it is helpful but not a 
complete solution.   Note that for some years, an HTML browser told us content had a 
missing right quote by the disappearance of the content.  Not very helpful but 
a clue that a validation pass was needed.  A bad script has to be caught in 
the authoring software by other means.

>the user-process may need to include reproducing the failure scenario in operation through a logging intermediary.

Yes.  See admin systems.

>- getCEO service that addresses the complaint where it belongs, not to the webmaster.

All locally determined.  Not a problem for the TAG or the W3C

len

Received on Thursday, 30 May 2002 11:45:44 UTC