Hey Jasleen.
Apologies for the delay in replying, I’ve been snowed under by work at
uni lately.
Jasleen Singh:
> I'm trying to build an error console for Squiggle, something like what
> firefox has, as part of my GSoC project. Currently, error handling is
> quite basic and any exception thrown is displayed in a dialog-box with
> the option to see the detailed stack-trace. However, under-certain
> circumstances, it may be possible to recover from the error, log it
> and continue execution. Or, if there is an error in the SVG document
> being parsed, it may make more sense to simply issue a warning, ignore
> the faulty element and continue with the rest of the document.
Right. So this “strict” error handling has been a feature of Batik that
has set it apart from other SVG implementations. It has its good and
bad points: it’s good because, as a developer, it can easily show you
where you’ve made mistakes in your SVG. As a user it’s not so good,
since often a tiny mistake in the markup will cause an obtrusive error
message to pop up, even though it’s not really affecting the document.
As some background, SVG 1.1 actually says this about elements which are
“in error”:
The following error processing shall occur when a document is in
error:
…
▪ The document shall be rendered up to, but not including, the first
element which has an error. Exceptions: […]
▪ A highly perceivable indication of error shall occur. For visual
rendering situations, an example of an indication of error would
be to render a translucent colored pattern such as a checkerboard
on top of the area where the SVG content is rendered.
— http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing
In practice, this isn’t what other implementations do. SVG Tiny 1.2
takes a different route, where most errors in attribute values are now
considered to be “unsupported attribute values”, which do not cause the
implementation to stop processing at that point, but rather disable
rendering of that element. Only a very few cases cause the document to
become “in error”.
My feeling is that both modes of error handling should be supported.
For 1.2 documents, the behaviour of disabling element rendering when an
unsupported attribute value is encountered will be required, but I’d
like the error handling behaviour to be configurable for 1.1 documents
(though in general I dislike differing behaviour for 1.1 and 1.2
documents).
I’m not sure how much you want (or will be able to) work on the 1.2
style of error handling in your project, though.
> Comments in the document could be displayed as messages (which would
> show the extent of the document that has been parsed and could be used
> during debugging). Displaying errors and warnings in a separate,
> normally-hidden dialog would make Squiggle more tolerant towards
> markup errors and would be a useful feature to have.
Yeah, something like the toolbar button in the Firefox Web Developer
extension (http://chrispederick.com/work/web-developer/) toolbar whose
icon shows whether there are errors or not, and when clicked shows the
error console.
Have you seen how Opera 9 shows markup errors when you load a document?
It’s pretty useful, as it gives you the context of the error:
http://sitesurgeon.co.uk/articles/images/opera9xml.jpg
> I looked up the source code (Batik-1.7 source snapshot) and found that
> the exceptions are displayed using the
> org.apache.batik.util.gui.JErrorPane class. It is not possible to
> simply replace this class with another as the information passed to it
> is insufficient. For parsing errors, the console would also need the
> Document being parsed. The console would then show a hyperlink which
> would open a window to edit the document on being clicked.
I agree, it might not be enough just to replace the JErrorPlane, you’ll
have to dig a bit further into the classes in the bridge package to
change how errors are handled.
> Also, in order to tolerate errors in the document, they must be
> handled as close to the place where they are being parsed as possible
> i.e. we cannot throw exceptions which are propagated too high-up where
> the whole process is simply aborted. To achieve this, I believe one
> will have to look at the parsing process and for each element, guess
> possible errors (incorrect or missing values), assume default values
> if it happens and continue to the next token.
So I think there are two kinds of errors here: one is markup errors,
where the XML document is not well formed (or not namespace well
formed). These errors will be signalled by the SAX parser (see the
SAXDocumentFactory and SAXSVGDocumentFactory classes). I think it is
necessary to stick with the strict error handling here, since that’s a
requirement of XML processors. Still, more useful error messages here
would be great (like Opera’s ones).
The second errors are SVG-specific ones, where an attribute is missing,
has a malformed value, or an element is in the wrong place in the
document. I don’t believe that these errors should be handled down at
the tokenising stage, since the errors can also come from DOM
manipulations.
> Any help/ideas on this would be highly appreciated. I've also created
> a simple GUI for the error console. A screen-shot is attached.
That’s a good start, I like it.
> Cameron: How do I submit code for the project? Do you have a separate
> branch for this where I can directly commit, or should I submit
> patches to you for review?
I’ll start investigating the best way to handle this.
Thanks,
Cameron
--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
