SVGT 1.2: Appendix C3: SVG Error Processing

[Eric Seidel]

== This message seems to have died somewhere in transit, resending. ==

Appendix C.3, describes how User Agents are expected to convey to the  
user when an SVG document is found to be in error.

Although the SVGT 1.2 specification makes no definitive  
recommendation as to what a "a highly perceivable indication of  
error" should look like (the SVG 1.1 Full specification gave an  
checkerboard overlay as an example), let us take the FireFox (and  
Safari) XML parse error as the example implementation for the context  
of our discussion:





Although this type of error works well for parse errors (whereby the  
user agent might not be able to show anything useful at all).  This  
type of error doesn't work as well for other situations which might  
put the document "in error".

For example:  If you were to write an svg which has <use> elements  
with circular dependancies.  This would put your document "in  
error".  Even if this circular dependancy came and went via  
javascript or animation.

Reporting this error to the end user seems to me of very little  
value, as there is nothing they are able to do about it.  
Particularly if say they are viewing this content on their cell  
phone.  (What should they do?  Call their service provider?)

Instead, what current desktop implementations (at least FireFox,  
Opera, ASV, and Safari) all do in these sorts of in-error situations,  
is to ignore the error and render as much of the document as is  
possible.  In this case, that might include omitting the entire <use>  
element, or in the case of something like a <linearGradient>  
xlink:href circular reference, forcibly terminating the reference  
chain at the point it becomes circular, and rendering it as though it  
had terminated there "naturally."

These type of "recovery behaviors" are the de facto standard for SVG  
implementations (at least on the desktop) and it seems incorrect to  
me that the SVG 1.2 specification should require otherwise.

I would like to ask the SVG working group to consider defining  
alternative error handling semantics more inline with those found in  
current SVG browser implementations.

Thanks,
Eric

[Jim Ley]

"Eric Seidel" <eseidel@...> wrote in message
news:502CD2E3-57B5-4309-B641-450371EB38DB@......
> These type of "recovery behaviors" are the de facto standard for SVG
> implementations (at least on the desktop) and it seems incorrect to
> me that the SVG 1.2 specification should require otherwise.

I fully agree, however the SVG specification should not specify such error
recovery, but should leave it purely to the implementation.  The working
group is not in a position to know now what appropriate recovery is for all
classes of errors, nor should implementation burden be forced on
implementors for erroneous content, equally interopable error behaviour is
not really error behaviour as the specification dictates exactly what should
happen and it will leave such errors baked into all future specifications.

Just define what an error is, and leave the rest to the UA.  Vote for less
work!

Jim.

[Jon Ferraiolo]

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

Jon


-----Original Message-----
From: www-svg-request@... [mailto:www-svg-request@...] On Behalf
Of Jim Ley
Sent: Wednesday, December 28, 2005 3:02 PM
To: www-svg@...
Subject: Re: SVGT 1.2: Appendix C3: SVG Error Processing



"Eric Seidel" <eseidel@...> wrote in message
news:502CD2E3-57B5-4309-B641-450371EB38DB@......
> These type of "recovery behaviors" are the de facto standard for SVG
> implementations (at least on the desktop) and it seems incorrect to
> me that the SVG 1.2 specification should require otherwise.

I fully agree, however the SVG specification should not specify such
error
recovery, but should leave it purely to the implementation.  The working

group is not in a position to know now what appropriate recovery is for
all
classes of errors, nor should implementation burden be forced on
implementors for erroneous content, equally interopable error behaviour
is
not really error behaviour as the specification dictates exactly what
should
happen and it will leave such errors baked into all future
specifications.

Just define what an error is, and leave the rest to the UA.  Vote for
less
work!

Jim.

[Maciej Stachowiak]

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

[Ian Hickson]

On Sun, 1 Jan 2006, Maciej Stachowiak wrote:
>
> 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.

It's also more work for the content developers, because they will write
non-conformant markup (guarenteed), and then wonder why it acts
differently in each browser, instead of writing non-conformant marker and
getting the same behaviour in all browsers.

And finally it's more work for the spec authors, because as soon as they
decide to make their spec actually useful to implementors and content
authors, they'll have to describe error handling, at which time they have
to go and reverse engineer all the UAs, coming up with test cases for all
the obscure cases, and end up having to document all the crazy de facto
error handling rules (which are always much more insane than any error
handling rules that one would get through forward planning).

In conclusion, it's more work for everyone, on the long term.

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

[Jim Ley]

"Maciej Stachowiak" <mjs@...> wrote in message
news:B967F07A-7D2F-462A-9E42-548657F1DCB2@......
> 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.

No, they don't _have_ to, they choose to.  And given that any error recovery
will be large and complex all you're gaining is the specified part - since a
dominant UA is likely to have bugs in the error recovery you are still stuck
choosing either to reverse engineer the dominant UA or follow the spec even
when all the content relies on the dominant UA behaviour.

Specifying error recovery does nothing to solve the decision of new user
agents deciding to ape the bugs and features of dominant UAs.

Jim.

[Jim Ley]

