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 ]

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

Maybe the best solution is to abandon Locator2 for this altogether.

Again, offlist discussion from Michael Glavassevich:

"Locator2 just isn't a good home for the XML version or encoding. They have
nothing to do with the document location and would have been better
communicated through some XmlDecl callback (as they are in Xerces' XNI a
stream based API similar to SAX). Even though they've been around for a
while it just doesn't seem like people have much experience with SAX2 1.1
extensions. I've never heard any feedback. If an XML decl callback ever
found it's way into SAX I'd prefer it would be on a new interface not some
extension of one."

An XML Decl/ Text Decl callback solves a whole lot of problems. Including
the repeated pull style checking of the version using getXMLVersion. There
would likely need to be BOM callback as well. Applications could handle
version stacks for multiple entities. The point where I disagree with
Michael is when he claims that the effective version/encoding, and not the
label should be passed. I think the actual labels (if any) should be passed.
If the parser is doing some transcoding or defaulting of the encoding or
version then perhaps it should report that instead. This would reduce
inconsistency in encoding detection.

PrologHandler anyone? Perhaps it is too late... I am not sure what Norm's
schedule is...

Cheers,
Jeff Rafter





 

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

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