[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX/Java Proposed Changes

• To: XML Developers List <xml-dev@l...>, SAX Developers' List <sax-devel@l...>
• Subject: Re: SAX/Java Proposed Changes
• From: David Megginson <dmeggin@a...>
• Date: Fri, 05 Mar 2004 14:12:20 -0500
• In-reply-to: <p0601020ebc6e7a732736@[192.168.254.4]>
• References: <40488A7C.90003@a...> <p06010202bc6e524db87c@[192.168.254.4]> <4048BDA9.3010802@a...> <p0601020ebc6e7a732736@[192.168.254.4]>
• User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1

Elliotte Rusty Harold wrote:

> I don't think this is a change. I think this is what the specs say now, 
> and I think those parsers are today non-conformant. This would make it 
> more obvious to parser vendors that they have a problem and that they 
> need to call endDocument. Right now they're living in denial.

Well, as others have pointed out in early threads, it's a bit ambiguous. 
Looking over the current documentation on saxproject.org, I see that 
ContentHandler.endDocument says this:

   The SAX parser will invoke this method only once, and it will be the
   last method invoked during the parse. The parser shall not invoke this
   method until it has either abandoned parsing (because of an unrecoverable
   error) or reached the end of input.

while ErrorHandler.fatalError says this:

   The application must assume that the document is unusable after the parser
   has invoked this method, and should continue (if at all) only for the sake
   of collecting additional error messages: in fact, SAX parsers are free to
   stop reporting any other events once this method has been invoked.

On balance, I'd say that the current docs tilt towards making endDocument 
optional, but it's definitely not clean.  The text for endDocument() seems 
to assume that the method will always be called, but it never explicitly 
says that it *must* be; on the other hand, the text for fatalError() 
explicitly states that it does not have to be.

It would be nice to see this fixed in a major release in the future; for 
now, the best solution is probably just to add some text stating that it's 
optional for now, but might change in the future -- at least that will 
clarify the situation for people using SAX parsers.

> However, before making this change we should probably ask the relevant 
> Xerces and Oracle developers what they think. AS far as I can tell, 
> these are the only two currently maintained SAX parsers for Java, and 
> both have this problem. (At least Oracle 9 did. I haven't tested the 
> just released Oracle 10 yet.)

That would be a good thing to do for a bigger, fancier release.  This is 
going to be a small one.


All the best,


David

• References:
  • SAX/Java Proposed Changes
    • From: David Megginson <dmeggin@a...>
  • Re: SAX/Java Proposed Changes
    • From: Elliotte Rusty Harold <elharo@m...>
  • Re: SAX/Java Proposed Changes
    • From: David Megginson <dmeggin@a...>
  • Re: SAX/Java Proposed Changes
    • From: Elliotte Rusty Harold <elharo@m...>

• Prev by Date: Re: SAX/Java Proposed Changes
• Next by Date: More on REST and HTTP status codes
• Previous by thread: Re: SAX/Java Proposed Changes
• Next by thread: Re: SAX/Java Proposed Changes
• Index(es):
  • Date
  • Thread