The view from Black Mesa : Notes on keeping scholarly, technical, and public information useful

An XForms case study, part 2: triggers for setting values

[20 February 2012]

This is another in an ongoing series of posts describing the design and implementation of the evaluation forms we put together last year for Balisage: The Markup Conference. The first post in the series discussed the overall look and feel of the forms.

The conference has used printed feedback forms in the past, and the online forms ask essentially the same questions as the paper forms have always asked. Overall, what’s your impression of the registration process? the materials (the on-site guide to the conference, the proceedings), etc. etc. For each question, the paper forms ask for an overall judgement (Good, Okay, Bad) and provide a space for comments. In recent years, the space for the overall judgement has taken the form of three small graphic images, showing smiling, neutral, and frowning faces:

A first version of the form

The XML document created by the form has a sequence of elements for the various topics: registration, materials, presentations, etc. Each covers one question in the form. For most questions, the element has an attribute named overall to record the user’s overall judgement of how well we did in that area, and its contents include any comments the user types into the comments field. (A few questions have a more complex XML representation, which will be discussed in separate posts.) If you would like to see the XML produced by the form in full detail, you can: go to the overview page, select the form you want to examine, optionally fill it in with some sample data, and select the Show XML button at the bottom of the page.

A straightforward translation into XForms of the question about registration would use a select1 element with the three values Good, Okay, and Bad, and an associated comments field, like this:

  <xf:group ref="instance('eval')/registration">
    <xf:label>Registration process</xf:label>
    <xf:select1 ref="@overall" appearance="full">
      <xf:label/>
      <xf:item>
        <xf:label>Good</xf:label>
        <xf:value>good</xf:value>
      </xf:item>
      <xf:item>
        <xf:label>Okay</xf:label>
        <xf:value>okay</xf:value>
      </xf:item>
      <xf:item>
        <xf:label>Bad</xf:label>
        <xf:value>bad</xf:value>
      </xf:item>
    </xf:select1>
    <xf:textarea ref=".">
      <xf:label>Comments</xf:label>
    </xf:textarea>
  </xf:group>

In a browser, it would look something like this:

You can also load the entire form into your own browser to examine it.

A first enhancement: smiling faces

The first obvious enhancement is to follow the paper form in using images of smiling and frowning faces for the various values. A few hours on the Web turned up a large number of public-domain clip-art sites, many with sets of widgets including smiling and frowning faces. It turns out that there are also smiling-face and frowning-face characters in Unicode (in the Miscellaneous Symbols block U+2600 to U+26FF), but no corresponding neutral face. And nowadays there is an entire block of Unicode emoticons (U+1F600 to U+1F64F). I was tempted by the Unicode characters, but ultimately decided that on my screen, at least, they were too hard to read clearly. So eventually I settled on a set of icons from a clip-art site.

Integrating the smiley images into the labels is simple: just embed an img element in the label, as shown here.

   <xf:group ref="instance('eval')/registration">
     <xf:label>Registration process</xf:label>
     <xf:select1 ref="@overall" appearance="full">
       <xf:label/>
       <xf:item>
         <xf:label>
           <img src="lib/smiley_thumbs_up.png"
                class="emoticon"
                height="20"
                alt="Good"/> Good
         </xf:label>
         <xf:value>good</xf:value>
       </xf:item>
       <xf:item>
         <xf:label>
           <img src="lib/smiley_pleased.png"
                class="emoticon"
                height="20"
                alt="OK"/> Okay
         </xf:label>
         <xf:value>okay</xf:value>
       </xf:item>
       <xf:item>
         <xf:label>
           <img src="lib/smiley_thumbs_down.png"
                class="emoticon"
                height="20"
                alt="Bad"/> Bad
         </xf:label>
         <xf:value>bad</xf:value>
       </xf:item>

     </xf:select1>
     <xf:textarea ref=".">
       <xf:label>Comments</xf:label>
     </xf:textarea>
   </xf:group>

This provides a bit more color in the form:

