Skip to content

jcabi/jcabi-xml

Repository files navigation

Simple XML Parsing and Traversing, in Java

EO principles respected here DevOps By Rultor.com

mvn PDD status codecov Javadoc Maven Central

More details are here: xml.jcabi.com. Also, read this blog post: Java XML Parsing Made Easy.

It's a simple wrapper around DOM that makes XML parsing and printing easy and simple, for example:

XML xml = new XMLDocument(
  "<cart><item id="4">Coffee to go</item></cart>"
);
XML item = xml.nodes("//item[@id=4]").get(0);
String name = item.xpath("text()").get(0);
System.out.println(xml.toString());

Architecture

The library defines three core interfaces: XML, XSL, and Sources. All concrete classes implement one of these interfaces, and callers program against the interfaces exclusively. This differs from typical Java XML code that couples callers directly to JAXP types such as Document, Transformer, or SAXParser. New contributors add implementations of these interfaces, not subclasses of existing concrete types.

All implementations are immutable and thread-safe. Operations that would alter state — registerNs() on XML and with() on XSL — return new objects rather than modifying existing ones. The W3C DOM Document is mutable by design and requires external synchronization under concurrent access; this library avoids that structurally.

Two implementations of XML exist for different XPath needs. XMLDocument wraps the JDK's JAXP processor, which supports XPath 1.0 and is thread-safe. SaxonDocument uses Saxon-HE and supports XPath 2.0 and above, but is not thread-safe. Callers who need typed comparisons, sequences, or advanced fn: functions must use SaxonDocument; others should prefer XMLDocument.

XSD validation is enforced through the StrictXML decorator, which wraps any XML and throws during construction if the document is invalid. Libraries such as dom4j or plain JAXP leave validation as an explicit separate call; here it becomes a structural guarantee at object-creation time.

XSLT stylesheets are composed with XSLChain, which accepts an ordered list of XSL instances and applies each in sequence, feeding the output of one as the input to the next. Without this class, callers must manage intermediate XML objects between transformation steps manually.

XSLDocument uses Saxon as its XSLT engine instead of the JDK's built-in transformer. Saxon supports XSLT 2.0 and XSLT 3.0; the JDK bundled transformer supports only XSLT 1.0. Saxon is therefore a required runtime dependency despite the library's narrow scope.

XSD schemas and XSLT imports (xsl:include, xsl:import) are resolved from the JVM classpath via ClasspathResolver and ClasspathSources. This is necessary when schemas and stylesheets are packaged inside JAR archives, where absolute filesystem paths are unavailable at runtime. For external files, FileSources is the alternative.

How to contribute?

Fork the repository, make changes, submit a pull request. We promise to review your changes same day and apply to the master branch, if they look correct.

Please run Maven build before submitting a pull request:

mvn clean install -Pqulice

About

Java XML Parsing, Transforming, Printing, and Validating

Topics

Resources

License

Stars

Watchers

Forks

Contributors