Hi Edwin,

>Well, I was hoping to get the fixes for javax.xml.parsers.* code into
the next Xerces2 release, but I haven't had time to work on it.

How about the next Xerces1 release--which was the subject of this message?

>I think the fix should be to copy the code from the xml-commons repository
which has the most current version and fixes bugs that are in the
xml-xerces
module.

I thought of doing this for you, so I finally checked out the xml-commons
module.  The most interesting discovery this led me to is that there are
two cases (in SAXParserFactory and DocumentBuilderFactory) where
org.apache.crimson is used as the "fallback implementation".  This is no
doubt appropriate for crimson, but surely we'd want to modify this for
xerces...  So while I agree that the best solution would be to have one
source repository for the jaxp classes, I'm not sure how both xerces and
crimson can share one repository when they would both appear to need slight
modifications to some of the files.

I also noticed that the jaxp files in xml-commons appear to have a
different origin than the files we have.  That is to say the files in
xml-commons don't seem to be patched versions of our files, they appear to
have  come from somewhere else.  While this is fine, I think it points out
that if/when we do move to using an implementation based on what's in the
xml-commons module, we'll have to make sure we do lots of testing.

So I wonder whether it's worth using the code from xml-commons in xerces1,
since we really only want to fix small bugs there now and using a wholly
different codebase puts us at risk of regressing.

Thoughts?

Cheers,
Neil


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to