lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Re: error recovery for form parsing


From: Al Gilman
Subject: Re: LYNX-DEV Re: error recovery for form parsing
Date: Thu, 3 Apr 1997 15:15:47 -0500 (EST)

  From: Wayne Buttles <address@hidden>
  
  On Thu, 3 Apr 1997, Al Gilman wrote:
  
  > At the user interface, what one wants is _one_ "try harder"
  > command. 
  
  Interesting idea.
  
  > Please don't ask the user to select what style of parsing they
  > want.
  
  We would still have to ask what to fix.  A page with broken forms and bad
  commenting may get worse if you just try to get looser on everything at
  once.
  
I agree you don't want to do too many changes at once.

A secondary query could be like the "d)ocument, l)ink or c)ancel"
secondary query regarding a)dd_bookmark.  Or it might require
something like the print or download secondary query page.

I'm not sure we will always need to ask.  I would want you to
hang loose a little and see how some heuristics would do before
assuming that we always have to ask.

What the user can tell you won't necessarily isolate a unique
remedy.  An inoperable form can result from different HTML bugs.
Blank screen should be clear enough to the user.  What does the
user see that the program can't know?

It's sorta like we need to build a list of pathologies, and come
up with a strategy made up of what to do on what evidence.
Actually, we could list problems, list remedies, and then work on
how much dialog is needed to steer the application of remedies.

The one we have data on, an extraneous </OL> in the middle of a
form, should probably just be ignored w/o any retry command or
questions.  We may run out of things to ask about.  

If there are serious discrepancies in a page, I wouldn't want to
start passing it through the tables filter.  There may be a
natural hierarchy to the try-harder dodges, and if one seems to
help, a repeat TRY_HARDER could get the next one added in.

--
Al Gilman

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]