Re: [Classpathx-xml] AElfred and File Not Found

[David Brownell]

> Even if I turn the URI into a full fledged file URI I get the error:

Hmm, then have you told the parser not to process external
parameter entities (and disabled validation)?

If the parser is required to access an entity in order to parse
a document in a given configuration, and the entity isn't there,
then clearly some unrecoverable error (like throwing FNF)
must be reported.


> This question pertains to how that error is being raised. Currently it is an
> IOException that is re-thrown by AElfred. Should the parameter entity be
> loaded by default if I do not have validating turned on? (This is controlled
> by the feature flag I think). 

That's how most Java parsers work, yes.  Any other answer leads
to portability problems, although at least SAX specifies those two
feature flags -- which applications can/should use to learn/control
what data is reported.  Given those flags, the portability problem
is just that SAX parsers _might_ have different default values for
those flags.  Fortunately, they usually don't.  (A notable contribution
of SAX to the XML community:  making the nasty variations allowed
by the XML REC be largely a non-issue, in one of the most active
XML developer communities:  Java dudes/dudettes.)


>        Even if the feature is turned on though,
> should it be a fatal error to encounter a non-existing entity? I think maybe
> it should be (as it is doing)--

Yes.  Though I'd say "unrecoverable", since the term "fatal error" is
defined in the SAX and XML specs, and does not address such
error cases.


>     but I am wondering if this error should be
> handled as a wrapped SAXParseException. The IOException needs to be handled
> separately outside of the call to parse. That feels odd... it is an IO
> problem-- but not necessarily an XML fatal error. Also, no error handler
> information is provided in this case.

Actually since it's not an XML error, it'd seem even more odd to report
it as one, through ErrorHandler!   It's clearly not a parsing exception;
that'd require some data to be parsing.  But it is clearly an I/O problem.

Exceptions carry information; in this case, you can tell that a file was not
found.  Which is more than you can learn from any SAXParseException
at this time.  (One of these days I'll dust off some of the SAX RFEs; the
ability to package detailed "what broke" info is high on the list.)  So I'd
say you actually get more information from a FNF than an SPE ... even
though the java.io.FNF doesn't say which F is NF! :)


> I admit to not being fully sure how SAX and the XML Rec are playing wrt this
> issue... : )

This is something the XML REC ignores.  They do a poor job IMO of
specifying entity processing, especially when it comes to skipping
external entities like this.

The behaviour could arguably be better specified by SAX, but on the
other hand it's quite explicit that parse() and resolve() are the places that
may report IOException (like FNF) errors.  The reason those two calls
are the only places IOExceptions may be thrown is IMO quite clear:
that's how, erm, I/O problems like non-existent entities should appear.

- Dave