SVGT 1.2: Appendix C3: SVG Error Processing

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