Hi Neeraj,
Good to see you're back with us. Hope you enjoyed your long weekend (and
now I'm curious: what does Diwali celebrate? Sorry for the ignorance. :)
)
To the matter at hand: one thing's for sure: I don't think we can let
2.2.1 come out before this is resolved. I know Xalan wants to get back
into sync with our JAXP code, so it's pretty important we get our house
back in order (see the recent discussions on general@ for further
evidence).
I don't think there's been any bugs reported against the code you dropped
in for 2.2.0. But Sandy switched us over to his contribution shortly after
2.2.0, and I don't think we've seen any bugs in that direction either. So,
it's probably reasonable to assume the correctness is about equal; that's
why I'm leaning towards just sticking with the way we have things at this
moment (i.e., use Sandy's code). That isn't a knock against the stuff you
put down, of course; we certainly needed a quick bugfix at the time, and it
works fine as far as it goes. It's just that what Sandy's put together is
a bit more complete, and there doesn't appear to be any evidence that it's
any less correct.
Anyway, what do you think about Monday as a 2.2.1 release date?
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Neeraj Bajaj |
| | <Neeraj.Bajaj@Sun|
| | .COM> |
| | |
| | 11/07/2002 09:04 |
| | AM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: file-path-to-uri algorithm in JAXP code
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Hi Sandy,
Sorry for late response on this. It was a long weekend here in
India on
occasion of Diwali.
> One thing was missing from Neeraj's fix: it doesn't support non-ASCII
> characters. This is why I committed another fix for the same problem,
using
> a different approach (borrowed from other parts of Xerces), with the
> support of non-ASCII characters.
>
> As we all know, JAXP is not our (Xerces') code, so it's better if it
lives
> in a common place (xml-commons would be a good candidate) so that other
> projects can have access to this fix. Before moving on, we'll need to
pick
> one of the two solutions.
>
> I don't know which one is more appropriate, so I would like to ask for
your
> opinions (especially Neeraj's) on:
> 1. How long and how much effort does it take to update Neeraj's approach
to
> support non-ASCII characters?
Right, As of now it doesn't handle non-ascii character. Since Xerces2.2
release
was due, and there were lots of bugs filed in bugzilla for this problem. My
take
on this was that it should be fixed before the release, and fixing for
ASCII
characters serves the need for most of the people. I didn't have time to
upgrade
it to handle non-ascii character. I would have a look into it and find out
how
much effort it is. Would it be fine for you, if i get back on this after
2-3
days, say by Friday or Monday ?
> 2. In terms of correctness and completeness, in which approach do people
> feel more confident?
I haven't had a look at your code, so I am not sure which one is better :-)
I am
really not too concerned about performance in this case since its just one
time
operation, my take on this it should work correctly and handle all the
cases.
I tested my code before commiting it in cvs. I think it has fixed many bugs
as
seen from the user responses. Is there any bug filed for the similar
problem
after the fix was put in cvs ?
Neeraj
---------------------------------------------------------------------
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]
