Referring to XML Types: Consider two code fragments of pure Java code: the first code fragment is written in a reflective style, where the only type used is java.lang.Object; the other code fragment is written as Java programs normally are, that is, by referring to classes and interfaces directly. Clearly, the second style is less tedious to write and easier to maintain. For example, errors in the reflective style (for example, if a class does not contain a particular field) will not be reported until runtime. If a class definition (or XML Schema in the XML case) is changed, a programmer has to search an entire program to find the portions that are affected. In the second case, where type references are explicit in the program, a compiler would throw errors at improper accesses of the program. The ability to specify the types of XML data in an XJ program allows XML processing programs to be easier to write, more readable, and more maintainable.

XPath Expressions: XPath is a declarative language that allows a programmer to write concise expressions that retrieve information from XML data. Runtime APIs, such as DOM, are moving towards allowing programmers to write XPath expressions rather than writing explicit tree traversal code (painful). There are two problems with the runtime approach. First, an XPath is passed to the runtime library as a string. Simple errors in XPath, such as syntax errors, will not be caught until runtime. More complex errors, such as misspelling the name of an element in the document, cannot be detected by the runtime API : the XPath evaluation will return no results. The second problem of runtime APIs is performance. The runtime library must parse and evaluate an XPath expression at runtime. There is no opportunity for a runtime library to analyze a program and structure the query evaluations in an optimal manner.

XJ solves these problems by introducing knowledge of XPath expressions into the language. The compiler can verify that the evaluation of an XPath on an element is appropriate with respect to the XML Schema type of the element (detecting many errors at compile-time). Furthermore, it can generate optimized code for evaluation of XPath expressions (not in the current prototype, but coming soon).

Construction of XML: With runtime libraries, such as DOM, a programmer must construct XML in a step-by-step manner, constructing each node and inserting it into the tree appropriately. In constructing elements and attributes, a programmer passes strings to the runtime library; misspellings and other errors are not caught until runtime (if the constructed document is validated). XJ, on the other hand, allows programmers to write XML inline. Programmers can cut-and-paste the XML they wish to generate and include it in the program. The compiler will verify that the constructed XML is valid with respect to the declared types (and can optimize construction as well).

There are many languages that integrate XML as a first-class construct into a programming language, the granddaddy of them all being XDuce. The aspect that sets XJ apart from these is its consistency with the open standards of XML 1.0, XPath, Namespaces, and XML Schema. Many of the details of our design were driven by the goal of ensuring that XML processing in XJ behaves "as expected"; for example, an XPath evaluation on an XML document in XJ gives the same results as that of an XSLT or XQuery processor.

Another aspect of XJ that is unique (not available in the current prototype, but coming soon) is the ability to update XML values in-place.

Besides, it'll make us happy!