Mailing-List: contact commons-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Date: Thu, 21 Apr 2005 11:40:52 +0530
From: Neeraj Bajaj <Neeraj.Bajaj@Sun.COM>
Subject: Re: Comments on the Xerces portions on the JAXP 1.3 donation
In-reply-to: 
 <OFD182370D.43F45AAB-ON85256FE9.005355F8-85256FE9.00560DAA@ca.ibm.com>
To: j-dev@xerces.apache.org
Cc: commons-dev@xml.apache.org
Reply-to: Neeraj.Bajaj@Sun.COM
Message-id: <426743EC.2080007@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
References: 
 <OFD182370D.43F45AAB-ON85256FE9.005355F8-85256FE9.00560DAA@ca.ibm.com>

Thanks Michael for looking into this. I will answer your queries later 
in  a day.
There are some which i can't answer and i will cc to the appropriate person
to keep the discussion going.

- Neeraj

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?
>
>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: mrglavas@ca.ibm.com
>E-mail: mrglavas@apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
>For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>  
>