Re: Error handling: yes, I did mean it
>Sean McGrath again:
>>I was simply making the point that the likes of
>> nsgmls foo.sgm | grep -c "^(BAR$"
>>can be a useful thing to do even if foo.sgm markup contains errors.
>Sure; but if you replace "grep -c" with some fancy java applet that
>does a business-critical application, this is no longer useful but
Of course! Wizard behaviour (i.e. guessing) and jaywalking software have
but space shuttles, on-line banking and healthcare are not some of them.
I think the issue here is whether or not this error handing behavour proposal is
mandatory for *all* XML apps.
First on the XML agenda is browsing right? I would have though that
browsing/visualisation is likely to be a happy hunting ground for
Wizardy behaviour. For reasons ranging from user friendliness through to product
differentiation. It seems totally out of character with the big Ms brilliant
of the market to think of them not trying to "help" the user as much as
I can see why any developer of a UA would want to turn on the flashing red light
in the top left hand corner signifying "Render this at your own risk buddy -
it is not
all there". But stopping at line 2 of a 10,000 line file and refusing to
other than errors sounds weird.
I take Peter Flynns very good point that with HTML browsers, this flashing
red light was not on
the menu. I think it could be a big help. People will not be able to
their nested tables look funny if the red light is on. As it stands of
course they shout
"red light what red light? No one told *me* about a red light!".
I am reminded of SGML 95 Boston. I think it was during the summing up
that the speaker envisaged the day when SGML parsers would
be able to report "your document does not parse - but its not too bad" and forge
on. This sounds very sensible to me. By all means lets *mandate* the reporting
of WF errors by anything that claims to be XML compliant but lets allow app.
to decide if forging on or stopping is the correct behavour on an application by
Sean Mc Grath