Re: [xml-dev] Re: [Sax-devel] SAX - endDocument() confusion again

[Karl W. <ka...@wa...>]

----- Original Message ----- 
From: "Elliotte Rusty Harold" <el...@me...>
To: "Karl Waclawek" <ka...@wa...>
Cc: "Toni Uusitalo" <ton...@pa...>; <xm...@li...>;
<sax...@li...>


> 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