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

RE: SVGT 1.2: Appendix C3: SVG Error Processing

From: Jon Ferraiolo <jonf@adobe.com>
Date: Sun, 8 Jan 2006 08:56:31 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C8576726@namail3.corp.adobe.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: <www-svg@w3.org>

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.

No, it is an argument against mandating complex error handling rules
within specifications. 

What I am saying is that it is OK to mandate simple error handling rules
(e.g., mandating CSS's rules that unsupported properties or supported
values for properties result acting as if the property assignment had
not been made, or mandating that UAs bail if they encounter
non-well-formed XML) but that we should avoid mandating complex error
handling rules (e.g., specifying highly specific error notification and
recovery behavior when a UA must do if an animation element contains a
'values' array where one entry in the array is incorrect but the others
are correct). Because SVG has a complex processing model (e.g.,
scripting, event handling, SMIL timing and synchronization model,
property inheritance, compositing), due to the complex interactions, it
is infeasible to attempt to define fine-grain error handling and
recovery behavior for every possible scenario, whereas it is indeed
feasible to define simplistic error handling rules, such as "highly
perceivable indication of error" whenever the content is "in error",
where UAs are provided latitude in how exactly they provide the
indication of error.

Received on Sunday, 8 January 2006 16:55:46 UTC

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