"Ian Hickson" <ian@...> wrote in message
news:Pine.LNX.4.62.0601020537360.2856@......
>
> On Sun, 1 Jan 2006, Maciej Stachowiak wrote:
>> In fact, failing to specify error recovery behavior can ultimately
>> create more work for implementors, not less.
>
> It's also more work for the content developers, because they will write
> non-conformant markup (guarenteed), and then wonder why it acts
> differently in each browser, instead of writing non-conformant marker and
> getting the same behaviour in all browsers.

If they get the same behaviour in all user agents, they will rely on the
behaviour, that means even the errors in the specification are baked into
the specification for ever more, indeed it's impossible to distinguish an
error from an actual part of the specification.

> In conclusion, it's more work for everyone, on the long term.

And useful to absolutely no-one.   Documents in Error, are in Error, there
can be no interopability in erroneous situations.

Jim.

[Maciej Stachowiak]

On Jan 2, 2006, at 1:34 AM, Jim Ley wrote:

> "Maciej Stachowiak" <mjs@...> wrote in message
> news:B967F07A-7D2F-462A-9E42-548657F1DCB2@......
>> 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.
>
> No, they don't _have_ to, they choose to.

They choose to because they wish to have more than the trivial number  
of users that is willing to put up with a great number of web sites  
not working. Over time there is pressure for UAs to converge in  
behavior for unspecified features that are easy to run into.

> And given that any error recovery will be large and complex all  
> you're gaining is the specified part - since a  dominant UA is  
> likely to have bugs in the error recovery you are still stuck  
> choosing either to reverse engineer the dominant UA or follow the  
> spec even when all the content relies on the dominant UA behaviour.

I disagree:

- No specified behavior could possibly be as ridiculous as the de  
facto standard behavior for HTML. For a few examples try doing a  
google search for the term "residual style". Ian and I have a lot of  
experience with these issues for HTML. This was part of Ian's point  
in his message. Write something sane while you have the chance, or  
the evolved de facto standard will be insane.

- Existence of a standard provides a club with which to beat  
laggardly UAs and content authors - consider how much work IE 7 is  
doing to improve their CSS support to comply with the standard, and  
how there is a "strict mode" where all UAs try to provide correct CSS  
behavior.

> Specifying error recovery does nothing to solve the decision of new  
> user agents deciding to ape the bugs and features of dominant UAs.

If error recovery is not specified, then some particular weird way of  
doing it is not a bug, it is a design choice. It's a lot harder to  
convince someone to change their design choices than to convince them  
to rectify a bug against a particular spec.

I don't think you have presented a convincing counter-argument to the  
experience of HTML, and the contrasting experiences of CSS and XML.  
Having done a fair amount of work on a mainstream web browser, I know  
that HTML is much harder to parse than CSS or XML as a result.

Regards,
Maciej

[David Woolley]

> differently in each browser, instead of writing non-conformant marker and
> getting the same behaviour in all browsers.

But the consequence of this policy is that there is no non-conformant
markup!  Even compromises likely eplicitly specifying that code be ignored
until a particular recovery point are likely to be treated as "undefined"
currently is, by browser developers, who will see a competitive advantage
in guessing what the author intended, which leads one to a world were
every construct does something "useful".

[Jim Ley]

"Maciej Stachowiak" <mjs@...>
>> Specifying error recovery does nothing to solve the decision of new  user
>> agents deciding to ape the bugs and features of dominant UAs.
>
> If error recovery is not specified, then some particular weird way of
> doing it is not a bug, it is a design choice. It's a lot harder to
> convince someone to change their design choices than to convince them  to
> rectify a bug against a particular spec.

The document is in error, that's a fact, if you feel a specification is
going to convince someone then "this document is in error" is enough of a
fact that it should convince them.

If the spec says "if you write this" "this happens" then it is much harder
to argue the document is in error at all, it uses a feature from the spec to
achieve a desired rendering, baking in the behaviour for ever more.

> I don't think you have presented a convincing counter-argument to the
> experience of HTML, and the contrasting experiences of CSS and XML.

Yes, HTML has been a great success, XML a failure at the user level!  CSS
was a failure such that a whole new good specification has been created -
the fact that creating the good specification was possible is because of
undefined error parsing.

> Having done a fair amount of work on a mainstream web browser, I know
> that HTML is much harder to parse than CSS or XML as a result.

Of course, but that is because you are deciding to render invalid content,
that is a choice, a choice I would always encourage, however your conclusion
that specifying rendering behaviour in every single error condition would be
of any help is incorrect.

I would absolutely encourage interopable error handling, I would encourage
all UA developers to sit down and work out an agreement - write it up as an
SVG Note whatever (I suggested a forum for discussion and a wiki previously
http://svg.jibbering.com/svg/2005-12-28.html#T23-38-35 ) , it just shouldn't
be part of the specification.

Error recovery is an inexact science, making it exact and preventing user
agent choice stops user agents picking better error recovery.  It also means
documents can no longer be in effect in error, meaning even user agents
which aren't interested in interoperating with a previous UA have to
implement a huge array of error recovery features, that they don't want to
implement.

Jim.

[Jon Ferraiolo]

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@...]
Sent: Sunday, January 01, 2006 8:04 PM
To: Jon Ferraiolo
Cc: Jim Ley; www-svg@...
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

