I'll respond to the other points later, but for now I'll just say thanks for the feedback, and here are two quick responses.
> From: "Glenn Marcy" <[EMAIL PROTECTED]> > Issue 2a: That one was reverted in r2pre3. The spec was updated on the understanding that it reflected how parsers actually worked, but it turned out that wasn't correct. Fixed. > Issue 3a: > > The phrase "ignoring ... any encoding specified in the InputSource." is > not relevant. This gives the misimpression that the encoding should > not be set for the InputSource when a character stream, i.e. Reader, > is used. This is in fact the correct way for the application to pass > the "actualEncoding" property to the parser, since the application might > be passing a byte stream wrapped by an InputStreamReader to the parser > as a character stream and the actual encoding is otherwise not available. I don't know what you mean by an "actualEncoding" property, it's not part of SAX or XML. But if you mean the infoset property to be exposed by http://www.saxproject.org/apidoc/org/xml/sax/ext/Locator2.html#getEncoding() (current "Extensions 1.1" API proposal), then I think I see what you're saying. I'll look at how to reword that. Parsers that report that infoset property would clearly benefit from a well specified way to pass it through the InputSource. (Probably just strike that last clause: "... as well as any encoding specified in the InputSource", and update Locator2 to say how that particular entity information is passed through an InputSource.) The issue was that some folk were thinking the parser should compare the InputSource encoding property with what the xml/text declaration says, and report an error given a mismatch. That's clearly not the way to handle an external authoritative encoding description ("text/xml;charset=iso-8859-15" in MIME, for example). - Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
