pipelines

RELAX NG for matching

Jeni — Thu, 06 Mar 2008 14:59:03 +0000

I’m still thinking about doing automatic markup with XML pipelines, and the kind of components that you might need in such a pipeline. These are the useful ones (list inspired by the components offered by GATE):

a tokeniser that uses regular expressions to add markup to plain text
a gazetteer that uses a lookup to add markup to plain text
an annotater that adds attributes to existing elements based on their context/content
a grouper that adds markup around sequences of existing markup
a stripper that removes markup
a general purpose transformer that uses XSLT to do just about everything else

The “grouper” is the most interesting and difficult of these. It needs to act like a tokeniser, except use regular expressions over markup rather than over text. For example, say I had:

<number>06</number><punc>/</punc><number>03</number><punc>/</punc><number>08</number>

I want to be able to create a rule that says “any sequence that looks like a number element that contains a two-digit number between 1 and 31, followed by a punc element that contains a slash, followed by another two-digit number between 1 and 12, followed by a punc element that contains a slash, followed by another two-digit number should be wrapped in a date element”.

Now this is something that XPath is really bad at. Try writing an expression that selects, from a sequence of elements that may contain other <number> and <punc> elements as well as other elements, only those sequences of elements that match the pattern I just described. It’s something like:

number[. >= 1 and . <= 31 and string-length(.) = 2]
      [following-sibling::*[1]/self::punc = '/']
      [following-sibling::*[2]/self::number[. >= 1 and . <= 12 and string-length(.) = 2]]
      [following-sibling::*[3]/self::punc = '/']
      [following-sibling::*[4]/self::number[string-length(.) = 2]]
  /(self::number, following-sibling::*[position() <= 4])

which is fiddly and messy and only works in this particular example because I know precisely how many elements there are supposed to be in the group.

In fact, it’s even difficult to do this kind of grouping using XSLT, even with <xsl:for-each-group> because the grouping is designed around elements either returning the same value or starting or ending with a particular kind of element, rather than grouping together a sequence that has a particular internal structure.

The language that is designed to describe sequences of elements is RELAX NG. Obviously RELAX NG is really useful as a schema language, but it’s really all to do with defining regular expressions over XML structures. We can use RELAX NG to describe the pattern of elements we want to match:

<group>
  <element name="number">
    <data type="integer">
      <param name="minInclusive">1</param>
      <param name="maxInclusive">31</param>
      <param name="pattern">[0-9]{2}</param>
    </data>
  </element>
  <element name="punc">
    <value>/</value>
  </element>
  <element name="number">
    <data type="integer">
      <param name="minInclusive">1</param>
      <param name="maxInclusive">12</param>
      <param name="pattern">[0-9]{2}</param>
    </data>
  </element>
  <element name="punc">
    <value>/</value>
  </element>
  <element name="number">
    <data type="integer">
      <param name="pattern">[0-9]{2}</param>
    </data>
  </element>
</group>

or, in compact syntax:

element number { 
  xs:integer { minInclusive = "1" maxInclusive = "31" pattern = "[0-9]{2}" }
},
element punc { "/" },
element number { 
  xs:integer { minInclusive = "1" maxInclusive = "12" pattern = "[0-9]{2}" }
},
element punc { "/" },
element number { 
  xs:integer { pattern = "[0-9]{2}" }
}

As a language, RELAX NG is really good at this. You could even imagine adding attributes to name subexpressions which you could then do things with (in the same way as you can get the substring matching a subexpression when you use a regular expression over text).

So I think a “grouper” component should use RELAX NG to identify sequences to be marked up. But I have no idea if there are RELAX NG libraries out there that can be used in this way: to identify and extract matching sequences rather than to validate entire documents.

Automatic markup and XML pipelines

Jeni — Mon, 25 Feb 2008 22:02:57 +0000

The project I’m working on at the moment aims to use RDFa (in XHTML) to expose some of the semantics in some natural-language text. We’re aiming moderately low — marking up dates, addresses, people’s names, and various other more domain-specific things — at least at the moment.

