On Jan 1, 2006, at 4:00 PM, Jon Ferraiolo wrote:
>
> Jim,
> I agree with you. Also, I will say that if the SVG spec attempted to
> define recovery rules for every possible error condition, the 350 page
> spec would grow to 3500 pages (or maybe more). Also, some constrained
> execution environments can only implement simple error handling logic,
> whereas desktop implementations might be able to do more sophisticated
> error handling logic. There are also implementation differences
> between
> web browsers, where it is desirable to have common error handling
> between HTML and SVG, and embedded devices such as car navigation
> systems or Java+SVG applications on mobile phones (JSR-226).
From experience with HTML, CSS and XML, I would argue that leaving
error recovery unspecified is problematic and ultimately creates more
work for implementors.
HTML specifications have historically declined to specify error
recovery behavior. However, the end result is that current UAs must
in practice implement a large, complex, completely unspecified set of
error recovery behavior based on the behavior of past dominant UAs.
Conversely, CSS and XML are both explicit about error recovery
behavior. Partly as a result (and admittedly partly through shorter
history), CSS and XML parsers do not have to be filled with these
kinds of hacks since the specified behavior is relatively simple.
So I disagree with Jim's original bottom line:
Jim Ley wrote:
> Just define what an error is, and leave the rest to the UA. Vote for
> less work!
In fact, failing to specify error recovery behavior can ultimately
create more work for implementors, not less.
Regards,
Maciej