To make it easier to see what the images are saying, the full form includes a large version of the images at the top, with explanatory labels. (This version of the form actually uses two different sets of clip-art images, so I could look at each of them in context and decide which one I wanted to use.)

A second enhancement: clicking on the images

The overall Good / Okay / Bad ratings still take up a lot of screen real estate, though.

And what I really wanted was not just to use the images as part of the labels for the radio buttons, but to have an even simpler interface: ideally, I wanted just to show the three icons and let the user click on them to specify that they thought things were good, back, or okay. (There is a certain amount of danger in this way of thinking: part of the point of XForms is to provide device-independent forms that might be rendered in different ways on different devices: getting really specific about details like this may interfere with device independence.)

This can be achieved in XForms, too. After some experimentation, I ended up a method of handling this that looks like this in the browser: a large image showing the current rating for the topic, and three small images (but larger than the images in the earlier versions of the form) for changing the rating.

The large display is handled with a sequence of xf:group elements, each of which contains an img element and each of which binds to the overall rating for a given topic if that rating has the particular value associated with the image.

   <xf:group ref="instance('eval')/registration">
     <xf:label>Registration process</xf:label>
     <div class="overall-rating">
       <xf:group ref=".[@overall='good']">
         <img src="lib/smiley_thumbs_up.png"
              height="150px"
              alt="good"/>
       </xf:group>
       <xf:group ref=".[@overall='okay']">
         <img src="lib/smiley_pleased.png"
              height="150px"
              alt="okay"/>
       </xf:group>
       <xf:group ref=".[@overall='bad']">
         <img src="lib/smiley_thumbs_down.png"
              height="150px"
              alt="bad"/>
       </xf:group>
       <xf:group ref=".[@overall='dunno']">
         <img src="lib/smiley_no_speak.png"
              height="150px"
              alt="good"/>
       </xf:group>
     </div>
    ...
   </xf:group>

So the big image for the registration topic will show a smiling face if the overall attribute on the registration element has the value good, and a frowning face if it has the value bad, and so on.

The value of the overall attribute could be set by the select1 elements shown above, but in the final version we used a set of XForms triggers (user-activatable controls — on a laptop screen these are typically buttons) labeled with the images for the values:

 <div class="simple">
   <xf:group ref="instance('eval')/registration">
     <xf:label>Registration process</xf:label>
     ... <!--* read-only display image, as shown above *-->
     <div class="overall-triggers">
       <xf:trigger>
         <xf:label><img src="lib/smiley_thumbs_up.png"
                   height="40" alt="good"/></xf:label>
         <xf:setvalue ev:event="DOMActivate"
                   ref="@overall"
                   value="'good'"/>
       </xf:trigger>
       <xf:trigger>
         <xf:label><img src="lib/smiley_pleased.png"
                   height="40"
                   alt="okay"/></xf:label>
         <xf:setvalue ev:event="DOMActivate"
                   ref="@overall"
                   value="'okay'"/>
       </xf:trigger>
       <xf:trigger>
         <xf:label><img src="lib/smiley_thumbs_down.png"
                         height="40" alt="bad"/></xf:label>
         <xf:setvalue ev:event="DOMActivate"
                      ref="@overall"
                      value="'bad'"/>
       </xf:trigger>
     </div>
     <xf:textarea ref=".">
       <xf:label>Comments</xf:label>
     </xf:textarea>
   </xf:group>
 </div>

As you can see, each trigger contains a label element which in turn contains the image, and a setvalue element which specifies the action to be run when the trigger is activated. In each case, the action is to set the value of the overall attribute to the appropriate value.

The group as a whole, the large image, and the set of three triggers are each wrapped in an XHTML div element with a different class value, to make it easier to style the display appropriately using CSS.

With XForms, it was easy to get a first working version of the form, much easier than it has ever been for me to get an equivalently complex form running in straight HTML forms, with its model of form content as a flat undifferentiated sequence of attribute-value pairs. And with XForms and CSS, it was (relatively) easy to change the look and to replace the radio buttons of the first version of the form with image-labeled buttons. Working with Javascript libraries has never been anything like this straightforward for me.