The problem we’re getting into now is how to get that information marked up. Because the information comes from various pretty unregulated sources, there’s no way we can force the authors to do the mark up. And the scope for making it “worth their while” (in terms of making their authoring job easier or more effective or even offering financial rewards) is very low.

So we’re taking a look at the technologies we might use for automating the markup, specifically GATE and UIMA.

These technologies basically use pipelines of components which each add some (out of line) annotations to the text. The annotations are done out of line because they might overlap, but you can (usually) serialize them into XML, which is what we want to do.

I find these technologies frustrating for a number of reasons:

any configuration we do will be specific to that particular application; it’ll be hard to for us to change to another implementation later on, and reuse by others will be limited to those who use the same implementation
they involve a fair bit of proper coding (by which I mean Java or C++)
where components can be configured through declarative means (such as keyword lists), there’s no way to reuse (XML/RDF) resources that we already have; we’ll have to manage transformations from them into the accepted formats through some external means, and I just know they’ll get out of sync
their user documentation is dreadful; it seems like you need to have a good understanding of natural language processing to have a hope of even getting started

It strikes me that the really powerful part of each of these technologies is the pipelining. The pipelining allows you to string together relatively simple operations (tokenising text, extrapolating sentences, marking up keywords, resolving ambiguities based on context etc.) which together give you something reasonably sophisticated.

Using XProc to coordinate the pipeline would alleviate many of my frustrations. XProc can and will be implemented on many platforms, in many languages, so it’ll be possible to move the pipeline from place to place (assuming that the components of the pipelines are similarly generic). It’s declarative, so no “proper coding”. We’ll be able to incorporate any transformations from existing XML/RDF data to the required configuration formats right into the pipeline. And… OK, it won’t automatically give us great user documentation or GUIs, but they’ll come.

The big problem is that XProc is still a Working Draft and the XProc ecosystem isn’t well-developed. If we were one or two years down the line, XProc would be a Recommendation, there’d be a .NET implementation readily available, and even perhaps extension XProc step types for tokenising, grouping and the other things we’d need to do; anything that was missing we could pull together using XSLT.

As it is, we’re in that annoying in-between-time when the Right technology isn’t ready and it looks like we’re going to have to put effort into working with what feels like the Wrong technology just to get things done. But perhaps I’m overlooking something in GATE or UIMA, or have missed another technology that would help us. Anyone out there got some experience that could help guide us?

Detecting streamability in XPath expressions and patterns

Jeni — Tue, 06 Nov 2007 19:45:45 +0000

The XSL Working Group gave some comments recently on the Last Call Working Draft of XProc. One of the comments was about a bunch of standard steps that we’ve specified which do things you can do in XSLT, such as renaming certain nodes. These steps generally use XPath expressions or XSLT patterns to identify which nodes should be processed.

What bothers the XSL WG is that these steps aren’t guaranteed to be streamable. In a streamable process, an input document can be delivered to the processor as a stream of events (and an output similarly generated as a stream of events) rather than as an in-memory representation. Such processes will start producing results more quickly and require less memory than non-streamable ones. And, because they don’t need as much memory, they are able to work on larger documents.

If the processes we defined in XProc were streamable, there’d have a clear advantage over their XSLT equivalents, and therefore a purpose. However, since they’re not guaranteed streamable, it looks like we’re simply creating yet another transformation language.

My response was basically that we left it down to implementers to detect when a particular expression/pattern was streamable because defining a streamable subset of XPath would (a) take too long, (b) require people to learn a particular XPath subset, raising the adoption barrier, (c) require implementers to implement their own XPath engines, raising the implementation barrier.

But if you put those pragmatic reasons to one side, I think there are good abstract reasons not to specify a streamable XPath subset. First, there is no clear line that can be drawn between a streamable XPath and an unstreamable one, only a scale between “buffering nothing” and “buffering everything” (building an object model). Second, you can’t judge the streamability of an XPath expression on its own: there are multiple other factors that effect how streamable a given XPath expression is for a particular processor.

To illustrate, say that we’re renaming all elements that we select, and let’s start with an expression that’s obviously streamable:

//section

