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.

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.

The connection that I, and possibly many others, at the time saw between this summary, at twice remove, of browser vendors asking “that error-handling be completely deterministic” and XML using draconian error handling may not have been much of a connection at all.  Okay, if you apply hindsight as of now, there never was any connection, but if you were/are of the mindset that:

• Well-formed XML doesn’t come with rules about what elements, etc., are allowed and not-allowed in different places so in the general case you can’t “just fix” a broken document so it now makes sense;
• There are (or, in 1997, were to be) XML applications where “keep calm and carry on” after receiving a document with an error isn’t an option; and
• The design goal of XML that “The number of optional features in XML is to be kept to the absolute minimum, ideally zero.” rules out including optional error recovery in the XML spec

then draconian error handling looks like the best/only alternative for XML.  And binary yes/no error handling certainly is completely deterministic even if it may not have been exactly what the browser vendors had in mind at the time.

The question whether draconian error handling is a good idea still comes up today.  (In XML circles, anyway; in HTML circles, they’ve voted with their feet/keyboards and gone for the almost too completely defined error handling of HTML 5.)  It came up again at XML Prague 2012, where the circles overlapped briefly when Anne van Kesteren presented “What XML can learn from HTML; also known as XML5” and, as Eric van der Vlist notes in his blog, in the panel discussion that followed.  The question still has no universally accepted answer: for instance, Eric in his post describes as irrational that others wouldn’t even discuss changing well-formedness requirements, and these two successive posts to the XML-ER list, by David Carlisle and David Lee, take diametrically opposite views about error recovery.

IMO, it’s too late to change the definition of well-formedness for XML 1.0, and the inroads that XML 1.1 hasn’t made illustrates the likely success of anything labelled XML 1.2 or even XML 2.0.  Enter the XML Error Recovery Community Group (XML-ER).  Set up in record time mid-conference at XML Prague 2012, its goal is to define a deterministic error-recovery mechanism for XML such that parsing well-formed XML 1.0 with a XML-ER processor (if that’s what it’s eventually called) produces the same result as parsing with a XML 1.0 processor and parsing non-well-formed XML (which, strictly speaking, by not being well-formed isn’t XML at all) produces what looks like the result of parsing well-formed XML with a XML 1.0 processor, where the fix-ups from non-well-formed to well-formed will be the same in every XML-ER processor.

Where XML-ER finds it’s place in the XML stack is a bit up in the air at present – since few people would want to parse with a XML 1.0 processor then fall back to a XML-ER processor only if it failed yet there are aspects of XML 1.0 parsing, such as reading and using any DTD, that won’t be handled by a XML-ER processor – but it is the current best effort for moving to deterministic error-handling that is more than a binary yes/no.

The intent of my talk – after the amusing introduction, the pep-talk about XSL-FO being good at multilingual layout, and the public displays of ignorance – was to make the case for additional W3C Layout Task Forces and/or for a Multilingual Layout Community Group at the W3C, where any Task Force(s) could do the heavy lifting for specific languages or scripts and any community group’s wiki could accrete information about lesser-known traditions.  Sadly, to me at least, the only expressions of support that I got for either idea were from Richard Ishida and Felix Sasaki, but then they’re also the current and previous chairs of the Japanese Layout Task Force.

Since Richard’s page, Daniels and Bright’s “The World’s Writing Systems”, and the Unicode Standard Version 5.0 (being about plain text, as it is) all cover the Khmer script without mentioning even the few layout details in the book, and since there’s no W3C community group to collect this sort of information, and since my talk included three slides of “What I know about…” for three Ruby traditions, here’s “What I know about Khmer pagination”:

Image from page 63 of Franklin Huffman’s “Cambodian System of Writing“. Book placed in the public domain in 1975.

