To find out the release version of Xerces, execute the following: java org.apache.xerces.impl.Version.

Please refer to the Reporting bugs in bugzilla

In order to take advantage of the fact that this parser is very often used in conjunction with other XML technologies, such as XSLT processors, which also rely on standard API's like DOM and SAX, xerces.jar was split into two jarfiles:

• xml-apis.jar contains the DOM level 2, SAX 2.0 and the parsing component of JAXP 1.2 API's;
• xercesImpl.jar contains the implementation of these API's as well as the XNI API.

For backwards compatibility, we have retained the ability to generate xerces.jar. For instructions, see the installation documentation.

Partially to address this issue, we've recently begun to distribute compressed jarfiles instead of our traditionally uncompressed files. But if you still need a smaller jar, and don't need things like support for XML Schema or the WML/HTML DOM implementations that Xerces provides, then look at the dtdjars target in our buildfile.

You can turn validation on and off via methods available on the SAX2 XMLReader interface. While only the SAXParser implements the XMLReader interface, the methods required for turning on validation are available to both parser classes, DOM and SAX.
The code snippet below shows how to turn validation on -- assume that parser is an instance of either org.apache.xerces.parsers.SAXParser or org.apache.xerces.parsers.DOMParser.

parser.setFeature("http://xml.org/sax/features/validation", true);

• UTF-8
• UTF-16 Big Endian, UTF-16 Little Endian
• IBM-1208
• ISO Latin-1 (ISO-8859-1)
• ISO Latin-2 (ISO-8859-2) [Bosnian, Croatian, Czech, Hungarian, Polish, Romanian, Serbian (in Latin transcription), Serbocroatian, Slovak, Slovenian, Upper and Lower Sorbian]
• ISO Latin-3 (ISO-8859-3) [Maltese, Esperanto]
• ISO Latin-4 (ISO-8859-4)
• ISO Latin Cyrillic (ISO-8859-5)
• ISO Latin Arabic (ISO-8859-6)
• ISO Latin Greek (ISO-8859-7)
• ISO Latin Hebrew (ISO-8859-8)
• ISO Latin-5 (ISO-8859-9) [Turkish]
• ISO Latin-7 (ISO-8859-13)
• ISO Latin-9 (ISO-8859-15)
• Extended Unix Code, packed for Japanese (euc-jp, eucjis)
• Japanese Shift JIS (shift-jis)
• Chinese (big5)
• Chinese for PRC (mixed 1/2 byte) (gb2312)
• Japanese ISO-2022-JP (iso-2022-jp)
• Cyrillic (koi8-r)
• Extended Unix Code, packed for Korean (euc-kr)
• Russian Unix, Cyrillic (koi8-r)
• Windows Thai (cp874)
• Latin 1 Windows (cp1252) (and all other cp125? encodings recognized by IANA)
• cp858
• EBCDIC encodings:
• EBCDIC US (ebcdic-cp-us)
• EBCDIC Canada (ebcdic-cp-ca)
• EBCDIC Netherland (ebcdic-cp-nl)
• EBCDIC Denmark (ebcdic-cp-dk)
• EBCDIC Norway (ebcdic-cp-no)
• EBCDIC Finland (ebcdic-cp-fi)
• EBCDIC Sweden (ebcdic-cp-se)
• EBCDIC Italy (ebcdic-cp-it)
• EBCDIC Spain, Latin America (ebcdic-cp-es)
• EBCDIC Great Britain (ebcdic-cp-gb)
• EBCDIC France (ebcdic-cp-fr)
• EBCDIC Hebrew (ebcdic-cp-he)
• EBCDIC Switzerland (ebcdic-cp-ch)
• EBCDIC Roece (ebcdic-cp-roece)
• EBCDIC Yugoslavia (ebcdic-cp-yu)
• EBCDIC Iceland (ebcdic-cp-is)
• EBCDIC Urdu (ebcdic-cp-ar2)
• Latin 0 EBCDIC
• EBCDIC Arabic (ebcdic-cp-ar1)

UCS-4 is not yet supported, but it is hoped that support will be available soon.

The parser may not be able to access various external entities or schema documents (imported, included etc...) available on the Internet, such as the Schema for Schemas "http://www.w3.org/2001/XMLSchema.xsd" or the schema defining xml:base, xml:lang attributes etc... "http://www.w3.org/2001/xml.xsd" or any other external entity available on the Internet. There are various reasons one could experience such a problem.

One of the reasons could be that your proxy settings do not allow the parser to make URL connections through a proxy server. To solve this problem, before parsing a document, the application must set the two system properties: "http.proxyHost" and "http.proxyPort". Another reason could be due to strict firewall settings that do not allow any URL connection to be made to the outside web. The problem may also be caused by a server that is offline or inaccessible on the network, preventing documents hosted by the server from being accessed.

If you read the SAX documentation, you will find that SAX may deliver contiguous text as multiple calls to characters(), for reasons having to do with parser efficiency and input buffering. It is the programmer's responsibility to deal with that appropriately, e.g. by accumulating text until the next non-characters() event.

The answer to this question is that, yes there is a way, but it's not particularly beautiful. There is no way in SAX 2.0.0 or 2.0.1 to get hold of these pieces of information; the SAX Locator2 interface from the 1.1 extensions--still in Alpha at the time of writing--does provide methods to accomplish this, but since Xerces is required to support precisely SAX 2.0.0 by Sun TCK rules, we cannot ship this interface. However, we can still support the appropriate methods on the objects we provide to implement the SAX Locator interface. Therefore, assuming Locator is an instance of the SAX Locator interface that Xerces has passed back in a setDocumentLocator call, you can use a method like this to determine the encoding of the entity currently being parsed:

	import java.lang.reflect.Method; private String getEncoding(Locator locator) { String encoding = null; Method getEncoding = null; try { getEncoding = locator.getClass().getMethod("getEncoding", new Class[]{}); if(getEncoding != null) { encoding = (String)getEncoding.invoke(locator, null); } } catch (Exception e) { // either this locator object doesn't have this // method, or we're on an old JDK } return encoding; }

This code has the advantage that it will compile on JDK 1.1.8, though it will only produce non-null results on 1.2.x JDK's and later. Substituting getXMLVersion for getEncoding will enable you to determine the version of XML to which the instance document conforms.