No problems here: as soon as we hit an start-tag (or end-tag) for a <section> element, we can change its name.

Now add a predicate:

//section[@type = 'summary']

This predicate tests the value of the type attribute on the <section> element. If we’re using SAX or StAX events, then this is as straightforwardly streamable as the previous example, because attribute values are reported at the same time as start-tags. But that’s purely down to the API: the underlying algorithm for streaming RELAX NG validation uses a different event model, for example, in which attributes are reported after the start tag begins (and before the start tag ends). So streamability depends on the event model.

Now a different predicate:

//section[title = 'Summary']

This predicate tests the value of the <title> child of the <section> element. In fact, it tests if the <section> element has any <title> child with the value 'Summary'. Normally, an XPath processor won’t be able to tell that a <section> doesn’t satisfy the predicate until it gets to the end-tag of the element. So it will have to buffer the events from each <section> start tag until its end tag until it can work out whether to do the renaming or not.

But say the <section> elements in this markup language can only contain a single <title>, and that’s the first child of the <section>. For an XPath processor that’s aware of the DTD or schema that the document adheres to, the situation is then very similar to the previous one, which tested the attribute. So streamability depends on how much the processor knows about the markup language.

Changing the XPath to

//section[title[1] = 'Summary']

similarly limits how much the processor will have to buffer if the <title> always appears, and always appears first, even without the processor being told that rule through a schema. So streamability depends on the markup language itself.

Anyway, I had a quick look at some academic work on streamability, such as XSQ, TurboXPath or the recent paper “Efficient Algorithms for Evaluating XPath over Streams”. These papers really surprised me. The things that prove difficult include backwards axes (which is surprising since information about the previous nodes should be easily available), the descendant axis, and the position function. On the other hand, predicates are absolutely fine (despite requiring a “look ahead”). [Weirdly enough, all the papers I looked at contained XPath errors; I guess when you’re considering abstract algorithms you don’t have to care about insignificant things like language syntax.]

The paper I mentioned above actually defines something called Univariate XPath which conforms to the syntax:

Path      := Step | Path Step
Step      := Axis NodeTest
             | Axis NodeTest '[' Predicate ']'
Axis      := '/' | '//'
NodeTest  := Name | '*'
Predicate := Path
             | Path CompOp Path
             | Predicate 'and' Predicate
             | Predicate 'or' Predicate
             | 'not' Predicate                            [sic]
CompOp    := '=' | '!=' | '>' | '>=' | '<' | '<='

This might be a useful starting point, but it omits useful things like attributes and functions which (as far as I can tell) wouldn’t effect the applicability of the algorithms. It’s also worth noting that it will allow paths such as /database[dummy]/record, which would involve buffering every <record> until the end tag of the <database> document element was reached. This illustrates that just because an XPath is theoretically streamable (can be evaluated based on a stream of events) doesn’t mean it can be evaluated efficiently.

Some final thoughts:

I wonder if there’s scope for an XPath subset that can be mapped to RELAX NG syntax and therefore evaluated using Brozozowski derivatives
what about an algorithm that evaluates XPaths using a pipeline process, whereby the stream of events is actually passed through several filters in order to provide the final evaluation
I’m sure there’s preprocessing that could be done on some XPath expressions that would increase their streamability

XProc Last Call

Jeni — Fri, 21 Sep 2007 22:35:20 +0100

Can you believe it, we’ve made it to Last Call on XProc (the XML pipeline language)! That’s only, like, nine months later than the published schedule, which I reckon is pretty good going. (Then again, I’m judging it against XSLT 2.0…)

I’m really excited about XProc. I’ve found that pipelining in XSLT — splitting up processing tasks into smaller, more manageable processing tasks and stringing them together — has greatly improved my productivity and the simplicity and maintainability of the code I write. But some processing (such as that used by my XSLT unit test framework) can’t be done in a single transformation, some is on massive documents that you can’t realistically process with XSLT (and I really don’t want to have to write SAX or StAX code to do it), and some I just want to do on all the files in a directory.

