Inasmuch as it’s something that people ask for, I demoed in the DemoJam at XML Prague that I’d been working on a Relax NG schema and Schematron rules for validating XSL-FO. Most of both the schema and the Schematron were generated directly from the XML source for the XSL 1.1 Recommendation. Additionally, the Schematron used a parser written in XSLT for handling the XSL-FO expression language, so the Schematron could evaluate property values rather than just matching on property value strings.

There was also an oXygen add-on framework in the works, and, naturally, the schema and Schematron also covered Antenna House extensions.

If you look at the screenshot, you’ll see:

Schematron error for the interrelated <axf:document-info> elements.

No error for ‘column-count="-1 - -2"‘ because the value evaluates as a positive integer.

oXygen ‘tooltip’ information for fo:block extracted from the XML for the XSL 1.1 Recommendation.

The ‘neutral’ and ‘out-of-line’ formatting objects, as well as the XSL 1.1 ‘point’ fo:change-bar-begin and fo:change-bar-end formatting objects that can appear anywhere inside a fo:flow, are available where they are allowed.

Inasmuch as, when using the Oxygen XSLT debugger, I often navigate straight to the files that I want to run or navigate to a line and set a breakpoint and then want to just run it, but I used to also often just rerun the previous set of files I’d been debugging because the debugger’s file selectors weren’t keeping up with my gyrations in the editor panels.

Enter the “Link with Editor” button. Clicking once on the button beside the file selectors once you’ve got the files that you want to run visible in the editor panels will update the selectors to reflect the currently selected panels. A useful button, indeed.

(You probably want to click it again straight away to turn the feature off again, just so the selections don’t change every time the debugger’s focus shifts to another file for a breakpoint or, rarity of rarities, an error.)

Inasmuch as the offer’s open a bit longer, you can still use the XML13 discount code for a 10% discount on your fees for this year’s XML Summer School.

This year, with Patricia Walmsley, I’m teaching Improv­ing stylesheets through the use of advanced features in the XSLT and XQuery track:

Most XSLT developers stick to a famil­iar core set of XPath and XSLT instruc­tions and func­tions. There are a num­ber of advanced fea­tures, many of them intro­duced in ver­sion 2.0, that appear only rarely in stylesheets even though they can be very use­ful in cer­tain situ­ations. In this course, we will explore some of these less-used fea­tures, show­ing inter­act­ively how they can be applied to improve exist­ing XSLT stylesheets. XPath fea­tures covered will include oper­at­ors like inter­sect and except, << and >>, quan­ti­fied expres­sions, and 2.0 func­tions that can sig­ni­fic­antly sim­plify your stylesheets. XSLT fea­tures covered will include group­ing, reg­u­lar expres­sion match­ing and advanced mod­u­lar­iz­a­tion using modes and instruc­tions like xsl:apply-imports and xsl:next-match.

One, in the XSLT and XQuery track, is an update of the Developing and Testing in XSLT talk, again alongside Jeni Tennison, that got us such a good review last year:

Unit tests, pro­fil­ing, debug­ging and, increas­ingly, test-driven devel­op­ment are part of the bread and but­ter of work­ing with other pro­gram­ming lan­guages but are not always so with XSLT or XQuery. In test-driven devel­op­ment, which is a fun­da­mental part of agile approaches to soft­ware devel­op­ment, the developers write tests that describe the desired beha­viour of their applic­a­tion, then write code that meets the tests. This style of devel­op­ment keeps code focused, avoids break­ing exist­ing code and facil­it­ates refactoring.

In this ses­sion, Jeni Ten­nison and Tony Gra­ham will describe both the state of the art in test­ing and debug­ging XSLT and XQuery and how test-driven devel­op­ment applies to XSLT and XQuery devel­op­ment. In par­tic­u­lar, they will focus on the use of the XSpec test­ing framework.

The other, in the Publishing track, is XML and Publishing Workflows:

Some formats are bet­ter or worse than oth­ers for cap­tur­ing and/or rep­res­ent­ing the inform­a­tion for pub­lish­ing pur­poses. Can you cre­ate and man­age life-cycle work­flows which ration­al­ise or reg­u­lar­ise mixes of formats using XSLT and other XML tool­sets? Should XML be the begin­ning of your pub­lish­ing work­flow, the hub format in the middle, the res­ult, or all three? How can XSLT and related tools be used to cover up the defi­cien­cies or excesses of the source XML? What are the argu­ments for mov­ing authors towards sub­mit­ting in XML (or not)? For mov­ing editors?

Incor­por­at­ing both live examples and war stor­ies, Tony Gra­ham will lead an exam­in­a­tion of XML in pub­lish­ing work­flows, the advant­ages and dis­ad­vant­ages of using XML at each stage, and some of the tools and tech­niques avail­able to you.

Inasmuch as I’d been threatening since the XML Summer School last year to do it, I’ve made a custom Ant task for running XML Calabash, currently only in my fork at git@github.com:MenteaXML/xmlcalabash1.git.

You can use this task to process:

A single input file to produce a single output file

A set of input files, processed one at a time, to produce a set of output files

Multiple input files as the input to one XProc input port processed to produce a single output file

Any of the above with additional input ports to each of which are applied one or more input files whose file names may be either fixed or mapped from the name(s) of the current main input file(s)

Any of the above with additional output ports whose file names may be either fixed or mapped from the name(s) of the current main input file(s)

Any of the above with Ant defaulting to not running the pipeline when the outputs are already up-to-date compared to the inputs and the pipeline

Inasmuch as, back in January, I was teaching another XML course, I reviewed the basis for draconian error handling in XML in light of the sea change in recent years towards HTML5-style completely-defined error recovery.

At the time of the draconian error handling decision, I was on the larger “W3C SGML Working Group” mailing list that provided input, clamour, and distraction to the core “W3C SGML Editorial Review Board” that did the work and made the decisions on the road to XML. I followed the discussions on the mailing list at the time (as much as humanly possible), and the message about this that stuck in my mind is the “ERB votes on error handling” message from Tim Bray on behalf of the ERB, particularly this section:

2. We have a strong political reality to deal with here in that for the first time, the big browser manufacturers have noticed XML and have together made a strong request: that error-handling be completely deterministic, and that browsers not compete on the basis of excellence in handling mangled documents. It was observed that if they wanted to do this, they could just do it; but then pointed out that this is exactly why standards exist – to codify the desired practices shared between competitors. In any case, if we want XML to succeed on the Web, it will be difficult to throw the first serious request from M & N back in their face.

Inasmuch as the Wisent parsing and other CEDET/Speedbar/Semantic goodness for RELAX NG compact syntax files that I’m currently working on may not be ready for prime time for a while, here’s something to add to your .emacs so `flymake' runs Jing in the background to find syntax errors in your RELAX NG compact syntax files: