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://c
hrispederick.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:heycam jabber.org ▪ ICQ 26955922 ▪ MSN cammcc.id.au
------------------------------------------------------------
---------
To unsubscribe, e-mail: batik-dev-unsubscribexmlgraphics.apache.org
For additional commands, e-mail: batik-dev-helpxmlgraphics.apache.org
|