XProc gives me a high-level, declarative, streamable processing language for XML documents. And I think we’ve struck the right balance between something that’s simple enough to be easy for everyday tasks, and powerful enough to be able to do the more complex things you might want to do with it.

It’s going to be really interesting to see how much of current XSLT use it replaces, and how much it opens up. For example, the ability to use a viewport to isolate a subtree of a document for processing means that XSLT could be used on (the records in) huge database dumps. A bit like Saxon’s support for streaming large documents, but standardised.

Anyway, Last Call, guys! Read the specification. Send us your comments. Write some pipelines. Try them out with Norm’s XML Pipeline Processor. Heck, write test cases! Implement it!

On the subject of comments, I recommend:

resending any comments you already made that you don’t feel we’ve addressed; as I understand it, we’re obligated to discuss every comment we receive during Last Call
sending a separate mail for each technical comment (but a single mail with multiple editorial comments is OK)
only sending requests that you think are must-haves for version 1.0
supporting requests with examples
searching for what you want to comment on in the archives of the XML Processing WG mailing list just to make sure we haven’t already discussed it to death

I hope that doesn’t sound as if I’m discouraging comments. If you’ve got something to say, say it. But be aware that the more comments we receive the longer it’ll take us to get to Recommendation, so make ‘em count. You’ve got until the 24th October.

Pipelines (of lentils) in action

Jeni — Tue, 29 May 2007 19:27:02 +0100

We went to the Science Museum on Monday. In Launch Pad, there are lots of hands-on activities for children. One of them starts with a big container with lots of lentils in it. You have to fill a bucket with lentils, then hoist the bucket up and along so it meets with a device that flips it over so that the lentils spill down a funnel into a tube and along a chute into another large container. From there there are two Archimedes screws linked together that, when you turn their handles, take the lentils into another funnel and down another tube into yet another large-ish container. From there, there are two conveyor belts with scoops attached that take the lentils up to another funnel, down another pipe and back into the first big container, where they can start the entire process again.

Around this closed system of lentil logistics were about fifteen children. Each of them was doing one of the jobs necessary to make the system work: filling buckets, turning handles, pulling ropes, pushing stubborn lentils down chutes and so on. There was no one ordering anyone about; each child was totally absorbed and content with their single job, and every job was filled (whenever anyone left to do something else, their place was immediately taken by another child).

It made me wonder how many tasks I’m engaged in that are ultimately pointless. And whether I really care that they’re ultimately pointless, so long as I’m fulfilled doing them. And what the human race could achieve if at least some of us were engaged in a system in which we’d each do tasks we enjoyed while actually working towards a non-pointless goal. Like, you know, avoiding mass extinction or something.

XTech 2007: Wednesday 16th May Afternoon

Jeni — Sun, 20 May 2007 22:52:14 +0100

Yes, I’m determined to write up every talk I attended at XTech 2007, so that I have a record of it if nothing else. On Wednesday afternoon, I attended sessions on microformats, internationalisation and NVDL (as well as giving my own talk, of course).

Microformats: the nanotechnology of the semantic web

Jeremy Keith

This was a supremely well-put-together presentation on microformats: beautiful slides, drama and humour, and a reference to Neal Stephenson’s Diamond Age (was I really one of only three people in the packed room to have read it?). There was a lot about what microformats are, how they’re designed, what their niche is (Jeremy was very up-front about the fact they don’t solve every problem), and how they’re developed. But there weren’t any demonstrations of microformat-based applications, which I would have really liked to see. The other thing I thought was worth noting was that Jeremy talked about the dangers of “grey goo” (he was using a nanotechnology metaphor): the proliferation of microformats. He expressed the strong desire that the set of microformats be kept small, and even said (I paraphrase) “Do use semantic class names in your HTML, but don’t call them microformats [unless they’ve been through the microformats standardisation process]!”

Liam Quin gave a paper entitled Microformats: Contaminants or Ingredients at Extreme last year, asking what we, as traditional markup geeks, should do about them. Some were very sceptical, saying something along the lines of “They’re headed for a trainwreck; and we should sit back, watch it happen, and pick up the pieces.” Others wanted to celebrate: the fact that tagging has become understood is really good news for the semantic web, open data and all that jazz.

