GlassFish - World's first Java EE 7 Application Server


JAXP.next Community Discussion Wiki

This page has been created as a place to share ideas about the next version of JAXP, i.e. JAXP.next. All ideas are welcome, but we are mostly interested in feedback about:

  1. Improving ease of use
  2. Supporting XPath 2.0 and XSLT 2.0.

Please use the section "Community Comments" at the bottom of this page to add your comments. The following two sections summarize some of the discussion thus far. For a discussion on StAX.next features, please refer to StaxNextDiscussion.

Improving Ease of Use

When it comes to ease of use, most people agree that JAXP is not really easy to use. Tasks that should take one or two lines often take ten or twelve lines instead. There are a number of reasons for this, including: JAXP factories, checked exceptions and parameter wrappers, all of which must be dealt with to write even the simplest of tasks.

Some of these issues have already been discussed in this blog entry. The basic idea proposed in the blog is to create a facade on top of the existing API to handle the majority of the common use cases. As you can see from the comments in that blog entry, reactions were mixed but many --at the very least showing that people do care about API proposals such as this.

An alternative to simply introducing an API facade may be the design of a radically different API in which Sources, Results and their flavors (SAX, DOM, StAX) are completely hidden from the programmer. This API can also add support for chaining borrowing some ideas from the XProc Language. For example, validating an XML document and then applying a transform to it could be written as:

<pre>
<code>
Xml xsl = new Xml("some-system-id-1");
Xml xml = new Xml("some-system-id-2");
Xml xsd = new Xml("some-system-id-3");

new XmlStylesheet(xsl)
.transform(new XmlSchema(xsd).validate(xml))
.to(System.out);
</code>
</pre>

using the following API classes:

<pre>
<code>
/**

  • The class Xml represents an XML document or XML
  • fragment that can be parsed from and serialized to
  • various representations.
    */
    class Xml
    Unknown macro: { public Xml(File f) { }


    public Xml(InputStream is) { }
    public Xml(String systemId) { }
    public Xml(char[] xmlLiteral) { }
    public Xml(Node n) { }
    public Xml(Source source) { }
    public void to(File f) { }
    public void to(String systemId) { }
    public void to(OutputStream is) { }
    public void to(StringBuffer xmlLiteral) { }
    public void to(Node n) { }
    public void to(Result result) { }
    }
    /**

  • This class can be used to apply XSLT stylesheets.
    */
    class XmlStylesheet
    Unknown macro: { public XmlStylesheet(Xml d) { }


    public Xml transform(Xml source) { }
    }
    /**

  • This class can be used to validate Xml instances.
  • The result of the validation is a, possibly extended,
  • Xml.
    */
    class XmlSchema
    Unknown macro: { public XmlSchema(Xml d) { }


    public Xml validate(Xml source) { }
    }
    /**

  • This class can be used to select parts of an
  • Xml using XPath. The result of a selection
  • is also an Xml instance.
    */
    class XmlXpath
    Unknown macro: { public XmlXpath(String expression) { }


    public Xml evaluate(Xml source) { }
    }
    </code>
    </pre>

Actually, the need for a radically different API often arise while discussing support the new XPath 2.0 data model, so the two topics mentioned at beginning of this page are clearly interrelated. Contrary to how the XPath 1.0 data model is supported in JAXP today, many believe that exposing the XPath 2.0 data model is required to take advantage of the new 2.0 standards. Should the decision be made to go in this direction, the goals to simplify the API and to support the new 2.0 standards will likely converge.

XPath 2.0 and XSLT 2.0 Standards

Many of you may know that the XPath 2.0 and XSLT 2.0 recommendations are final since late last January. Since JAXP.next is possibly going into Dolphin (JDK 7.0), which is very tentatively schedule for late 2008, there seems to be plenty of time to incorporate these new technologies into JAXP and the Java platform.

Naturally, XPath 2.0 and XSLT 2.0 are not yet as popular as their 1.0 counterparts, but the status quo is likely to change in the next 2 to 3 years. As discussed in the previous section, supporting these technologies may require significant additions to the JAXP API if the current approach of hiding the XPath data model is deemed insufficient. So the question of if these technologies should be part of JAXP.next very rapidly becomes a question of how these technologies should be supported.

Community Comments

  • __Santiago Pericas-Geertsen (4/20/2007):

Created this page!

  • __JirkaKosek (4/26/2007):

What I would like to see:

    • XPath 2.0 and XSLT 2.0 support
    • Integrated support for RELAX NG, ISO Schematron and NVDL
    • XML resolver smoothly integrated into Java platform
    • Ability to access PSVI in an usable way – not just TypeInfo object, but nodes in DOM should be easily accessible as Java datatypes
  • __Norman Walsh (23 May 2007):
    • The XPath API should allow the caller to specify the context position and the context size.
  • __Santiago Pericas-Geertsen (5/24/2007):
    • Transformer.setParameter() should be further specified. It states that an arbitrary Java object can be passed but in reality XSLT processors can only convert a few types. At the very least it should something about this being implementation depedent.
  • __Fabian Ritzmann (2007-08-29):
    • We would like to see support for xml:base in StAX and the underlying parsers. Currently our application is forced to track the base URI for every element that uses xml:base and all its child elements. It would be much more convenient if we could retrieve the applicable base URI with a simple call to e.g. javax.xml.stream.Location.getBaseUri().
  • __Sean Mullan (2007-09-21):
    • +1 to the xml:base support. Also, support for xml:id so that you do not need to have a DTD or schema to identify elements with ID attributes, or require the application to register them. Both of these features would be helpful for supporting XML Signature/Encryption and XML C14N 1.1. Another useful addition would be an XML attribute context (similar to the javax.xml.NamespaceContext) that would allow you to retrieve the values of inheritable xml attributes (like xml:space, xml:lang) that are in scope for an element.
  • __Santiago Pericas-Geertsen (2007-10-10):
    • The spec needs to be clear on what is expected from classes that consume DOMSource(node). How much of the ancestors and context from 'node' should be inspected? For XSLT: Should all of the ancestors be considered? For Schema processing: Should all the parent namespaces be looked at?
  • __<Your Name> (<date>):

<Your comment>