[This local archive copy is from the official and canonical URL, http://developer.java.sun.com/developer/earlyAccess/xml/relnotes.html, 1998-12-17; please refer to the canonical source document if possible.]

Java Project X
Release Notes

Version: Early Access 2

This document contains notes that may help you use this library more effectively.

Please feel free to send problem reports, questions, and other feedback to the feedback alias, <xml-feedback@java.sun.com>. With respect to new feature requests, please keep in mind that we want to see packages built on top of this core for most features. The core API is intended to facilitate such a layered architecture for value-added products that leverage XML.

Changes since EA 1

DOM support conforms to the W3C recommendation, not the proposed recommendation. Changes include renaming the "Attribute" interface to "Attr" to fix a conflict with a reserved word in OMG-IDL.
DOM space and time performance was improved.
Most classes in the com.sun.xml.tree package are now private. There are new interfaces. Some of the APIs have changed.
In the com.sun.xml.parser package, the static methods for checking character and name types have been moved out of the parser class for clarity. New interfaces have been defined, for better DOM support.
There is now an ElementFactory interface which supports namespace-aware creation of elements. You can have two element types, distinguished only by namespace URIs, which instantiate as different XML Beans. SimpleElementFactory provides a table-driven implementation of this functionality.
Minor bugfixes have been implemented, including implementing some missing DOM functionality.
New examples have been provided, including one using XML with HTTP for messaging.

Conformance

The parsers conform to the W3C's XML 1.0 recommendation.
The parse tree supports the XML (core) part of W3C's DOM Level 1 recommendation.
In combination, the two also support the current W3C XML Namespaces proposed recommendation.
The parser supports the SAX 1.0 API.
The entity resolution used within the parser normally conforms to the IETF's RFC 2376 registration for XML-related MIME content types. This can be overridden as required. (See below; overriding may be needed since many web servers do not conform to that specification, and report incorrect character set encoding information.)

Parser

There are two separate parsers, sharing almost all the same code. The validating parser is slightly slower since it performs additional error checking.
Because SAX specifies the default error handling to be that validation errors are ignored, the validating parser normally accepts invalid documents (when they are are well formed). To reject such documents, configure an implementation of ErrorHandler with a error() method which throws its argument.
Both parsers normally read all external entities, and so their behavior is all but completely defined by the XML specification. An exception is that for valid standalone documents you may enable a "fast standalone" mode, which skips external parts of the DTD if validation is not being performed.
Please let us know about any diagnostics produced by the parser which are misleading or confusing.
If you are working with text encodings other than UTF-8 and UTF-16, you should put a text declaration at the very beginning of all your XML documents (including DTDs). If you don't do this, the parser will not be able to determine the encoding being used, and will probably be unable to parse your document. A text declaration like <?xml version='1.0' encoding='euc-jp'?> says that the document uses the "euc-jp" encoding.
The parser currently reports warnings, rather than errors, in cases where the declared and actual text encodings don't match. It gives those same warnings in the common case where the encoding name used internally to Java is not the one used in the document. If the declared encoding is truly an error, you'll usually see other errors (not warnings) being reported by the parser.
Currently, many web servers report incorrect MIME types for XML documents using non-ASCII encodings. Such situations are indicated through the warning noted above, and are often followed by other errors (not warnings). You may work around such web server problems by disabling MIME typing support by using a properly configured com.sun.xml.parser.Resolver, disabling the use of MIME typing information.
The parser currently does not report an error for content models which are not deterministic. Accordingly it may not behave well when given data which matches an "ambiguous" content model such as ((a,b)|(a,c)). DTDs with such models are in error, and must be restructured to be unambiguous. (In the example, (a,(b|c)) is an equivalent legal content model.)

Object Model

Conforming to the XML specification, the parser reports all whitespace to the DOM even if it's meaningless. Many applications do not want to see such whitespace. You can remove it by invoking the ElementNode.normalize method, which merges adjacent text nodes and also canonicalizes adjacent whitespace into a single space (unless the xml:space="preserve" attribute prevents that).
Currently, attribute nodes may not have children. Access their values as strings, instead of enumerating children.
Currently, when documents are cloned the clone will not have a clone of the associated ElementFactory or DocumentType.
To get full XML namespace support, you must use one of the Sun XML parsers and pass it to the XmlDocumentBuilder.setParser method. Otherwise names with colons aren't constrained as required during parsing, so various document errors will be ignored.
The in-memory representation of text nodes has not been tuned to be efficient with respect to space utilization.
We're seeking feedback on "XML Beans". What sorts of things have you successfully used them for? What sorts of things did you have trouble with?

Other Issues