RE: SVGT 1.2: Appendix C3: SVG Error Processing

On Sun, 8 Jan 2006, 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.
> 
> No, it is an argument against mandating complex error handling 
> rules within specifications.

In that case I disagree. I think we should not mandate complex error 
handling because I think we should not mandate complex specs, not because 
we should not mandate complex error handling. That is, the error handling 
should always be well defined, and it should always be simple.


> 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).

Sure. But that has nothing to do with error handling, the same would apply 
in non-error cases as well.


> Because SVG has a complex processing model (e.g., scripting, event 
> handling, SMIL timing and synchronization model, property inheritance, 
> compositing)

Indeed, some would argue it is too complicated and needs drastic 
simplification -- I myself, for instance, have argued that SVG should be 
dropping features instead of adding new ones. Again, this has nothing to 
do with error handling -- SVG is having huge difficulties getting 
broad interoperability even in non-error cases at the moment.


> 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.

I do not see anyone arguing that we should have "fine grained" error 
handling rules.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 9 January 2006 00:33:04 UTC