Re: Comments on the Xerces portions on the JAXP 1.3 donation

Michael Glavassevich wrote:

>Hello everyone,
>
>During the past week I spent some time having a look over the Xerces 
>portions of the JAXP 1.3 donation to get a feel of what work would be 
>required to integrate this code back into Xerces. In doing so I found a 
>number of issues which should probably be addressed before integration 
>work begins on the main line.
>
>In the Xerces code there are a couple instances where JAXP identity 
>transformers are being used for supporting DOM input into the validation 
>API. This creates a dependency on an XSLT processor (such as Xalan), one 
>that wasn't there before, meaning users would have to carry even more 
>megabyte sized jars in their classpath.  To allow users to continue using 
>Xerces stand-alone, these dependencies would need to be replaced with some 
>equivalent.  I believe stand-alone usage of Xerces is common and should 
>still be supported in Xerces 2.7.0. Does anyone more familiar with the 
>code know how difficult cutting these dependencies would be?
>
>  
>
re: standalone Xerces usage:

I like to re-use the code because It is the best bet to avoid fixing the 
same bug at two places and
helps in easy maintenance. I also understand that community is used to 
standalone Xerces and this is
a very valid point. So i am not sure what would be the right solution. 
One solution could be to
prominently document the dependency of DOM input on an XSLT processor.

re: cutting these dependencies

This should be possible because validator works on SAX stream. DOM --> 
SAX converter is required.
Kohsuke, Do you want to add here ?

>I also noticed that the JAXP SAXParser and DocumentBuilder now fix the 
>XMLParserConfiguration to a new configuration called JAXPConfiguration. 
>Previously it was possible to override [1] the parser configuration, a 
>rather powerful feature that's been supported throughout Xerces2 releases. 
>In addition to the many parser configurations [2] which ship with Xerces 
>other applications such as NekoHTML provide parser configurations which 
>can be used to override the default parser configuration. It isn't obvious 
>to me why the parser configuration would need to be fixed. Was there a 
>compelling reason for doing this?
>
>  
>
IIRC, this was something to do with changes related to newly introduced
function reset() in SAXParser & DocumentBuilder. reset() sets the instance
back to factory settings. A parser configuration can't reset() itself. 
Say if a
configuration contains n components there isn't any function which allows
all components to be reset. Neither it has any function to know what all
components are part of it.

I think there might be other solution to this problem, may be we just need
to put more thought on this.

>In addition there have been modifications made to both XNI and the XML 
>Schema API. Specifically a constructor and a method were added to 
>org.apache.xerces.xni.parser.XMLInputSource which handle 
>javax.xml.transform.Source objects. org.apache.xerces.xs.XSTypeDefinition 
>was modified so that it also extends org.w3c.dom.TypeInfo. These changes 
>would make XNI dependent on JAXP and the XML Schema API on DOM Level 3. 
>Though minor changes have been made on occasion, XNI is more or less 
>final. The XML Schema API is a published API [3] which both Xerces-J and 
>Xerces-C++ support. Though it may be possible to make modifications to 
>both of these APIs in Xerces, it seems like the changes were made for 
>convenience and could be replaced without modifying XNI or the XML Schema 
>API.
>  
>
Kohsuke do you have any opinion on this ?

>When trying to use JDK 1.3, I ran into several compile and runtime 
>dependencies on JDK 1.4 in the API and Xerces and Xalan code (which I 
>needed for the validation API). These are summarized below:
>  
>
>Location
>javax.xml.datatype.DatatypeConfigurationException -- Relies on 
>Exception(String, Throwable), Exception(Throwable) constructors added in 
>JDK 1.4
>javax.xml.transform.stream.StreamSource.setSystemId(File) -- Requires 
>File.toURI() at compile time, recovers from the NoSuchMethodError if it 
>isn't there.
>
>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -- Boolean.valueOf()
>org.apache.xml.serialize.DOMSerializerImpl -- import of java.net.URI class
>org.apache.xml.serialize.EncodingInfo -- java.nio.*
>
>org.apache.xalan.xsltc.trax.TransformerImpl -- Use of the java.net.URI 
>class
>org.apache.xpath.jaxp.XPathImpl -- the Error(Throwable) constructor
>
>Historically Xerces has been conservative about its JDK requirements. 
>Support for JDK 1.1 was only dropped last year in Xerces 2.6.2 (which now 
>requires JDK 1.2) after discussing it with the community [4]. At the time 
>there were still users depending on JDK 1.1 support. There are still many 
>users which depend on pre-JDK 1.4 environments. To keep the code 
>accessible to such users, I feel that the dependencies on JDK 1.4 should 
>be removed. What do other people think?
>
>  
>

JAXP APIs are compilable on JDK 1.4 and runnable on JDK 1.3
I think same should be maintained for implementation as well.


-Neeraj