Both the traditional markup and the microformats community have the same goals: they want to make information easier to search for, to query, to integrate and so on. The microformats approach is to minimise the cost to those supplying information, and to target just a few, very common, kinds of data such as contact information, events and social networks. Traditional markup, on the other hand, aims to cover every single kind of information you might want to make available, and has to worry about issues like validating, styling, and distinguishing between tag sets.

It seems that a fundamental problem is that the benefits of including semantic markup aren’t immediately obvious to the supplier. Whether you use semantic class names in HTML or use elements in known namespaces, it’s purely a matter of faith that this will make your information easier to locate or use. You can’t know that search engines will include that information in their weighting algorithms, or that people reading your page will have the screen-scraping software necessary to pull anything out. With so little (obvious) benefit, authors will only supply semantic data if the cost is low. Adding class names to existing HTML elements is easy whether a web page is generated by hand or automatically. Adding namespaces and authoring special CSS might not be that much more costly to do, but it’s much more costly to grok.

So if we want authors to start putting elements in their own namespaces in their web pages, we need an application that immediately cranks up the benefit of doing so. I have no idea what that is.

Applying the Internationalization Tag Set

Yves Savourel

This was a good introduction to [a standard] I only knew about vaguely. It’s definitely worth knowing about the its:* attributes for defining i18n features such as indicating which content should be translated, which are terms, providing comments for localisation and so on, just in case you need to build those in to new markup languages.

I also have much admiration for how the ITS standard doesn’t expect people to completely rework their markup languages to incorporate ITS data. Instead of using the ITS attributes directly in a document, you can use global rules embedded in the document itself, referenced from the document, or embedded in the schema for the document. I think this approach will prove useful in the development of LIX, when we get around to formalising it.

NVDL - a breath of fresh air for compound document validation

Jirka Kosek & Petr Nálevka

NVDL is Part 4 of DSDL, specifically targeted at organising the validation of documents that incorporate multiple namespaces, such as XHTML documents containing islands of SVG, RDF and MathML. NVDL’s approach is to identify subtrees within the document that need to be validated against a particular schema. The subtrees don’t need to only hold one namespace, but often that will be the case.

The XML Schema wonks in the room (Henry Thompson and Michael Sperberg-McQueen) were a bit befuddled, I think, because with XML Schema you just supply a whole bunch of schema documents to the processor, for different namespaces, and as long as the schemas contain wildcards they’ll do the right thing. The concept of supplying multiple schemas to a validator isn’t part of RELAX NG’s validation approach, so you need something like NVDL if you don’t want to rework your schema for every combination of namespaces.

Henry and Michael were particularly concerned about the fact that it means you can override the original schema, allowing elements from foreign namespaces in situations where the original schema hasn’t allowed them. But as Henry said, it just means that the primary schema you use to define what’s allowed where is actually an NVDL schema: it’s not auxiliary validation like Schematron is, but a language for the primary schema you use.

Later, I wondered how much the XProc work would render NVDL irrelevant. After all, XProc can invoke validation of subtrees against multiple external schemas. On the other hand, NVDL’s syntax is going to be easier to use if that’s all you want to do. Perhaps someone will write a tool to convert NVDL schemas to XProc pipelines…

Actually, Jirka & Petr’s experience with JNVDL is interesting from the XProc viewpoint, in particular the problems that they had with reporting meaningful line numbers when validating subtrees. Something that XProc implementers might want to look at in regard to error reporting with <p:viewport>.

Pipelining in XSLT

Jeni — Sun, 22 Apr 2007 22:28:50 +0100

I took on a long-term contract back in January which is good fun (of course I have to say that; my boss might read this) and pretty challenging.

First, I’m hobbled by having to use XSLT 1.0 (MSXML, what’s more). I hadn’t really realised either how fantastic XSLT 2.0 is, nor how used to it I’ve become, until I started this work. How I miss user-defined functions, sequence constructors and if expressions.

