Registration has just opened for this year’s XML Summer School, held in Oxford on 20-25th September. I’m teaching a couple of sessions and helping with a workshop on the “XSLT, XSL-FO and XQuery” track along with Bob DuCharme, Michael Kay and Priscilla Walmsley. It’s one of my favourite events, for three reasons:
I know a lot of beginners go to the XML Summer School for the introduction course, but to me the real value is for people who are actually using XML on a day to day basis and want to keep on top of the latest tools and technologies that will actually help them do their jobs. I learn something new every year.
Anyway, I wanted to blog about it because there’s a discount on registration up until 30th June. Grab ‘em while you can!
In my last post I talked about different techniques for representing overlap within XML. One technique is fragmentation. In the work that I’ve been doing, I’ve been using milestone-based formats similar to ECLIX, but my eyes were opened at the GODDAG workshop: fragmentation would make overlap so much easier to process in XSLT, especially when dealing with localised overlap such as revision or comment markup.
But how could fragmentation be used with full-on overlap? I had a little play and came up with some XSLT to demonstrate.
Global retail organisation and household name is looking for 2 (two) Front-End/User Interface Developers to work on a major consumer e-commerce portal.
A question about how to refactor some repetitive templates.
The issue is in creating XHTML headings.
For a small docbook article, I have the following templates in one of my stylesheets:
The Free Our Bills campaign was launched recently in the UK. Some of the comments I’ve seen about the campaign makes me think that it might be helpful if people understood more about how Bills and legislation get published in the UK. I thought I’d offer a bit of background based on my experience (though there are many people with more intimate knowledge of the processes involved; perhaps they’ll correct me when I get it wrong).
Michael Sperberg McQueen (CMSMcQ) has written a couple of interesting posts about datatypes in W3C’s XML Schema (XSDL). (The second is a response to a comment from John Cowan, and attempts to justify some of the seemingly arbitrary decisions made in the set of datatypes present in XSDL 1.0.) The posts are a discussion of one of the issues against XSDL 1.1 raised by Michael Kay:
Michael proposes: just specify that implementations may provide additional implementation-defined primitive types. In the nature of things, an implementation can do this however it wants. Some implementors will code up email dates and CSS lengths the same way they code the other primitives. Fine. Some implementors will expose the API that their existing primitive types use, so they choose, at the appropriate moment, to link in a set of extension types, or not. Some will allow users to provide implementations of extension types, using that API, and link them at run time. Some may provide extension syntax to allow users to describe new types in some usable way (DTLL, anyone?) without having to write code in Java or C or [name of language here].
The first of what will probably become a series of posts where I answer publicly questions that people post me privately (with permission, of course)…
How should I model (and store) data for Courses, while being able to pull info about a Course into a particular context (a Semester or Curriculum)?
A Google Search Appliance (GSA) is a box that you plug into your network which crawls and indexes your data, and serves up the results of searches. Search results come in an XML format, and there’s a built in XSLT engine which means you can convert that XML into as many different views as you like. So you can have HTML-based search results, summaries, feeds, and so on.
My task recently was to debug some XSLT that transformed the GSA XML into an Atom feed. Easy enough, right? The GSA XML format is pretty hideous — most of the elements max out at three capital letters in length (whatever happened to human-readability) — but logical enough, and the mapping is hardly complex.
But all was not as it seemed. The GSA’s XSLT implementation is… how can I put this politely?… “non-standard”. This post describes some of the problems and workarounds.
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.
I’m exhausted after two days of teaching XSLT 1.0. Yes, there are still people out there who want to learn it. The exhaustion comes mainly because I’m an introvert (INFP, Myers-Briggs fans!) who finds it tiring just being in the same room as someone else.
In fact, I’ve been teaching XSLT 1.0 rather a lot in the past couple of months. The first lot was a bunch of C# programmers who had done some light XSLT work, the second a bunch of developers who’d been using XSLT for years, but wanted to improve. The majority of people on this most recent course weren’t even developers.