Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: [Sax-devel] SAX - endDocument() confusion again
 ----- Original Message ----- From: "Elliotte Rusty Harold" <elharo@m...> To: "Karl Waclawek" <karl@w...> Cc: "Toni Uusitalo" <toni.uusitalo@p...>; <xml-dev@l...>; <sax-devel@l...> > 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
