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, 8 Jan 2006 20:48:45 -0800
Message-Id: <7108EF3B-5A47-4FCD-948A-A6D1C3B14ADA@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, www-svg@w3.org
To: Jon Ferraiolo <jonf@adobe.com>

On Jan 8, 2006, at 8:56 AM, Jon Ferraiolo wrote:

> Ian wrote:
>> On Thu, 5 Jan 2006, Jon Ferraiolo wrote:
>>> * I am against mandated rules error handling (and instead leave  
>>> error
>>> handling to the UA, as Jim suggests) if the spec and implementation
>>> become complex.
>>> In other words, if it qualifies as KISS, then mandate interoperable
>>> error handling behavior; otherwise, tell content implementers and
>>> content developers that error handling is UA dependent.
>> That's not an argument against mandatory error handling, it's an
>> argument against complex specs.
> Ian,
> No, it is an argument against mandating complex error handling rules
> within specifications.

I think Ian's point was this: If error handling rules need to be  
complex, then you have a problem, whether or not you put that  
complexity in the spec explicitly.

I'm honestly not sure if SVG has underspecified error handling  
behavior at present. The original point at stake was a suggestion  
that the spec should not define error handling behavior at all.

Strict error-intolerance is an easy behavior to specify, but it does  
create some difficulties due to the vast quantity of non-comforming  
content out there. Another relatively simple rule that is likely to  
be more tolerant of existing content and more forward-compatible is  
some clearly defined version of "ignore attributes with illegal  
values, ignore elements found in diallowed places in the tree". I  
don't think the description of such a rule has to be complex, despite  
the complexity of SVGs processing model.

But either approach would be acceptable, so long as it is clearly  

Received on Monday, 9 January 2006 04:49:09 UTC

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