RE: SVGT 1.2: Appendix C3: SVG Error Processing

Ian,
If your complaint about error processing boils down to complaints about
the SVG language being too complex, my response is that it isn't helpful
to toss vague complaints about complexity; in contrast, the very many
specific detailed comments that you and others have provided are
extremely helpful.

I am glad to hear you say:
--------------- 
I do not see anyone arguing that we should have "fine grained" error 
handling rules. 
---------------

Jon


-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch] 
Sent: Sunday, January 08, 2006 4:33 PM
To: Jon Ferraiolo
Cc: www-svg@w3.org
Subject: 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 14:34:48 UTC