Re: error handling

[Thierry Kormann <Th...@sophia.inria.fr>]

> In general for MalformedSVGException, do you plan to have a non "strict"
> policy available. I explain: by default when such an error is
> encountered, the exception is thrown and the loading stops at the place
> of the error. But do you plan to have a mode where these kind of errors
> are ignored (just to get an idea of what could be the file if it was
> correctly formed for example when somebody forgot to put type="text/css"
> on a style element)?

Well, the spec says we have to stop immediatly. I think it's a good idea as 
with a huge document it's easier to find where is the error when you just have 
the valid part displayed. So that will be the default mode.

Anyway, one thing I plan to do is the let the builder continue (via a menu 
option for example). I will just not display the subtree where the error 
occured (ie. a path data is not valid - I will not display the path or
a <g> is not valid - the whole subtree will not be displayed).

> Here also a non "strict" policy could help to load files that have been
> designed with property values other than specified one (for particular
> extensions for example)

For custom extensions, they will be in a custom namespace so not consider at 
all in our standard bridges.

> For CSS, do you plan to have a particular kind of exception for bad URI
> references?

I don't know yet anyway the error message will explain that the URI is not 
find. I don't know yet if we need a particular exception class for that.

Thierry


-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis

Re: error handling

[Christophe Jolif <cj...@ilog.fr>]

Thierry,

Thierry Kormann wrote:
> 
> > In general for MalformedSVGException, do you plan to have a non "strict"
> > policy available. I explain: by default when such an error is
> > encountered, the exception is thrown and the loading stops at the place
> > of the error. But do you plan to have a mode where these kind of errors
> > are ignored (just to get an idea of what could be the file if it was
> > correctly formed for example when somebody forgot to put type="text/css"
> > on a style element)?
> 
> Well, the spec says we have to stop immediatly. I think it's a good idea as
> with a huge document it's easier to find where is the error when you just have
> the valid part displayed. So that will be the default mode.

Yes I know. I was just talking about adding another mode not removing
the default SVG one.
 
> Anyway, one thing I plan to do is the let the builder continue (via a menu
> option for example). I will just not display the subtree where the error
> occured (ie. a path data is not valid - I will not display the path or
> a <g> is not valid - the whole subtree will not be displayed).

Unfortunately, this will probably not solve the case I was talking about
<style> * {rect:blue} </style>. I still think it could be valuable for
certain cases to have a mode that when it finds an error in an attribute
use the default value instead and go further. I don't say that we need
it in the default provided SVG Viewer but it could be interesting to
have it in the lib to let advanced users & customizers use it.
 
> > Here also a non "strict" policy could help to load files that have been
> > designed with property values other than specified one (for particular
> > extensions for example)
> 
> For custom extensions, they will be in a custom namespace so not consider at
> all in our standard bridges.

I'm sorry if I misexplained but I was talking about CSS properties
values, so namespaces are not the point here. For example if the user
wants to be able to use its own system colors identifiers instead of the
255 (or whatever) SVG provided ones, It will be interesting to have a
mode not throwing an exception when seeing "vert" instead of "green" for
a fill value. One more time, I'm not talking here about a default mode
but about an advance possibility.
 
> > For CSS, do you plan to have a particular kind of exception for bad URI
> > references?
> 
> I don't know yet anyway the error message will explain that the URI is not
> find. I don't know yet if we need a particular exception class for that.

Maybe yes, because your CSS error is described as:

IllegalCSSPropertyValueException
----------------------------------

        Thrown when a css property value is not recognized by the CSS
engine

a bad URI reference (pointing to an element that is not reachable) is
not exactly an illegal value. Indeed CSS accepts this value, but SVG
can't do anything with it. If we want to have one exception we need to
change a little bit the definition of the exception.
Anyway we need to clarify what to do with a bad URI ref, because the
spec is not very clear. It says that a non-existant (a non-reachable is
non-existant I guess) URI should be treated as an "invalid reference".
And the only place it is talking about "invalid reference" is on
xlink:href attribute of textPath, where it says we should not render it
and go in error. It doesn't say for paint servers or filters what to do
if the URI is invalid...
And here also I think we should have a mode that ignore invalid
reference and go further (if your network is down and you want to load
an SVG file referencing an external one...)

-- 
Christophe