W3C home > Mailing lists > Public > www-svg@w3.org > January 2006

RE: SVGT 1.2: Appendix C3: SVG Error Processing

From: Jon Ferraiolo <jonf@adobe.com>
Date: Sun, 1 Jan 2006 16:00:28 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C84F8475@namail3.corp.adobe.com>
To: "Jim Ley" <jim@jibbering.com>, <www-svg@w3.org>

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


-----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 
> 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
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
classes of errors, nor should implementation burden be forced on 
implementors for erroneous content, equally interopable error behaviour
not really error behaviour as the specification dictates exactly what
happen and it will leave such errors baked into all future

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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:06 UTC