- From: Jon Ferraiolo <jonf@adobe.com>
- Date: Mon, 2 Jan 2006 08:21:38 -0800
- To: "Maciej Stachowiak" <mjs@apple.com>
- Cc: "Jim Ley" <jim@jibbering.com>, <www-svg@w3.org>
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