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

[Neil Delima]

It may be time to start thinking about integrating the contributed JAXP 1.3 implementation and while doing so, addressing issues like the ones below that we come across.  I'd be willing to look into the XInclude implementation support required by JAXP 1.3.

Thanks,
Neil.


Michael Glavassevich/Toronto/[EMAIL PROTECTED] wrote on 04/20/2005 11:39:59 AM:

> 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?
>
> 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?
>
> 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.
>
> 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?
>
> I have some other more minor concerns that I haven't listed here. These
> might merit discussion once these more significant issues have been
> resolved.
>
> Thanks.
>
> [1] http://xml.apache.org/xerces2-j/faq-xni.html#faq-2
> [2] http://xml.apache.org/xerces2-j/faq-xni.html#faq-3
> [3] http://www.w3.org/Submission/2004/SUBM-xmlschema-api-20040309/
> [4]
> http://marc.theaimsgroup.com/?l=xerces-j-user&w=2&r=1&s=Dropping+JDK+1.1&q=b
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: [EMAIL PROTECTED]
> E-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>