Hi Neil, > >Ideally, We should first take user permission before we make any > >attempt to parse such (other than UTF-8, UTF-16) documents to make sure > that > >application/user is aware that by doing so it is tying itself to processor > based > >feature and may not obtain the desired result when shifting to other > processor. > > It seems to me that this is the right direction to move in, rather than the > one you're actually proposing. :-) >The only trouble with it is that it > would represent a significant break with backward compatibility--even > generating a warning makes a new version of the parser instantly > backward-incompatible with old versions for any application that detects > warnings. So unfortunately I don't think we can go down this road either.
That was my perception too :-) I used the word "Ideally" ;) Right. It would severly affect the wide usability of Xerces2. Practically this wont be good for many applications. I think XML spec. seems to have compromise between the document interoperability and the practical limitation of a parser to read all kinds of encodings known in this world. > But we'd be completely throwing our hands up in despair at the problem if > we allowed Java encoding names by default as well as IANA names. To my > mind, the current situation is as good a compromise as we're likely to > find. > > I am curious though as to why setting the > http://apache.org/xml/features/allow-java-encodings feature is such a > tremendous burden? I would try to consolidate my thoughts in other mail, it seemed to me that XML spec encourages the behavior of parser to be able to process other encodings. So i was interested in knowing what the community thinks or in the best interest of it. But i dont want to push this thread too far :-) Neeraj --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