2012 02 20 cmsmcq Tools
XForms Comments (0) Permalink

An XForms case study, part 1 (look and feel)

[16 January 2012]

In a previous post, I mentioned the evaluation forms we put together for the Balisage conference last year, using XForms. This is the first of a series of posts discussing some aspects of the design and development in more detail.

One of the first requirements for these forms was that if at all possible they should have the same look and feel as the pages on the main conference site. In XForms, this turns out to be remarkably simple: XForms is designed to be styled using whatever styling mechanisms are usual for the host document vocabulary. In the case of XForms in XHTML, running in a Web browser, that means the form can be styled using CSS. And because the form is embedded in a normal XHTML document, any necessary logos or graphic apparatus can be embedded in the normal way.

The forms pointed to http://balisage.blackmesatech.com/ do three things to maintain the Balisage look and feel:

They point to an appropriate CSS stylesheet, in the usual way.
```
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xf="http://www.w3.org/2002/xforms"
      xmlns:xhtml="http://www.w3.org/1999/xhtml"
      xhtml:dummy="Help the poor user of Mozilla
          evade the Mozilla namespace curse"
      ...
      >
  <head>
    <title>Balisage Speaker/Presentation Feedback</title>

    ...

    <link href="lib/feedback.css" rel="stylesheet" />

    ...
```
[The xhtml:dummy attribute is a work-around that helps XSLTForms compensate for the bug in Mozilla's XSLT implementation: Mozilla does not support the XPath namespace axis, so the only way XSLTForms can discover what namespaces are in scope is to walk around the tree collecting namespace bindings from elements and attributes in the document. The value of the attribute doesn't matter; I use a value that reminds me of why I have to have the attribute there in the first place.]

They use the same overall document structure as the main Balisage pages: three divs of class header, mainbody, and footer, respectively,
with the second in turn divided into navbar and body.

<body>

  <div class="header">
    ...
  </div>

  <div class="mainbody">
    <div class="navbar">
      ...
    </div>

    <div class="body">
      ...
    </div>
  </div>

  <div class="footer">
    <hr />
    <p>Last revised 26 July 2011.
      Copyright &#169; 2011 <a
        href="http://www.blackmesatech.com/">Black Mesa
        Technologies LLC</a>.
      <a rel="license"
        href="http://creativecommons.org/licenses/by-sa/3.0/">
      <img alt="Creative Commons License"
        style="border-width:0"
        src="http://i.creativecommons.org/l/by-sa/3.0/88x31.png"
        /></a>
      <br/>
      The <span xmlns:dct="http://purl.org/dc/terms/"
        href="http://purl.org/dc/dcmitype/InteractiveResource"
        property="dct:title"
        rel="dct:type">Balisage 2011
          Feedback Forms</span>
      by <a xmlns:cc="http://creativecommons.org/ns#"
        href="http://balisage.blackmesatech.com/2011/feedback/"
        property="cc:attributionName"
        rel="cc:attributionURL">Black Mesa Technologies
        LLC</a>
      are licensed under a
      <a rel="license"
         href="http://creativecommons.org/licenses/by-sa/3.0/"
         >Creative Commons Attribution-ShareAlike 3.0
         Unported License</a>.</p>
  </div>

</body>