[David Woolley]

> Conversely, CSS and XML are both explicit about error recovery  
> behavior. Partly as a result (and admittedly partly through shorter  

In both cases, the rules are about ensuring extensibility; they err towards
faulting or ignoring, rather than the more commercially acceptable best guess.
The XML well formedness rules are to allow the addition of elements unknown
to the user agent in a way that allows the user agent still to process the
elements it understands.  The CSS rules are about ignoring *valid* but not yet
defined constructs.

[Anne van Kesteren]

Quoting David Woolley <david@...>:
>> differently in each browser, instead of writing non-conformant marker and
>> getting the same behaviour in all browsers.
>
> But the consequence of this policy is that there is no non-conformant
> markup!

That is nonsense.

# p { foobar:baz; background:lime }

... is non conforming CSS. UAs do know _exactly_ what to extract from
the above
though, which is important for possible language extensions in the
future, etc.

Another example:

# ...
# <rect ...>
#  <circle .../>
# </rect>
# ...

Is not conforming SVG afaik as svg:rect can't contain svg:circle. UAs
do need to
know how to process it though. Can the svg:circle still be rerenced for
example
from an svg:use element? Et cetera. No interoparable error handling leads to
all kinds of hacks and abuse of the language. See HTML, see CSS, etc.


--
Anne van Kesteren
<http://annevankesteren.nl/>

[David Woolley]

> Quoting David Woolley <david@...>:
> > But the consequence of this policy is that there is no non-conformant
> > markup!
>
> That is nonsense.

My text could have done with better proof reading, as parts of it didn't
quite make sense, but...
 
> # p { foobar:baz; background:lime }
>
> ... is non conforming CSS. UAs do know _exactly_ what to extract from
> the above

As I pointed out in another reply, my view is that CSS rules aren't about
the handling of invalid content, but rather about forward compatibility:  
the ignoring of valid future content forms.  (Specifically, one can only
say that it is not conforming CSS 2.1; it might be conforming CSS 5.0.)

The general commercial imperative for handling invalid content is to to
do what the author most likely intended, which is generally incompatible
with a policy of ignoring it, as used by CSS.

Incidentally, one of the biggest problems for HTML was, in my view, not
deliberate error recovery, but the use of simplified parsing strategies
(in that case, basically treating opening and closing tags as independent
rendering commands) that are unable to detect syntax errors, but easier
to implement (although I'm not convinced that these always produced a
valid result for valid input).  That's relevant for small platform SVG
in that it is precisely such sorts of parsing simplification that allows
code size to be reduced.

[Boris Zbarsky]

Jim Ley wrote:
> Just define what an error is, and leave the rest to the UA.  Vote for less
> work!

For whom?  The spec authors?  Or the UA implementors and content authors?
Well-specified error behavior (even something as simple as XML's "this is a
fatal error, drop everything on the floor and stop" behavior) leads to
significantly less work for UA implementors and (in the long run) content
authors.  Of course it _is_ more work for the authors of the specification in
some cases, especially if the desired error-handling is complicated.

As a simple example, the ratio of time spent on HTML parsing vs time spent on
XML parsing in Gecko development right now is probably about 10:1.  Largely
because with XML parsing issues simply don't arise; you just follow the spec,
and as soon as content doesn't you bail.  No complex error-recovery behavior to
reverse-engineer.  The XML parser is definitely a lot less work for this
particular set of UA implementors, even though the HTML parser is older and more
mature.

-Boris

[Jon Ferraiolo]

My opinion:

* I am all for mandated rules for error handling behavior within specs
if it can be specified simply and implemented simply, such as an XML
parser bailing if the content is not valid XML.

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

Jon


-----Original Message-----
From: www-svg-request@... [mailto:www-svg-request@...] On Behalf
Of Boris Zbarsky
Sent: Thursday, January 05, 2006 1:40 PM
To: Jim Ley
Cc: www-svg@...
Subject: Re: SVGT 1.2: Appendix C3: SVG Error Processing


Jim Ley wrote:
> Just define what an error is, and leave the rest to the UA.  Vote for
less
> work!

For whom?  The spec authors?  Or the UA implementors and content
authors?
Well-specified error behavior (even something as simple as XML's "this
is a
fatal error, drop everything on the floor and stop" behavior) leads to
significantly less work for UA implementors and (in the long run)
content
authors.  Of course it _is_ more work for the authors of the
specification in
some cases, especially if the desired error-handling is complicated.

As a simple example, the ratio of time spent on HTML parsing vs time
spent on
XML parsing in Gecko development right now is probably about 10:1.
Largely
because with XML parsing issues simply don't arise; you just follow the
spec,
and as soon as content doesn't you bail.  No complex error-recovery
behavior to
reverse-engineer.  The XML parser is definitely a lot less work for this

particular set of UA implementors, even though the HTML parser is older
and more
mature.

-Boris

[Ian Hickson]

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 Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Jon Ferraiolo]

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.

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.

Jon

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'

[Maciej Stachowiak]

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

Regards,
Maciej