serverJava version and a JavaScript version that can run in a web browser.
Step | Supported | Remarks |
---|---|---|
p:directory-list | No | |
p:http-request | Yes | Only simple GET requests |
p:load | Yes | DTD validation not supported |
p:unescape-markup | No | |
p:xinclude | Yes | XPointer not supported |
p:xslt | Yes | Only XSLT 1.0 supported (browser-native) |
p:exec | No | |
p:hash | Yes | CRC32 not supported |
p:validate-with-relax-ng | No | |
p:validate-with-xml-schema | No | |
p:xquery | No | |
p:xsl-formatter | No |
Category | Percent passed |
---|---|
Required | 81.85% |
Optional | 45.45% |
Serialization | 68.00% |
Extension | 100.00% |
productlist
service and to display the results in a dynamically constructed HTML table. This would typically involve iterating over the result elements in the returned XML document and creating a table row for each result.AJAX request - process response - update host pagepattern to XProc. The XProc pipeline starts with an HTTP request to the
productlist
service. The XML document returned by the service is then processed by creating an HTML table row for each product
element in the document. After that, all table rows are inserted into a table wrapper which is then injected into the host page. In the example, a custom extension is used that makes it possible to address elements of the host page using their ID. In our case, the p:store
step effectively replaces the element with the ID search-results
by the generated HTML table.heavierXProc approach where a simpler and more efficient alternative exists? We argue there is, although it depends strongly on the particular use case. XProc is not a hammer for everything: it is first and foremost an XML processing language, and it should be used as such. Client-side XProc therefore makes most sense in user interfaces that are XML-driven, consume or produce XML data, or require non-trivial XML processing. In other situations, other approaches may be more appropriate.
dita:topic-to-xhtml
step will most likely perform rather complex XML processing: from resolving the various DITA link types to content filtering to applying an XSLT stylesheet. Or... maybe not: the black-box nature of XProc steps provides great freedom by allowing different implementations of the same step interface- which is not only convenient when writing (and testing) the pipelines, but it also makes it possible to adapt the pipelines to the needs of a particular user audience or to different browser environments. Thus, the pipeline below can, for instance, do full-blown client-side DITA processing in web browsers that are known to be fast (or compliant) enough, and delegate to the server-side in other cases.
circuit breaker checkprocedure. The pipeline has two options, an aircraft model number and its variant. Depending on a specific combination of the model and the variant, the maintenance mechanic is presented with a dialog (an XForm) that allows him to enter information about the state of the circuit breaker. When the mechanic submits the dialog, the pipeline displays a message that tells the mechanic to switch on the breaker if it was in the OFF position.
nativeJava API of Calumet can be used, but for the case of traditional HTML/JavaScript applications, a JavaScript interface will be necessary. An additional option that we are considering is to support embedding XProc pipelines in the HTML
script
element; however, that direction still needs to be researched.