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

Re: SVGT 1.2: Appendix C3: SVG Error Processing

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 1 Jan 2006 20:03:41 -0800
Message-Id: <B967F07A-7D2F-462A-9E42-548657F1DCB2@apple.com>
Cc: Jim Ley <jim@jibbering.com>, www-svg@w3.org
To: Jon Ferraiolo <jonf@adobe.com>

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.

Received on Monday, 2 January 2006 04:03:55 UTC

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