[Note: strictly speaking, as those who go and look at the HTML coding of the main Balisage site will discover, this is not “the same overall document structure” as the main Balisage pages. For reasons I won't go into here, the main Balisage site uses XHTML tables to lay out the pages. I usually try to avoid tables, so the forms use div elements with CSS style rules to govern the layout. Apart from avoiding invidious comments from those who disapprove of using tables for layout purposes, I find the documents somewhat easier to navigate and edit this way.]

They embed the appropriate material. The header embeds the Balisage logo:

<div class="header">
  <a href="http://www.balisage.net/">
    <img src="bflib/Balisage-2011-logoType.png"
         width="35%"
         alt="Balisage 2011 logo"/>
  </a>
</div>

And the navbar embeds a suitable set of links.

<div class="navbar">
  <p class="upbutton">
    <a href="http://www.balisage.net/">Balisage 2011</a>
  </p>
  <p class="upbutton">
    <a href="../../">Balisage at Black Mesa Technologies</a>
  </p>
  <p class="downbutton">
    <a href="http://www.balisage.net/2011/Program.html">Program</a>
  </p>
  <p class="downbutton">
    <a href="index.xml">Balisage 2011 Feedback Forms</a>
  </p>
  <p class="downbutton">
    <a href="conference.xhtml">Conference Feedback</a>
  </p>
  <p class="downbutton">
    <a href="symposium.xhtml">Symposium Feedback</a>
  </p>
  <p class="downbutton">
    <a href="speaker.xhtml">Speaker Feedback</a>
  </p>
</div>

It turns out to be psychologically helpful to have the form appropriately styled, both for me in developing it and for those whom I ask to review draft versions of the form. It’s so helpful, in fact, that one of the first things I do, in developing a form for a particular site, is to create an XForms template for the site, with

the namespace declarations for XHTML, XForms, XML Events, XSD, and any other namespaces that may be needed (extra namespace declarations cause no trouble, and missing ones cause a lot);
a link to the standard site stylesheet, or (if the standard site stylesheet uses tables) an equivalent stylesheet that provides the correct look
the high-level document structure needed by the site stylesheet
dummy headings and body text, using Greeking (‘lorem ipsum …’)

XForms is designed to allow forms to be integrated nicely into a site’s normal look and feel; the template makes it easier to do that consistently across all the forms used on a given site.

2012 01 16 cmsmcq XForms Comments Off Permalink

Another example of XForms

[9 January 2012]

In recent years I’ve spent a fair amount of time telling people about XForms as a method for making special-purpose XML editors. From time to time people ask me what sorts of things it’s possible to do in XForms, and by implication what sorts of things don’t fit very well in XForms. It’s a good question, but I don’t know a good way to answer in words. The only way I know to answer is to show some examples of things done in XForms.

In that connection, perhaps it’s worth while to point to an XForms application I put together last year for Balisage 2011. The organizers of Balisage place great weight on feedback from participants, and we’ve always used paper feedback forms distributed to participants on the last day of the conference. Paper forms have the drawback of only being in one place at any given time, and since the organizers don’t all work in the same location, most of the organizers only got a chance to look at the feedback forms on the afternoon after the conference ended, before everyone went home. (Yes, we could have had them photocopied, but we never got around to it.) So last year I suggested we do electronic forms, in addition to the paper forms (which we entered into the electronic system by hand, afterwards).

The forms we ended up with (all pointed to from http://balisage.blackmesatech.com/) illustrate one kind of application it’s easy to do in XForms. To answer, up front, a frequently asked question: no, they don’t do anything you couldn’t do in Javascript or HTML Forms plus a little bit of Javascript. (Javascript is a Turing-complete language; how could any technology do anything that could not, in principle, be done in Javascript? Asking if XForms can do things you couldn’t do in Javascript is like asking whether the XForms spec contains a refutation of Gödel’s Theorem.) Doing them in XForms made these forms easier to develop and debug, and XForms provide XML output, which means the forms are easier to summarize and analyse than they would otherwise be. I have written conventional HTML forms interfaces to generate XML, so I know it’s possible. I also know it’s tedious; XForms is much much more convenient.

These feedback forms posed a few interesting design challenges, and I went through several iterations, bugging my colleagues on the organizing committee for feedback until I suspect most of them were heartily sick of the whole thing. The various alternatives are worth some discussion; in subsequent posts I’ll discuss the issues and some of the alternative ways of handling them in XForms.

2012 01 09 cmsmcq XForms Comments (2) Permalink

Pierazzo on digital diplomatic editions

[2 January 2012]

A new issue of Literary and Linguistic Computing arrived not long ago. I’ve been meaning to note that it contains an article I hope will become standard reading for anyone involved with the digitization of texts and manuscripts: Elena Pierazzo’s thoughtful essay under the title “A rationale of digital documentary editions”. (LLC 26.4 (Dec 2011): 463-477.)

Dr. Pierazzo is a member of the team responsible for the Jane Austen’s Fiction Manuscripts Digital Edition and she has used her experience with that edition to reconsider the question are digital editions different from printed ones? … Do they represent an advancement of textual scholarship or just a translation of the same scholarship into a new medium? My own inclination is almost always to stress the continuity of scholarly concerns here as more important than the discontinuities of the technologies pressed into the service of scholarship, but Dr. Pierazzo reaches the different conclusion that digital editions are “substantially different” from print editions. She begins her argument by defining her terms and discussing some central questions (“What is a diplomatic edition?” “What does a diplomatic edition contain?” “Once you start identifying features to encode, where do you stop?”). She takes a firm stand against the view that it’s possible for an edition to encode everything about a source document (so what does an edition contain? A selection of the available information. She concludes her survey of recent thinking about the topic with the remark that

It is only with the advent of digital editions that we have started to understand that what we need is scholarly guidance …, that we need to rethink the reasons why we make our transcriptions, and that this approach should apply to print and digital editions alike.

She then proceeds to make a start on the task she has identified, listing a number of features (or rather, classes of features) which may be recorded, or elided, in a digital edition, and proposing five criteria for deciding whether to include or exclude them:

the purpose of the edition
the needs of prospective readers
the nature of the document
the capabilities of the publishing medium
cost

In the section on the purpose of the edition, she uses the decisions made by the Austen project to illustrate the kinds of considerations that arise, and devotes a useful couple of paragraphs to “What was not encoded”. As the last two items in her list of criteria suggest, while she argues that we need scholarly guidance about what information about a manuscript can usefully be recorded, she also takes a pragmatic view of the limitations imposed on any project by finite resources. The essay is, in the nature of things, overtly concerned only with text-bearing objects like manuscripts. But many of the concerns addressed will bear also on other forms of cultural artefact.

A wonderful piece; no one engaged in digitization of cultural heritage materials should miss it.

2012 01 02 cmsmcq Editions
Preservation
TEI Comments Off Permalink

Balisage 2011

[11 August 2011]

Last week, Balisage 2011 took place in Montréal.

As one of the organizers, I should not brag overmuch about the conference, but I can’t resist saying that on the whole it seemed to go fairly well this week. (But hey, you don’t have to take my word for it. Cornelia Davis of EMC, who gave a well received talk about Programming Application Logic for RESTful Services Using XML Technologies has written a blog post describing her experiences at Balisage 2011. Read it!)

Allen Renear (with collaborators) and Walter Perry gave thoughtful and thought-provoking papers on the nature of identity and the role of identifiers (rather dense, and probably not to everyone’s taste — I suspect some found them less thought-provoking than just provoking). There were case-study reports on ebook deployments, the markup of supplementary material in electronic journals (huge issue for the maintainers of the scholarly record in science), and the revival in XML of an old SGML project whose server died. Michael Kay and O’Neil Delpratt talked about their work measuring the performance benefits of byte-code generation in Saxon. Eric van der Vlist described a small Javascript library he has written for the support of multi-ended hyperlinks. Eric Freese reported on the state of EPUB3. Michael Kay gave an impromptu evening session on SaxonCE (XSLT 2.0 in the browser, now out for alpha testing). Jean-Yves Vion-Dury talked about a method of encrypting XML documents in such a way that a service provider can store them and perform certain operations on them (like running a restricted class of XSLT stylesheets or XQueries over them) without decrypting them, by the ingenious technique of encrypting appropriate parts (that’s the tricky bit, what exactly are the appropriate parts?) of the stylesheet or query. And there was much, much more.

Balisage 2012 will be in Montréal in August 2012. As Patrick Durusau put it:

If you see either < or > at work or anyone talks about them, you need to be at Balisage ….

Mark your calendars.

2011 08 11 cmsmcq Conferences Comments Off Permalink

Bilingualism as a specification tool

[16 May 2011]

The other day I discovered that ISO, the International Organization for Standardization, makes two documents called ISO/IEC Directives, Part 1: Procedures for the technical work and ISO/IEC Directives, Part 2: Rules for the structure and drafting of International Standards available on the Web. Since ISO (and IEC, the International Electrotechnical Commission) have been doing technical specifications for a long time, their rules are informative for anyone interested in standards or in standards development.

In Part 2 of the ISO/IEC directives we find the following astute observation:

4.5 Equivalence of official language versions

The texts in the different official language versions shall be technically equivalent and structurally identical.

The use of bilingualism from the initial stage of drafting is of great assistance in the preparation of clear and unambiguous texts.

Or as they say in French:

4.5 Équivalence des versions dans les langues officielles

Les versions dans les différentes langues officielles doivent être équivalentes sur le plan technique et avoir une structure identique.

L’utilisation du bilinguisme dès la phase initiale de la rédaction facilite l’élaboration de textes clairs et sans ambiguïté.

This coincides with my own experience: the XML specification became much clearer when Murata Makoto translated a draft into Japanese and raised question after question about the precise meaning of this passage and that. Some of the clarifications were purely editorial, but sometimes his questions revealed that some aspect of the spec had not yet been fully thought through.

I think the practice of describing systems both in prose and in a formal specification language like Z, VDM, Alloy, or ACL2 counts as another form of bilingualism and produces some of the same benefits. (And unfortunately, when not all members of the responsible working group are bilingual in the languages used, it also poses similar challenges.) This is on my mind because recently I followed a reference to John Guttag and J. J. Horning’s paper “Formal specification as a design tool”, which makes a very readable case for the use of formal specifications in the early stage of design for any system. Some of the arguments for using formal specification don’t transfer to other natural languages (or multiple programming languages), but it’s striking that Guttag and Horning recommend formalization at the design stage, in a way that strikes me as similar to ISO’s urging bilingual development of the document, not just translation of the finished product.

2011 05 17 cmsmcq Standards development Comments (1) Permalink

XForms course 16-17 June 2011, San Carlos, California

[30 March 2011]

I’m happy to announce that in June, I’ll be offering a two-day hands-on XForms course in San Carlos, California, in facilities generously provided by MarkLogic Corporation (itself a user of XForms technology).

The organization of the material will be substantially the same as in the earlier iterations of the course. And the rationale for XForms, as I understand it, remains as described in an earlier post to this blog; the course is directed to users of XML who want to use XForms to work with XML representations of information.

In case it matters to potential attendees, I’ll point out that the course will occur just before the Digital Humanities 2011 conference down the road in Palo Alto.

2011 03 31 cmsmcq Courses
XForms Comments (1) Permalink

How many attributes?

[9 March 2011]

Beginning programmers are often taught to avoid arbitrary limits in their software, but in reality it’s not unusual for programmers to write capacity limits into their software: fixed-length fields are often easier to deal with than variable-length fields. So we have fixed-length IP numbers, fixed-length addresses in most machines, and who knows what all else.

So I wasn’t surprised today when I found a hard limit to the number of attributes allowed on an XML element in an XQuery implementation I use and think highly of.

But every now and then, the fixed limit turns out to be too small. That’s one reason beginners are instructed to treat such limits with suspicion.

When I first learned about IP numbers, for example, I remember being told there were enough IP numbers for everyone in the world to have one, including all the people in China. That seemed an extravagant plenitude of IP numbers, partly because we didn’t really expect everyone in China to want one. We didn’t expect everyone in the U.S. to want one, either: at the time, the only computer anyone in the room used for network activities was a shared mainframe, so we needed far fewer than one IP number per person then: looking ahead to a time when people would want their microcomputers to be on the internet felt like being farsighted. We did not foresee (at least, I certainly didn’t) that individual machines without a human in attendance might also want IP numbers, so that the world would need more than one per human. So IPv6 became necessary. (If you don’t know what I’m talking about, don’t worry: sometimes limits that look reasonable at the outset turn out to be too low, especially if the system they are built into becomes highly popular.)

Memory addresses of 32 bits also seemed extravagant for a long time (that mainframe I worked on supported several hundred simultaneous users in a 24-bit address space; the actual hardware supported 31-bit addresses, but only specialized parts of the operating system used more than 24 bits). But nowadays more and more machines now are moving to 64-bit addresses.

So I also wasn’t surprised that the reason I learned about the hard-coded limit in the XQuery engine was that it turned out to be set too low. The software declined to handle some XML I need to work with for a client’s project. It turns out that current versions of the Unicode Character Database are available in XML, which makes my life a lot easier. But most of the many character properties defined in the Unicode Database are represented as attributes, which blew well past the limit of (are you sitting down? ready?) 32.

I was a little surprised by the actual value of the limit: 32 seems like a very low number for such a limit. Who in their right mind (I found myself thinking) would expect a limit like that to suffice for real work? Who, indeed? But upon reflection, I remembered that I’ve been using this XQuery engine without incident for at least two or three years, doing a good deal of real work. And all the XML I’d dealt with in that time came in under the limit. So while 32 seems like a low limit, it seems to have been fairly well chosen, at least for the work I’ve been doing.

The happy ending came when I wrote to the support list asking if there were some way to change the configuration to lift the limit. Less than ten minutes later, a reply was in my inbox (from the indefatigable Christian Grün, who must work very late hours to have been at his desk at that time of the night) saying that in current versions of the software (BaseX, for those who are curious, one of a number of excellent XQuery implementations available today), the limit has been changed to 2³¹, so now it can handle elements with a little over two billion attributes. (Hmm. Will that do? Well, let’s put it this way: if I wanted to experiment with a restructuring of the Unicode database that had one element per character property or property value, and a boolean attribute for each character indicating whether that character had that property [or that value for the property], the software could handle that many attributes. Actually, it could handle about a thousand times that many.

Moral: it’s not necessarily an error when software has a fixed capacity limit. But as a user, you normally need to take care that the limits are appropriate to your needs.

Moral 2: when you do bump your head on a limit of this kind, it’s very handy if those responsible for the software are responsive to user queries. Even better, of course, if they turn out to have fixed the problem before you asked about it.

2011 03 10 cmsmcq XML software Comments Off Permalink

XML Prague 2011

[17 February 2011]

XML Prague is just over a month away. I’ll be there again this year, the organizers having once more generously invited me to provide some closing remarks at the end of the conference.

I’d urge anyone within easy travel distance of Prague to plan to attend, but it turns out the conference is booked to capacity already. So there’s nothing to do, if you haven’t already registered, but wait ’til next year. (Well, that’s not really true. XML Prague provides live streaming video, which means you may be able to watch some of the talks even if you can’t be in the room.)

The theme this year is Web and XML; the suggested topics include speculation on why XML never became the usual way to prepare Web pages and the relations between XML and HTML 5 and between XML and JSON. The latter two, at least, seem designed to provoke some bottle-throwing; maybe they will succeed.

The papers include one by Alain Couthures on JSON support in XForms and one by Jason Hunter on a JSON facade for Mark Logic Server; this suggests that at least some XML users plan to co-exist with JSON by the expedient of making XML tools present and work with JSON as if it were XML. When one has to deal with information provided by others which is available only in JSON form and not in XML, it will be handy to view the JSON information through XML lenses.

Other papers describe XQuery in the browser (by way of a Javascript implementation from ETH Zurich, created by compiling the Java-based MXQuery engine into Javascript using Google’s Web Toolkit), XSD in the browser (from the University of Edinburgh), and XSLT 2.0 in the browser (from Saxonica), as well as a general consideration of XML processing in the browser (Edinburgh again). Some papers are about XML and information processing outside the browser: one team is translating SPARQL into XQuery, and Uche Ogbuji of Zepheira is presenting the Akara framework under the title “Spicy Bean Fritters and XML Data Services”, which makes me eager to to go have some spicy bean fritters (figurative or literal).

There are other papers on EPUB, on electronic Bibles, on XQuery optimization, and on a variety of specific applications, projects, and tools.

It should be fun. If you’ll be there, I look forward to seeing you there; if you won’t be there this year, you might sample the conference using the video feed (some people I know turn off the video as distracting and just listen to the audio, which takes less bandwidth). And if not this year, then perhaps next year.

Tagged #xmlprague

2011 02 18 cmsmcq Conferences Comments (1) Permalink

Why do some XML-oriented users avoid Cocoon 2.2?

[24 January 2011]

Over time, I’ve become aware that I’m not the only user of Cocoon 2.1 who has not yet moved to Cocoon 2.2.

In my case, the basic story is simple. When I first considered installing Cocoon 2.2, I expected installation to be very similar to installation of Cocoon 2.1; it is after all a decimal-point release. So I looked for a zip or tgz file to download and couldn’t find one. A little puzzled, I read the getting-started documentation, which informed me to my dismay that the first thing I had to do was install a particular Java build manager and start building an extension to Cocoon. (I have nothing whatever against Java build managers in general or Maven [the build manager in question] in particular. It’s just that the large majority of lines of code I’ve written in the last ten years are in XSLT, with Prolog and XQuery a distant second and third, with Common Lisp, Emacs Lisp, C, Java, Rexx, and other languages bringing up the rear like the peloton in a bicycle race. So no, I didn’t have Maven installed and didn’t have it on my list of things to do sometime soon or ever.) Now, I like Cocoon a fair bit and moving to 2.2 still seemed like a good idea, so I got as far as downloading Maven and working through its five-minute introduction before I went back to the Cocoon 2.2 intro and learned that the first thing I was to do was develop a Java extension to Cocoon. That was when I lost patience, said “This is nuts” and re-installed Cocoon using an old Cocoon 2.1 .war file.

Some months later I thought about it again and decided I should give it another try. I did. And essentially the same thing happened again.

In the time since then I’ve encountered two or three other XML-oriented people who have told me similar stories as explanations of why they are still using Cocoon 2.1.

Recently I’ve come to believe that the problem here (if it’s a problem — and as a Cocoon 2.1 user, I think it is) is simple: the Cocoon 2.2 documentation is written (I guess) by people who think of themselves in some primary sense as Java programmers, and they have written it (not surprisingly, if in this case perhaps not quite reasonably) for people much like themselves: i.e. people who want to use Cocoon as a framework to write and deploy Java code and/or to extend Cocoon. There is no highly visible documentation for Cocoon 2.2 aimed at people who want to use Cocoon’s out-of-the-box features to create XML-based web sites where all the heavy lifting is handled by XSLT transformations under the control of Cocoon pipelines, and who are more likely to be interested in writing XSLT than Java. Me, I got interested in Cocoon precisely because I could do nice things without writing Java code for it. I am happy to know, and occasionally to be reminded, that I can extend Cocoon if I ever need to by writing Java code; I’ve done that in the past and I expect to do it in the future.

I think Cocoon 2.2 could get better uptake among XML-oriented users if there were some highly visible documentation aimed at that demographic. It might also help if there were a document on “Cocoon 2.2 installation for Cocoon 2.1 users” to explain that while Maven is indeed targeted at Java developers, you really don’t need to be a Java developer to find it useful: you can just think of it as a Java-specific package and dependency manager or a much-smarter FTP client specialized for downloading and installing Cocoon in just the way you want it.

The view from Black Mesa