For some reason, this issue still doesn't seem to be generating much feedback; with the exception of Neeraj, everyone's been silent. So I think it's time to move towards a concrete proposal.
I've been quiet on this issue for a few reasons: 1) I've been busy with other things; and 2) the SAX2 extensions that are the cause of this discussion are only in the beta stage at the moment. (Or were there other reasons for this that I'm forgetting?)
After thinking about the 4 options I originally posted, I've concluded that option 1 seems best. It's completely consistent with what we've done everywhere else in XNI viz. encodings, and makes the startExternal subset call symmetric with the startDocument call. So to review, I'm proposing that we change
I don't like option 1 because it's a breaking API change. Anything that changes an existing method's prototype or removes an existing method is destructive and causes a lot of distress for application writers using XNI.
2. We could add a new callback to the XMLDTDHandler interface, somethinglike:
public void externalSubsetEncoding(String encoding)
Ugh. I *really* don't like this.
3. We could use the Augmentations parameter of the startExternalSubsetcallback.
Works but not desirable.
4. We could amend the XMLLocator interface by adding a method like public String getEncoding()
I don't mind this addition because I figure that we'll probably end up adding something like this anyway. And this change does not break existing applications unless those applications implement their own XMLLocator class. And even then, adding this method in their code still allows it to be used by people using older versions of Xerces.
from the XMLLocator. We'd also have to make sure to update the locator implementation at every entity change, which could impact performance slightly. Finally, I'd submit that it's trivial to implement the SAX
I don't think so.
The XMLEntityManager.ScannedEntity class already keeps track of the encoding of the entity. So there is no "updating" required as entities are popped off of the entity manager's scanned-entity stack.
locator2 functionality without this change. If we're going to do something really ugly in XNI like duplicate means for accessing a particular piece of information, I really hope we'd require some solid use-case that simply couldn't be met with the existing framework.
Before we make changes to XNI, I'd like to see more cases than just the SAX extensions (1.1 beta1) to justify it.
It's true that we've declared XNI to be "golden", but we always said it could still change if we found a sufficiently significant problem. I think this problem is sufficiently significant.
I'm still unconvinced that it's significant enough to break the API.
-- Andy Clark * [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
