I have to agree with Andy on this. Option 4 solves the pb without breaking backward compatibility and only requires an extra call for the few (as shown by the lack of interest in this) who care. -- Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
> -----Original Message----- > From: Andy Clark [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 20, 2003 4:53 PM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL: XNI CHANGE]: determining the encoding of an > external subset via XNI > > > Neil Graham wrote: > > 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, > something > > like: > > > >> public void externalSubsetEncoding(String encoding) > > Ugh. I *really* don't like this. > > >>3. We could use the Augmentations parameter of the startExternalSubset > > callback. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
