OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ 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>;

> 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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS