I have enjoyed the work and the company of my co-workers, but there’s a few points to note:

• Going “across the water” to England to work may be almost an Irish tradition, yet it has shown the undesirability of living away from home for extended periods
• Since I’ve not known what I’ll be doing after the contract ends, I’ve kept doing work for some of my consulting clients at nights and weekends, but that hasn’t always got them results as quickly as they would like and, frankly, it made a very poor lifestyle choice
• There’s been little time left for side projects (or, you may have noticed, for blog posts), yet I have many side projects related to XML, XSLT, and XSL-FO and would have more if I had the time – I don’t aspire to it, but I was interested to see that the .net awards has elevated side projects to being an award category of their own
• As a contractor rather than an employee, I don’t get sick leave or holiday pay, so catching a cold can (and did) cost me money, but I’m able once the contract ends to have a long break visiting family on the other side of the world and then going to Balisage
• As a contractor, I’ve also had the freedom to go to XML Prague and to the MultilingualWeb workshop in Rome without having to fret about departmental training budgets, how the events align with corporate goals, or using precious holiday days and my own money (though in a sense it was) if I did out of my own pocket, though I did miss the W3C “eBooks and I18n” workshop last week in Tokyo because of pressures of work, so to be a contractor isn’t to be a completely free agent, and if I was still or again a member of an active W3C WG, then multiple face-to-face meetings a year would strain my finances more than they would a large corporation’s

So what am I looking for?  Firstly, a good, long break before I address the question for real after Balisage in August. Secondly, to be based back in Ireland, at least most of the time. Beyond that, it’s undecided.  I’m not running away from consulting nor running towards either employment or more contracting. Consulting has been good to me, and been good for me since I can use a wide range of skills with different clients, but the difficulty has always been getting the right amount of work to arrive at just the right intervals so that I’m neither swamped nor starved for work.

The XSL-FO 2.0 Requirements document includes, among others, requirements for: feedback from the pagination stage; including information from formatting time; and outputting the result of an expression back into the area tree.  However, the XML Print and Page Layout Working Group (as the XSL-FO subgroup became) never got to the point of working out how any of those would be expressed.

More recently, the Print and Page Layout Community Group has been collecting examples where feedback from the formatter is useful – or essential – for a satisfactory result.  Thanks to Arved Sandtrom we also have proof-of-concept for running a XSL formatter from a XSLT extension function to get an area tree, so an XSLT stylesheet can now make decisions about what to put in the result based on the trial formatted size of areas, but as it’s only a proof-of-concept, it doesn’t aim as high as getting feedback from or modifying in-situ the area tree for the final, formatted document.

Once people have tried a few things with getting feedback from the XSL formatter and start asking their vendors for the same or better, they’ll also be wanting an interoperable way to express what to do with that feedback.  For simple feedback of static area trees, which is all that is possible with the current proof-of-concept, the most interoperability that you could manage would be a common representation of area trees (with flexibility for vendor extensions) and, possibly, a library of XSLT functions to make it easier to navigate the area trees, but for “live” feedback, something more would be required.

The following template from the “Knight’s Tour” sample Saxon-CE application is the event handler for when the user clicks the ‘Reset’ button.  It simply writes a no-break space to each square on the Knight’s chess board

<xsl:template match="button[@id='reset']" mode="ixsl:onclick">
  <xsl:for-each select="//div[starts-with(@id, 'square')]">
     <xsl:result-document href="#{@id}" method="replace-content">
       <xsl:text>&#xa0;</xsl:text>
     </xsl:result-document>
  </xsl:for-each>
</xsl:template>

The key feature of the event handler for the purposes of this discussion is that it’s written in plain old XSLT.  The advantage of the XSLT event handler for Saxon-CE users is interactivity “without dropping down into JavaScript” (as the Saxon-CE documentation so delicately puts it), but the advantage for XSL-FO users would simply be that they don’t need to learn a new language (declarative, functional, or otherwise) to handle feedback.  (And the advantage for those of us trying to define or implement feedback is that we don’t need to invent a whole new language to handle it.)

Applying the Saxon-CE approach to XSL-FO, the following illustrative FO event handler would handle a figure overflowing its available space by reducing its size to 80% of the current.

<xsl:template match="BlockArea[key('fig', @id, $src-doc)]"
              mode="ppl:overflow">
  <xsl:result-document href="#{@id}/area:external-graphic"
                       method="replace-content">
    <xsl:copy>
      <xsl:apply-templates select="@*"/>
      <xsl:attribute name="width"
                     select="ppl:scale(area:external-graphic/@width,
                                       0.8)"/>
      <xsl:apply-templates/>
    </xsl:copy>
  </xsl:result-document>
</xsl:template>

(I invented a ppl:scale() XSLT extension function here so the new length is written back to the area tree rather than requiring that XSL formatters support an expression language in area tree trait values.)

An extra wrinkle for XSL-FO is the question of whether event handlers should be specified to (a) match on, and (b) modify the FO tree or the area tree or both.  There are some existing requirements that can only be satisfied by modifying the area tree, e.g., Section 3.3, Output result of expression:

Allow users to output the result of expressions on area tree, traits, markers or text content. For example to calculate the subtotal of a certain page (as opposed to a running total that is already supported in XSL 1.1 with table markers)

On the other hand, it will often be simpler (from the user’s perspective) to modify an FO rather than all the areas that it generates, since a single FO may generate multiple areas across several columns or pages (and footnote areas), and its content may be reused in markers on multiple pages.  If, for example, the response to a page sequence taking too many pages is to reduce the font size in one of the multiple flows appearing on the page, it would be at once simple to adjust the font-size property on the appropriate FOs in the FO tree and inaccurate to directly modify font sizes in the line areas in the area tree.  If the XSL formatter did the work based on modified FOs, it would reflow the line areas based on their reduced font size and make the pages again and the resulting modified block areas would break across pages in different places because of the smaller font size.  If the XSLT stylesheet did the work by modifying the area tree, it would have to do the same recalculating of text sizes and the same merging or splitting of line areas and of block areas, and all (probably) without the benefit of font metrics.  It might work, just, in a simple case with only monospace fonts, but would still be a lot of work to do in XSLT.

Adapting the Saxon-CE event model to XSL-FO is, therefore, an interesting possible solution to handling feedback from the XSL formatter, but there are still many FO-specific details that would have to be worked out.

Evaluating the same attribute set more than once can produce different results, because although an attribute set does not have parameters, it may contain expressions or instructions whose value depends on the evaluation context.

This changing context was useful recently when customising an existing XSL-FO stylesheet included adding id properties for use as the targets of fo:basic-link cross-references.  Since I couldn’t  modify the base stylesheet, I was looking at having to replicate multiple templates just to add the id properties where needed. However, to make it easy to customise the base stylesheet, its templates for the elements of interest each referred to named attribute sets and, more often than not, I was already adding to the same attribute sets in my stylesheet that imported the base stylesheet. It was simple, therefore, to add the xsl:attribute for the id property to the customisations of the attribute sets and be able to leave the base stylesheet’s templates unaltered.

The short form of what I was doing may be seen as:

<xsl:attribute-set name="fig">
  <xsl:attribute name="id" select="generate-id()" />
</xsl:attribute-set>

where the changing context for each time the attribute set is used produces a different id attribute each time, each containing the unique ID for the then-current context node.

However, the source XML had id attributes on some elements already, and I wanted to hook into using the existing machinery in the base stylesheet for getting either the assigned ID or a generated ID, so the code in the customising stylesheet was more like:

<xsl:attribute-set name="fig">
  <xsl:attribute name="id">
    <xsl:call-template name="get-id" />
  </xsl:attribute>
</xsl:attribute-set>

<xsl:template name="assign-id">
  <xsl:param name="node" select="."/>
  <xsl:attribute name="id">
    <xsl:call-template name="get-id">
      <xsl:with-param name="node" select="$node"/>
    </xsl:call-template>
  </xsl:attribute>
</xsl:template>
  
<xsl:template name="get-id">
  <xsl:param name="node" select="."/>
  <xsl:apply-templates select="$node" mode="id"/>
</xsl:template>

where the assign-id template overrides the corresponding template in the base stylesheet and part of the function of the original assign-id is broken out into get-id for use in the attribute sets. And did I mention that the base stylesheet, and therefore also its customisation, was written in XSLT 1.0 for maximum portability?

The symptom when trying to boot into Windows was a black-and-white screen of death containing:

File: \Boot\BCD
Status: 0xc0000034
Info: The Windows Boot Configuration Data file is missing
  required information

The official Microsoft advice at http://support.microsoft.com/kb/927391/en-us didn’t help.  What did work was the second option, “Manually Repairing the Windows Bootloader”, from http://neosmart.net/wiki/display/EBCD/Recovering+the+Windows+Bootloader+from+the+DVD:

attrib -h -s C:\boot\BCD

del C:\boot\BCD
bootrec.exe /rebuildbcd

Happily, I didn’t need to do the third, “Nuclear Holocaust” option from that page.

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.

XML Sum­mer School 2012 is on Septem­ber 16–21 2012 at St Edmund Hall, Oxford Uni­ver­sity.

