- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 1 Jan 2006 20:03:41 -0800
- To: Jon Ferraiolo <jonf@adobe.com>
- Cc: Jim Ley <jim@jibbering.com>, www-svg@w3.org
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 04:03:55 UTC