Extremism, 2006-08-11

Extremism: Day 4, Friday, 2008-08-11
David J. Birnbaum, djbpitt+xml@pitt.edu
Two things you think you know if you’ve never attended an Extreme Markup conference before:

1. Keynote addresses are boring and out of touch with the interests of the audience.
2. The conference is over before it’s over.

Anyone who has ever chaired a conference program committee understands that nobody wants the last slot. On my last program committee we called it “the death slot.” The attendees are tired from too much partying (er, coding), they’re leaving early to catch their flights, and their minds are already elswhere. But not at Extreme! Since the birth of the Extreme Markup conference in 2000, C. M. Sperberg-McQueen’s closing keynotes have been the soloist’s breathtaking improvised cadenza at the end of the concert, and when Michael plays, nobody leaves the hall. Because I’m not Syd Bauman, I’ll stop here, but not before saying that Michael’s keynote this year once again drew connections within the rich content of the most thought-provoking annual conference in the field of electronic text technology, and did so with Michael’s signature insight, humor, and eloquence. And, by the way, the rest of today’s concert program was certainly no slouch, with strong plenary papers on important topics by Yves Marcoux, Ann Wrightson, and Jeni Tennison. If you’re a first-timer who made the mistake of going home from Extreme early this year, you’ll know better next time.
In the first presentation of the morning, “A Natural-Language Approach to Modeling: Why is Some XML So Difficult to Write?” Yves Marcoux argued that one could use natural language features (such as text-before and text-after properties, or tool tips that appear when the user hovers with the mouse) to guide authors in the use of markup by showing them semantic features instead of just the less intuitive underlying syntactic structures. Yves suggested that such efforts could produce an XML-authoring counterpart to the well-known paradigm of literate programming, where the documentation happily lives alongside and supports the code. In the ensuring discussion, Wendell Piez noted that the features to implement this type of approach are already latent in existing technologies (such as CSS, as Yves had pointed out), and markup has long sought a comfortable point along the continuum between natural language, on the one hand, and forms, diagrams, and layouts, on the other. John Cowan noted that XSLT makes it easy to add this capability, much as unix crontab2english allows the user to deal with otherwise inscrutible cron syntax.
When Ann Wrightson spoke at Extreme 2001 and the power failed in the hotel in the middle of her presentation, her geeky audience helpfully shone their handy-dandy pocket flashlights on a whiteboard while Ann finished her talk. The equipment cooperated today, as, in “Conveying Meaning through Space and Time Using XML: Semantics of Interoperability and Persistence,” she talked about exchanging meaning (as distinct from data or information) within systems. For example, imagine a person with a chronic medical condition who is found unconscious while on vacation and needs to be treated by health-care professionals who do not know his medical history and cannot ask him about it. Now imagine that there are social care implications to the patient’s condition (e.g., he is unable to do the shopping for the infirm aunt who depends on him). If the social service agencies are part of the network, they are able to respond to the patient’s changing medical circumstances, but a patient in one system may be or interact with a client in another, and the systems must recognize where these concepts share semantics. Ann approaches this set of problems from the perspective of informorphisms (see her Extreme 2001 paper), where the shared record is designed for interoperability and is capable of recording a correspondence between a type in one record (e.g., a patient who is frail and unable to walk) and a different type in other (e.g., such patients get home care services). An interoperability layer needs to mediate between the human knowledge on either end, but only relatively simple structured data can be truly black box. Complex structured data standards requires sustained collaborative effort in a community with a very strong shared business need to make it work.
In her whiz-bang Takahashi presentation entitled “Datatypes for XML: The Datatyping Library Language (DTLL),” XSLT rock star Jeni Tennison not only described DTLL in detail, but also reminded us of the similarities between clients and toddlers. DTLL is an ISO/IEC JTC1/SC34 language for designing datatypes in RelaxNG. Jeni noted that XML Schema has primitive types that define value spaces in prose, but it does not permit new value spaces, so you cannot say, for example, that “white” =“#FFFFFF” because there is no color value space. Similarly, you also cannot introduce new lexical representations (e.g., your own date format), since you can’t map a new lexical representation onto the same value space. In DTLL every type has its own value space, and if two lexical representations of a given datatype map onto a same set of property/value pairs, then the values are considered to be equal. Much of the ensuring discussion concentrated on whether XML Schema was truly as restrictive as Jeni had stated (Michael disagreed, while Ann lamented “the arrogance of XSD in thinking you can define an adequate inventory of datatypes for any community”), and Jonathan Robie pointed out that if you define a new type only in terms of its lexical representation, you have to know about its operators if you want it to be interoperable with existing datatypes.
This year Michael’s closing keynote was entitled “Failing Upward.” He reviewed the presentations that had transpired over the four days of the conference against such background questions as what factors contribute to our failures and our successes, and how we distinguish among them. Michael noted that we learn more from failure than from success, since success narrows the margin of error, but not as definitively as failure, which provides a concrete example with access to traceback. There is a cost to overengineering, even if there is a more obvious cost to failure, and Michael invited us to contemplate what markup systems would be like if we feared failure the way bridge builders do. In his paper earlier at this conference, Dave Dubin showed how a series of sensible decisions led to degradation; Michael thinks this means that there was a failure, while Dave thinks it means an opportunity for improvement, and this may turn out to be just a rhetorical difference. Failure is surprisingly psychological in nature. If you work in an environment with nothing but success, you may become complacent, and ratcheting up expectations and thus raising the rate of (acknowledged) failure can be motivating. Validation is one of the success stories of markup languages because there is a clear failure mode, and validation lets us define clearly the set of inputs for a which a program must be prepared. If the software doesn’t cooperate, you know whose fault it is. But validation is a failure for markup languages because it suggests that people in markup languages are obsessed with success.
Tying these observations back into the conference papers, Michael noted that the conference exemplified failure as an option, and thus supported ratcheting up expectations. Why not demand that the standard of success for XSLT be that of a fully functional programming language? Why not demand or expect a compact notation? There may be reasons, but such questions reflect legitimate examples of failure as an option. Moving into a hortative mood, Michael concluded with a rousing invitation not to let fear of failure suppress our expectations: “Let us demand that our data be reusable between RDF and TM, since what we really care about is the information. Let’s demand that XML be easy to write in the editor interface sense (cf. Peter Flynn’s presentation) and semantically (Yves’s). Why not inch up the semantic content of XML by allowing microformats (Liam Quin’s presentation), and present a way to validate without deprecation (causing loss of face). We should identify potential failures that we can embrace and adopt. We want to fail upward. We want our failures to prompt us to solutions that leave us with more problems to solve. Let’s have a helix, not a circle. The only failure to fear is the failure to push our systems and our demands hard enough, to set our sights high enough.”
Quotable quotes:

• When people say “metadata” without asking what it’s for, they are turning off their brains in a very damaging way. (Ann Wrightson)
• This is the only conference I’ve ever attended where they are obvious about taking the suggestions and throwing themselves in the wastebasket. (Lynne Price about John Cowan’s signature randomizing implementation)

Bookmark these Extreme resources:

• Main Extreme Markup web site: http://www.extrememarkup.com/extreme/
• Extreme Markup papers: http://www.idealliance.org/papers/extreme/proceedings/dates.html
• Extreme Markup blog site: http://www.concretesyntax.com/

See you next year!