“My name is Dick Marston” as the opening words of Robbery Under Arms may not have the recognition nor the ring of “Call me Ishmael” (though for a great young-adult read, Don’t Call Me Ishmael), but it is one of the great Australian novels.  If you want to read the EPUB, a search for ‘”Robbery Under Arms” EPUB’ will turn up several sources.

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

You can also specify options and parameters to be used by the pipeline.

Examples

Single input, single output

<calabash in="in.xml" out="out1.xml" pipeline="pipeline.xpl"/>

What could be simpler?

Implicit fileset plus mapper on additional input port

<calabash
    includes="doc.xml"
    inport="source"
    destdir="out"
    extension=".compare.xml"
    pipeline="compare-001.xpl">
  <input port="alternate">
    <globmapper from="*.xml" to="*-alt.xml" />
  </input>
</calabash>

Fixed input, multiple mapped outputs

<calabash
    in="group-003_input1.xml"
    pipeline="group-003_pipeline.xpl">
  <output port="result">
    <globmapper from="*_input1.xml" to="out/*_result.xml" />
  </output>
  <output port="result2">
    <globmapper from="*_input1.xml" to="out/*_result2.xml" />
  </output>
</calabash>

QNames

<calabash in="in.xml" out="out.xml" pipeline="pipeline.xpl">
  <namespace prefix="hi" uri="low" />
  <parameter name="{hi}there" value="a value" />
  <parameter name="hi:there" value="a value" />
</calabash>

{hi}there is a QName in Clark notation, where hi is the namespace URI and there is the local name; whereas hi in hi:there is a namespace prefix that is bound to the low namespace URI.

I had a more fully-featured Ant mode years ago but accidentally lost it when changing machines once, so putting the new mode on GitHub makes it both available to you and harder for me to lose.  The motivation for reinventing it now came from from working with the build files in my fork of XML Calabash while I was adding the Ant task for running XML Calabash.

The current schema bundled with the mode is little more than a translation using Trang of the DTD dumped by <antstructure>, so I know I need to tweak it to make it easier to extend with custom task types, but in the meantime the mode is useful for when you’re looking at someone else’s build file (or your own when it’s grown big enough).

use-when (and xsl:use-when on non-XSLT elements) is for “conditional element inclusion” and is very useful for excluding elements that either aren’t currently useful or that will cause errors if acted upon.  The use-when in the example below causes the xsl:value-of to be used only when saxon:line-number() is available, thereby avoiding the Saxon extension functions are not available under Saxon-HE message from more recent versions of Saxon HE where saxon:line-number() is no longer available but producing a useful result on older Saxon HE versions where the function is available.

<!-- Leftover intermediate elements. -->
<xsl:template match="t:*">
  <xsl:if test="$debug">
    <xsl:message>
      <xsl:value-of select="t:node-basename(.)" />
      <xsl:value-of
        use-when="function-available('saxon:line-number')"
        select="concat(':', saxon:line-number())"
        xmlns:saxon="http://saxon.sf.net/" />
      <xsl:text> :: </xsl:text>
      <xsl:copy-of select="." />
    </xsl:message>
  </xsl:if>
  <xsl:apply-templates />
</xsl:template>

The use-when expression is evaluated very early in the processing of the stylesheet, and you can’t use variable references in the expression.  So don’t be tempted to try:

<xsl:message use-when="$debug">
...
</xsl:message>

• Start from the examples in the documentation – My first attempt at a top-level production was incorrect and failed to match anything, so nothing matched. I eventually resorted to reusing the entire wisent-graphviz-dot-mode parsing code with one added production for RELAX NG compact syntax namespace declarations and built it up from there until I’d sufficiently got the hang of the productions to remove the remaining wisent-graphviz-dot-mode training wheels and go it alone.
• Make sure your syntax table is correct – The mode was initially based on rnc-mode by David Rosenberg of Pantor Engineering AB and used the syntax table defined in it. At one point when things weren’t working, I remembered that the wisent-graphviz-dot-mode code that I’d been using as an example included a comment about needing to modify the syntax table of graphviz-dot-mode. Sure enough, rnc-mode was missing a syntax-table entry that was needed for Semantic parsing of .rnc files. And just today I had to set the “?” character as a symbol character to get one more part working properly.
• Use the debug functions – Forgive me for restating the very, very obvious, but you will find these useful. For example, `semantic-show-unmatched-syntax-mode‘ is useful, though initially disheartening, for showing which parts of the file are not being matched by displaying a red line under the unmatched parts. Occasionally, you may also note the absence of the red line under parts that you don’t expect to be matched yet.