Hi Andy and all,
Thanks for the feedback!
> 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?)
Folks want to get access to encoding information by some (more or less)
standard SAX means; this is clearly the best we can do for them.
getVersion() is similar; by the same argument that's leading us to add
getEncoding to XMLLocator, I wonder whether we shouldn't add getVersion()
as well?
> I don't like option 1 because it's a breaking API change.
Yeah, I hear you. I wonder how many XMLDTDHandler implementations there
are out there though?
>>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.
Why would we have done that?
>> slightly. Finally, I'd submit that it's trivial to implement the SAX
> I don't think so.
Trust me; it is. Though you're right in pointing out the XMLLocator
addition is even more trivial. :)
While I'd still claim that this is ugly, the consensus seems to be that
adding a method to XMLLocator is the right way to go and I'm not of a mind
to contest the point. So I'll make the appropriate change in the next
couple of days unless I hear arguments to the contrary. If anyone wants
getVersion() added, let me know and I can do that in passing.
Now if we can just get some feedback on Elena's proposal, we'll be all set!
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Andy Clark |
| | <[EMAIL PROTECTED]|
| | > |
| | |
| | 03/20/2003 07:53 |
| | PM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| 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]