(require 'flymake)
(defun flymake-rnc-init ()
  (let* ((temp-file (flymake-init-create-temp-buffer-copy
		     'flymake-create-temp-inplace))
     	 (local-file (file-relative-name
		      temp-file
		      (file-name-directory buffer-file-name))))
    (list "jing" (list "-c" local-file))))
(add-to-list 'flymake-allowed-file-name-masks
      '(".+\\.rnc$"
	flymake-rnc-init
	flymake-simple-cleanup
	flymake-get-real-file-name))
(add-hook 'rnc-mode-hook
	  'flymake-mode)

XSL Formatting Objects (XSL-FO) from the W3C is an XML vocabulary for specifying formatting semantics. While it shares many properties with CSS, it is most frequently used with paged media, such as formatting XML documents as PDF. XSL-FO 2.0 is currently under development, and one of its top-level requirements is for further improved non-Western language support. However, the requirement for improved support in XSL-FO 2.0 is actually less specific than the 1998 requirements for XSL 1.0 since we recognised that we didn’t have the knowledge and expertise to match our ambitions. For that, we would need more help — either from individual experts or from the W3C forming more task forces along the lines of the Japanese Layout Task Force to capture and distill expertise for use by all of the W3C and beyond.

XSL-FO does quite well at “big picture” multilingualism, with support for the Unicode Bidirectional Algorithm, multiple writing modes, and multiple text directions being there from the start and with property names being “writing-mode neutral” – such as preferring property names with “-before”, “-after”, “-start”, and “-end” rather than “-top”, “-bottom”, “-left”, and “-right” – but the “small picture” of getting the details right for individual languages and scripts has mostly been out of reach because the Working Group (under its various names) has not had the necessary knowledge to get all of it right.

If you print out the “Internationalization” section of the “XSL Requirements Summary” (produced before XSL 1.0 but explicitly not for any target version), it’s about 10 pages.  You might be tempted to discount that by noting that requirements for Western European and related languages takes about four pages, but even six or so pages is a lot more, and a lot more specific, than the corresponding section from “Extensible Stylesheet Language (XSL) Requirements Version 2.0“:

6 Further improved non-Western language support

Improve support for non-Western languages, such as Mongolian, Indic languages, Thai, Japanese, Chinese, etc. The working group invites language experts to identify language specific features that are currently not yet supported by XSL.

Specifically, the Japanese Layout Taskforce is creating a document about requirements for general Japanese layout realized with technologies like CSS, SVG and XSL-FO. The document is currently in draft stage and is being developed further by the Japanese participants in the task force. This document will be an input to the XSL working group as a source of requirements.

But as I state in the abstract for the Multilingual Web workshop, this isn’t because we don’t want to do better at non-Western languages in XSL-FO 2.0, it’s because we recognised that we need more outside help to fulfil our ambitions.  It may just be that the MultilingualWeb workshop could be the start of a way to get some of that help.

One suggestion, from George Bina, was to make a single “framework” file for running the tests – and including the test files in the framework file either directly or by using XInclude to refer to external test files – rather than the current decentralised approach.  A single framework file would make it easier to make a report of the results, unlike the the current approach where the idea is that the only report you really want to see is “<errors/>” when there are no more errors.  A single framework file could also become very large and hard to navigate when there’s lots of very similar tests in it.  What do you think?

This procedure worked for me.  There is no guarantee that it would work for you, and you use these instructions solely at your own risk.  As always, back-up your data and remove the battery before fiddling with the insides of your computer.

The underside of the P1630, with battery removed, is shown below:

The drive bay with the cover removed is shown below. The drive is covered by a plastic sheet, and it’s the four foam-rubber pads at the edges of the sheet that holds the drive in place.

Every muscle, every sinew, every fibre of your being will scream that it isn’t so, but you just need to lever up the disk drive to be able to take it out (taking care not to damage the flat cable connecting to the drive):

After you disconnect the flat cable from the drive (another moment where you wonder exactly how much force will be “enough” force), you can take the plastic/foam-rubber combo off the old drive, put it on the new drive, and do the reverse procedure to reassemble the P1630 with the new drive.

Emacs’ “Imenu” feature puts in the menu-bar a menu whose each menu item (or sub-menu item) jumps you to a location in the current buffer. Emacs being Emacs, Imenu is highly configurable, and quite often an Emacs mode will set up the Imenu menu to point to locations in the buffer that are significant for that mode/file-type. For example, my xslide and tdtd modes each set up very different Imenu menus.

`imenu-generic-expression` is a variable that, at its simplest, contains a list of three-item lists that each specify a menu title, a regular expression, and the number corresponding to the subexpression of the regular expression to use as the resulting menu item’s name. When `imenu-generic-expression` is set and the Imenu menu bar item is enabled (using `imenu-add-to-menubar`, naturally), Emacs constructs a buffer index by searching the buffer using each of the regular expressions in turn and then builds up the menu based on the matches found.

For example, here’s the `rnc-mode-hook' that I use to add a “RNC” menu when using `rnc-mode' to edit RELAX NG compact syntax (RNC) files. The hook sets `imenu-generic-expression` with patterns that match significant declarations in a RNC file (with separate sub-menus for include, namespace, and datatypes declaration types) then enables Imenu with `imenu-add-to-menubar`. A screenshot of the resulting menu is action is shown after the code.

(require 'rnc-mode)
(add-hook 'rnc-mode-hook
 (lambda ()
   (set-variable
    'imenu-generic-expression
    (list
     (list
      nil
      "^\\([a-zA-Z][-a-zA-Z0-9._]*\\)\\s-*[&|]?=" 1)
     (list
      "include"
      "^include\\s-+['\"]\\([a-zA-Z][-a-zA-Z0-9._]*\\)['\"]" 1)
     (list
      "namespace"
      "^\\(default\\s-+\\)?namespace\\s-+\\([a-zA-Z][-a-zA-Z0-9._]*\\)\\s-*=" 2)
     (list
      "dataypes"
      "^datatypes\\s-+\\([a-zA-Z][-a-zA-Z0-9._]*\\)\\s-*=" 1)))
   (imenu-add-to-menubar "RNC")))

The only downside to using `imenu-add-to-menubar` compared to doing more of it yourself is that `imenu-add-to-menubar` doesn’t provide a way to sort the menu items, so the order of the matches in the file is the order of the items in the menu or sub-menu. I wrote both xslide and tdtd before I knew of `imenu-add-to-menubar`, but the recently revived xslide for XSLT 2.0 still uses a custom function to make the Imenu index because I also like to sort the index entries alphabetically within each menu or sub-menu.