[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
To: "Karl Waclawek" <karl@waclawek.net>
Cc: "Toni Uusitalo" <toni.uusitalo@pan.nu>; <xml-dev@lists.xml.org>;
<sax-devel@lists.sourceforge.net>
> Yes, but the situation is this:
>
> 1. Parser opens stream.
> 2. Parser calls setDocumentLocator and passes in a Locator2.
> 3. Parser calls startDocument
> 4. Parser parses XML declaration. Oops there's an error!
> 5. Parser calls fatalError
> 6. In fatalError Client calls Locator2.getXMLVersion and/or getEncoding.
> 7. Parser calls endDocument.
>
> What is the Locator2 supposed to return?
>
> It's to avoid this problem, that Parsifal is not calling either
> setDocumentLocator or startDocument until the declaration (or lack
> thereof) has been successfully parsed.
>
> Possibly, there's a loophole, however The Locator JavaDoc says:
>
> Note that the results returned by the object will be valid only
> during the scope of each callback method: the application will
> receive unpredictable results if it attempts to use the locator at
> any other time, or after parsing completes.
>
> I think it's reasonable to say that parsing was completed before
> fatalError was called; not completed successfully of course, but
> definitely completed. Therefore, there's no place in this chain where
> the Locator methods can be expected to return correct information.
Actually, I am not sure that one can say that formally,
but it doesn't matter, IMO.
> Therefore Parsifal (and other SAX parsers) should indeed call
> startDocument, fatalError, and endDocument in that order when they
> encounter an error very early in the XML document. If the client uses
> the Locator2 object at any point in this process, they deserve what
> they get.
I agree. If the error says that the very information you want
could not be retrieved, well, then you have to take that into account.
> Possible problem with this chain of reasoning: in more normal
> circumstances it's very useful to use a Locator in fatalError() to
> get the line and column number where the errror appears. This logic
> would forbid such use.
I would not say so. You just have to take the type of error
into account. Why should Locator be useful when the error says
that it can't be?
> Hmm, still another tricky bit, thisn one not even requiring an error:
>
> 1. Parser opens stream.
> 2. Parser calls setDocumentLocator and passes in a Locator2.
> 3. Parser calls startDocument. startDocument returns.
> 4. Another thread uses the Locator2 object before the parser has
> parsed the XML declaration.
>
> What do getXMLVersion and getEncoding return?
You are only allowed to use Locator in a call-back, I think.
How can the other thread be in a call-back? Is the parser
supposed to be thread-safe?
> I think the best solution is to make a minor fix to the Locator2
> JavaDocs that allow (indeed require) these methods to return null at
> points where the version and encoding are not known.
Sure, that sounds like a good requirement in any case.
Karl
|
