RE: SVGT 1.2: Appendix C3: SVG Error Processing

Maciej, Ian, Jim,
You all make good points. At this point, however, I think the discussion
has moved into vague philosophical discussion where some folks say that
UA-dependent error handling is best and others say have the spec include
well-defined error handling is best. My guess is that if particular
error cases were brought up, the various contributors to this thread
would say that some errors warrant a clear definition in the spec about
error handling and other errors warrant UA-dependent error handling.
Thus, it would be more useful to move the discussion to specific cases
than continue the philosophical discussion.

One thing I will point out is that Maciej claims below that CSS and XML
have explicit error handling behavior rules. I was under the impression
that the latest draft of Tiny 1.2 adopts CSS's error handling behavior
rules (e.g., unsupported values are treated as if they were not
specified) and of course SVG uses XML to express its syntax. If SVG Tiny
1.2 falls short on incorporating CSS and XML's error handling behavior
rules somehow, it would be great to hear the specifics.

Jon

-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Sunday, January 01, 2006 8:04 PM
To: Jon Ferraiolo
Cc: Jim Ley; www-svg@w3.org
Subject: Re: SVGT 1.2: Appendix C3: SVG Error Processing


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

Received on Monday, 2 January 2006 16:20:25 UTC