Second, my task is to take some XHTML generated from WordprocessingML and (a) turn all the CSS styling relative, so that it uses ems and percentages all over the place rather than points and (b) rationalise the CSS so that common styling appears in the <head> of the XHTML rather than on individual elements.

Now I hesitate to say that something is impossible in out-of-the-box XSLT 1.0, but I have developed a sense of when something is impractical. Here, to rationalise styles, we’re looking at grouping (elements) with a calculated value (their inherited style). That would be OK in XSLT 2.0, with <xsl:for-each-group> and user-defined functions, but in XSLT 1.0 it means code that is hard to write and impossible to maintain.

The good news? I’m allowed to use msxsl:node-set(), and that means I can use a pipeline. I can break down the complex process into simple steps, such as:

turn CSS declarations into attributes
inherit declarations from element and class rules down to individual elements
inherit declarations down the tree, so that child elements inherit undefined inheritable properties from their parent
inherit declarations up the tree, so that parent elements have declarations that are common to their children
convert those properties that can take relative values into relative values
update existing and create new class definitions for combinations of declarations that are used many times in the document
remove declarations that are inherited from element and class rules or from parent elements
remove elements that don’t have any new declarations
turn attributes back into CSS declarations

In my stylesheet, I have a different mode for each step. I can capture the result of processing a document in that mode in a result tree fragment, then convert that into a new document using msxsl:node-set(), and process that document. I end up with lots of variable declarations like:

<xsl:variable name="inheritedDeclarations">
  <xsl:apply-templates select="msxsl:node-set($declarationsAsAttributes)"
    mode="inheritDeclarations" />
</xsl:variable>

The trouble with this is that it’s hard to modify the pipeline and you have to make up unique names for each intermediate variable, which is such a challenge that they end up with meaningless names. So I created a mini pipeline definition in the stylesheet:

<my:pipeline>
  <my:step mode="styleToAttributes" />
  <my:step mode="inheritDeclarations" />
  ...
</my:pipeline>

and then process it with a template similar to the following:

<xsl:template name="processPipeline">
  <xsl:param name="steps" select="document('')/*/my:pipeline/my:step" />
  <xsl:param name="source" select="/" />
  <xsl:choose>
    <xsl:when test="$steps">
      <xsl:variable name="mode" select="$steps[1]/@mode" />
      <xsl:variable name="result">
        <xsl:choose>
          <xsl:when test="$mode = 'styleToAttributes'">
            <xsl:apply-templates select="$source" mode="styleToAttributes" />
          </xsl:when>
          <xsl:when test="$mode = 'inheritDeclarations'">
            <xsl:apply-templates select="$source" mode="inheritDeclarations" />
          </xsl:when>
          ...
        </xsl:choose>
      </xsl:variable>
      <xsl:call-template name="processPipeline">
        <xsl:with-param name="steps" select="$steps[position() > 1]" />
        <xsl:with-param name="source" select="msxsl:node-set($result)" />
      </xsl:call-template>
    </xsl:when>
    <xsl:otherwise>
      <xsl:copy-of select="$document" />
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

I have to modify the processPipeline template each time I introduce a new step, but dropping, repeating, or reordering the steps in my pipeline is very easy: I just change the pipeline definition by removing, copying or moving the <my:step> elements.

(You can use the same template in other XSLT 1.0 processors by changing the msxsl:node-set() call into the version of the function used by your processor. And you can use the same code in XSLT 2.0 by just dropping the call to msxsl:node-set() altogether, though I’d also change the <xsl:copy-of> to a <xsl:sequence> to prevent unnecessary node creation.)

The only thing that bugs me about this approach is the performance: creating so many nodes seems wasteful, especially when many are straight-forward copies of existing nodes. Now that I understand better what the stylesheet needs to do, perhaps I can merge some of the step together. In any case, in the environment I’m writing for, performance isn’t a particularly big issue.

Of course what I really want is XProc to be finished and implemented (and adopted by the company I’m working for). Several of the steps I’m using could be streamed and might be better implemented in something other than XSLT. But at least breaking down my transformation in this way has made it easier (possible!) to write, more manageable, and more amenable to migration to a proper pipeline in the future.