RE: SVGT 1.2: Appendix C3: SVG Error Processing

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).

Jon


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Jim Ley
Sent: Wednesday, December 28, 2005 3:02 PM
To: www-svg@w3.org
Subject: Re: SVGT 1.2: Appendix C3: SVG Error Processing



"Eric Seidel" <eseidel@apple.com> wrote in message 
news:502CD2E3-57B5-4309-B641-450371EB38DB@apple.com...
> These type of "recovery behaviors" are the de facto standard for SVG
> implementations (at least on the desktop) and it seems incorrect to
> me that the SVG 1.2 specification should require otherwise.

I fully agree, however the SVG specification should not specify such
error 
recovery, but should leave it purely to the implementation.  The working

group is not in a position to know now what appropriate recovery is for
all 
classes of errors, nor should implementation burden be forced on 
implementors for erroneous content, equally interopable error behaviour
is 
not really error behaviour as the specification dictates exactly what
should 
happen and it will leave such errors baked into all future
specifications.

Just define what an error is, and leave the rest to the UA.  Vote for
less 
work!

Jim.

Received on Sunday, 1 January 2006 23:59:14 UTC