xtech

XTech 2007: Thursday 17th May Afternoon

Jeni — Sun, 27 May 2007 23:03:24 +0100

UPDATE: Dare Obasanjo has written an interesting critique on using the Atom Publishing Protocol as the basis for general purpose sharing of data in the way that the Google Data API does.

Thursday afternoon had a few really interesting talks. I learned about the Google Data API (no longer called gData); Oracle’s use of XLink to represent relationships between documents, and the requirements that entails; using XSLT to create JSON to use Exhibit widgets; and using XMPP to enhance instant messaging.

Google Data API

Frank Mantek

The Google Data API is the unified API that Google offers to all its services, such as Google Base, Blogger, Google Calendar, Google Spreadsheets and so on.

Frank talked about how awful SOAP/WSDL is, in particular how two services developed in different platforms can’t talk to each other (which one might imagine is rather the point of Web Services). (Later, when challenged by a Microsoft guy about this claim, he revealed that he’d been a major developer of the SOAP/WSDL stuff at Microsoft, so knew exactly what he was talking about from bitter experience.)

So the Google Data API is a RESTful API, using the Atom Publishing Protocol with a few additions:

extra data model
querying
concurrency control
extra authentication

What this basically means is that you can query any of the Google services using HTTP, and get back an Atom document. The URI can contain queries (the precise nature of which depend on the service; Google Base, for example, uses a single URI request parameter that has a complex internal query syntax), and you get back the feed with the items that you’d requested. The Atom items themselves have the basic Atom elements, but then a bunch of service-specific elements that provide the extra information you need.

Listening to this talk I finally got what Tim Bray was talking about at the XML Summer School a couple of years ago: REST gives us verbs and Atom gives us objects and lists of objects. I didn’t get it before, because, after all, aren’t all XML documents objects? But I think the point is that Atom has a lot of the mechanics that you need for talking about objects built into it, and the extensibility necessary for adding your own information to it (which is what each of Google’s services are doing).

The really interesting part of the talk was where Frank started talking about what the problems (still) are. The problems I noted were:

Atom’s verbose
Google have to use <category> to indicate the kind of thing they’re representing (as opposed to using the document element which is what you’d do with normal XML documents)
the rel attribute is too vague
they made up their own markup languages, rather than reusing existing standards
they should be using ETags for concurrency control
they haven’t got any versioning (eek)
incremental updates are a problem; they don’t want to serve the whole Atom feed (to a mobile device) when only a small amount has changed, so what they do is have several feeds, each of which reveals a different part of the information

From Trees to Graphs: Evolving XML for building enterprise applications

Ravi Murthy

Ravi Murthy talked about the provision for defining links between documents in Oracle’s database, and their consequent requirements. Information Oracle’s XML database has a file system abstraction (every XML ‘object’ has a file path) with access control, versioning, metadata and protocol access. Within an XML ‘object’ stored in the database, they use XLink to represent the relationships with other objects. When you export the XML, the XLinks get resolved to create the XML document.

Using XLink to represent relationships between documents brings a whole new set of constraints that you might want to express in a schema language, or annotations that you can use to describe the links (depending on how you look at it):

The type of the linked resource (eg the document element’s name, substitution group or XSD type)
The scope of a particular reference, similar to the scoping of XSD’s identity constraints
That a particular link is acyclic (eg, given an XPath expression, keep evaluating it and make sure you never get back to where you started)
The kind of a link, one of:
- hard: the target of the link must exist, and cannot be deleted while this resource exists (but can be renamed) — these are similar to links in normal databases
- symbolic: trust the file path specified by the link and only resolve it on demand
- weak: like a hard link, except the target can be deleted, in which case the link becomes symbolic
The versioning of a link, whether it points to the “current” version of a resource or a specific version

These extra constraints are expressed as annotations on the definitions of xlink:href attributes in XSD schemas for the documents held in the database.

Ravi also talked a bit about expressing decomposition rules: how an XML document should be shredded when it gets put into the database. They use XPath to specify rules that indicate that particular elements should be placed at a particular filepath.

I was really flattered in the tea break. Chatting with a guy called Phil working at the University of Bath, who politely asked about my presentation, and after I’d explained how it was all to do with overlapping markup and that kind of hard-core theory he said: “You don’t look like a markup geek”. Me: “What, because I’m a girl?”. Him: “No, no, that’s not what I meant. You just look more Web 2.0-ey.” Max was there at the time, and labelled me “the Geekess of XSLT”, which I think clarified things. (Actually most of the people at XTech this year were Web 2.0-ey rather than markup geeks, but I’m glad I looked as though I fitted in.)

XML-powered Exhibit: A Case Study of JSON & XML Coexistence

Chimezie Ogbuji

“What’s Exhibit?” I hear you ask. Or maybe you’re more with-it than I am, but that’s what I was asking. Chimezie never really explained, but I kinda gathered that it’s a funky AJAX toolset for creating views of data by importing scripts and using magical IDs and extension attributes within web pages. The other phrase that Chimezie dropped in was Rich Web Application Backplane, which again I hadn’t heard of. Even having read the W3C Note, I still don’t get it. Ho hum.

Anyway, Chimezie made the point that while entering data using XForms is great, it’s too heavy-weight for viewing that data. Exhibit gives a lot more flexibility (take a look at the US presidents example), which enables users to explore data more freely. In Exhibit pages, you provide a JSON schema for your data, a number of lenses/views/widgets that you can use to view the data, then you embed the widgets in the HTML page and point it at the data source. The JSON schema indicates the type of a particular property (eg “country”), and gives labels for it (including a plural label (“countries”) and a reverse label (“country of”)) that it uses in the widgets.

But that requires JSON, right? Chimezie showed how easy it is (and it’s really easy) to transform data-oriented XML into JSON using XSLT.

You know, there are all these cool ways out there for viewing information, I just wish I had some really meaty data to use them on! Timelines are one thing, but I’d also love to find some data to employ in Gapminder or even in an interface like the one for the music of Philip Glass. Perhaps I should just mine Google Base, but I’d like it to be something personally or collectively useful.

Real-time user-to-user web with Mozilla and XMPP

Massimiliano Mirra

This talk was strong on motivation — the requirement to enhance basic instant messaging functionality — and strong on demonstration, with Massimiliano chatting and playing with a pre-programmed bot, but really weak on the technical details. It was only through the post-talk questions that we learned that what we’d seen was based on XMPP (the Extensible Messaging and Presence Protocol), which allowed DOM events to be passed between clients. Have to read the paper if you want to learn more.

XTech 2007: Thursday 17th May Morning

Jeni — Fri, 25 May 2007 22:34:18 +0100

On Thursday morning, I was down to chair the first session in the “Core Technologies” track. Two interesting papers: one on XForms and one on Google Base. Then I snuck on to the “Applications” track to hear about scientific Wikis and the trials of managing schema repositories.

XForms, REST, XQuery… and skimming

Mark Birbeck

Mark Birbeck, one of the developers of formsPlayer (and an invited expert on the XForms and XHTML WGs), discussed the rationale behind using XForms. The only thing that really stood out for me was the fact that he used an XML document to provide the labels for the form controls (in just the same way as you can use XML documents to provide the data in the form controls). That was quite neat, and made me think of the different requirements of data entry and data presentation: a topic that returned in Chimezie Ogbuji’s talk later that afternoon.

Another theme here, for me, was the use of declarative programming: you write a form, which is just some XML and leave all the technical stuff about submitting a PUT HTTP request to the XForms player. Mark talked about using WebDAV and eXist on the server to store the XML documents, and demonstrated using <oXygen/> to load and save documents. Hmm… I wonder if I should experiment with XForms and that Unicode database browser I was thinking about…

Google Base, a mashups database for the REST of us

Jeffrey Scudder

A very popular, thought-provoking, and slightly disturbing, talk on Google Base. So Google are asking us to upload data on anything (jobs, personals, cars, etc.) into their huge databases. And then they’ll serve us back that information (and other people’s information) in formats such as Atom, RSS and JSON, as well as standard web pages.

The thought-provoking bit, for me, was the fact that they don’t have any particular schema for each of these kinds of items. Now, I come from a knowledge engineering background where we’re very into ontologies and creating conceptual models and all that stuff. But Google don’t bother: you create categories and structure your data the way you want to, and they’ll serve it back in that way. But they look at all the data they have their hands on in order to decide how to display and serve information. So, for example, if I define cars with the property ‘shade’ but a hundred other people define them with the property ‘colour’ then on a feed that includes all our items, we’ll see the ‘colour’ property.

This is a kind of bottom-up ontology design: the properties of an item are the properties that other people think are important about an item. One thing that surprised me was that it looks like it’s not very intelligent yet: simple differences in case (like ‘color’ vs. ‘Color’) don’t seem to be detected, so I guess nothing else is. Time to dig out my old research on automated comparison of ontologies…

The slightly disturbing part? Well, Google are trying to get us to upload our data to their servers. And they’re not putting any limit on how much we upload. One member of the audience asked “What’s in it for you?”; Jeffrey seemed to have a hard time understanding the question and said something like “Better indexed information means we can give you better information”, but that doesn’t really answer the question. Presumably it’s all about being able to advertise to us better: the more data we upload, the more They know about us, the better targeted Their adverts can be.

What I found strange was the idea of uploading data to a central server. Surely the whole point of the web is that I put my data on my machine. I don’t have a problem putting the data together in a nice Atom feed so that Google can index it easily and pointing them at it, but I want to own it, y’know?

By the way, one thing that was apparent to me during this talk was how important it is that web pages look good with large font sizes, not just for people with poor eyesight, but also for when you’re demoing your cool web applications! The Google Base drop-down menus were impossible to see with increased font size because their height is fixed in pixels.

An Augmented Wiki for Interactive Scientific Visualization and Evolutionary Collaboration

Frank Marchese

On to the less well-attended “Applications” track. This talk was about supporting scientists (specifically biochemists) in providing side-by-side visualisation (of complex molecules) and textual analysis. Frank talked about a Wiki in which Jmol Java applets for visualising molecules are arranged side-by-side with standard journal articles. The articles themselves have links in them that animate the Jmol visualisation: highlighting particular groups of atoms, moving it to show a particular view, and so on.

It was kind of neat, as pretty pictures of molecules often are, but I didn’t think the Wikiness of the whole enterprise was really explored: I got the impression that the textual articles were basically static: you could add comments, but not collaboratively create an article about the molecule. Also, the link between the text and the animation of the molecule was through Javascript, as far as I could tell: I’d expect a declarative method of defining animations would make it a lot more accessible.

Real-world metadata registries; sharing concepts, schemas and semantics

Emma Tonkin

This talk took me back to the trials of creation of top-down conceptual models, focusing on the definition of metadata schemas. Unfortunately, there was a lot of philosophy and not many practical guidelines in the talk, and I didn’t get a lot out of it. One thing that Emma touched on, though, was the way that the meaning of a term can change over time, through:

extension or generalisation
narrowing or specialisation
amelioration (when a term gains approval)
deterioration or perjoration (when a term gains disapproval)

The latter two are particularly demonstrated by political correctness, whereby terms like “Eskimo” fall out of favour and “Inuit” becomes more acceptable (all highly culture-specific; see the Wikipedia Eskimo page for more discussion on what term to use).

The advantage of a principled conceptual model is that the concept itself and the term(s) you use for that concept are loosely coupled, so if a given term falls out of favour or becomes inappropriate, you can always decouple it. On the other hand, bottom-up tagging tends (I think) to have a 1:1 relationship between term and concept, so if the use of terminology changes you might be left with inaccurate tagging of legacy data. Maybe.

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>.

XTech 2007: Wednesday 16th May Morning

Jeni — Thu, 17 May 2007 21:50:59 +0100

Since there’s next to no ‘net connection at XTech 2007 (obviously the Web is not so ubiquitous as all that), I have nothing to do in the sessions but listen! Here are some thoughts about the sessions that I attended on the morning of Wednesday 16th. I haven’t included the keynotes not because they weren’t interesting but because I can’t think of anything to say about them at the moment.

XML and LINQ: What’s New in Orcas and Beyond

Erik Meijer (Microsoft)

I thought I’d better go to this one because I’m supposed to be talking about XML APIs at this year’s XML Summer School and LINQ, or XLINQ, is one of the hot topics. I’m not a .NET developer, so it’s all kinda passed me by thus far, and I’m not sure I really understand it now. (I’d welcome corrections and clarifications.) The three things that seemed to be important are:

You can get at information held in objects, databases or XML using the same syntax. (Erik showed accessing XML with faulty XQuery syntax, which made me and Priscilla Walmsley grimace at each other.) This means you can decide how you want to actually hold your data further down the line. A big distinction between previous attempts to work across paradigms is that the data doesn’t get converted, but the queries do. So you write your LINQ query in LINQ syntax and it gets mapped on to SQL to query your SQL database, or on to XQuery (I guess) to query your XML document. This all seemed to assume data-oriented information: I have no idea, yet, how or whether mixed content gets handled.
XML is a “first class datatype” in LINQ, so to create static XML you just write XML in your program (a bit like in XQuery). The example Erik showed included an XML declaration, which is just plain weird: dunno if that was an error or it’s a way of indicating what version of XML you’re using, or what. To create dynamic portions of the XML, you use <%=...%> “expression holes” which can contain .NET code, including calls to a new API for creating XML elements and attributes (a DOM replacement).
Erik talked about writing applications in .NET and then automatically refactoring them (with a click in a context menu) to work in client/server architectures, and refactoring again to work across several clients. Presumably this creates all the code necessary to make the application work with WS* messaging, so you don’t have to program it. This all sounded really dodgy to me: I don’t want to rely on a tool to make a language/approach/architecture usable.

There was an amusing digression into the art of rendering triangles, and thus three-dimensional models, with zero-width, zero-height, bordered <div>s in XHTML. And a mention of the “backbutton” problem that you get when you spawn tabs/windows in your web browser and then go back to your original tab/window and hit submit, which made me think that perhaps a RESTful architecture would make a whole lot of complexity go away.

Data Model Perspectives for XML Schema

Felix Michel (ETH Zurich), Erik Wilde (UC Berkeley)

Felix mentioned that I might be interested in his talk in a comment here, and sure enough I found it fascinating. He’s created a single-file representation of XML Schemas (consolidating schemas that, by virtue of using different namespaces, must be in different physical documents), and a set of XSLT 2.0 user-defined functions that provide access to and queries on the XML Schema information.

For example, you can go from an instance element in your document to its type, find out if it’s an extension or restriction, go to its base type, look at the annotations on it, and so on and so on. And all this in Basic XSLT 2.0 (the functions that work on instance elements traverse the instance document and schema in parallel to locate the element declaration that applies). You could use these functions to do everything you can do in Schema-Aware XSLT 2.0, with more flexibility, at the expense of performance.

He also mapped content models onto <occurrence> elements that encode the “follow set” for a particular occurrence, so you can easily answer the question “what elements could come next?”. I can’t immediately think of a way of using that information in a stylesheet, but perhaps he can describe one.

Anyway, I think Felix’s point was not to provide XSLT programmers with a set of useful functions, but to demonstrate the kind of standard, fairly light-weight, API that we might use to access XML Schema information. There was some discussion, in the development of XPath 2.0, of providing this kind of API, but getting agreement on XDM was hard enough!

However, my thoughts were veering off in different directions. To my mind, validation and annotation are separable processes, and the data types, element groups and linking behaviour that you might find useful on a data set are processing-specific. For example, it might make sense for one process to annotate the element <foo>2007-05-17</foo> as having the type date, while for another process (such as a transformation that deletes all <foo> elements) it’s unnecessary. I really don’t want to have to define an XSD schema for my entire schema just to indicate that the <foo> element is of type xs:date.

Just as it’s better to define the links between elements using keys, rather than relying on ID annotations made by a DTD, I think type annotations and node groups (why limit it to elements?) could be defined in the stylesheet. To give an idea:

<!-- all date attributes have the type named 'xs:date' -->
<ann:type name="xs:date" match="@date" />
<!-- h1, h2, h3, h4, h5, h6 elements are heading elements -->
<ann:group name="xhtml:heading" 
  match="xhtml:h1 | xhtml:h2 | xhtml:h3 | xhtml:h4 | xhtml:h5 | xhtml:h6" />
<!-- oh, and so's the h element -->
<ann:group name="xhtml:heading" match="xhtml:h" />

It’d be reasonably easy to give rudimentary support for ann:type($node) and ann:group($node) user-defined functions based on these, but they’d really have to be built into the XSLT processor to get full pattern support and to work with modularised stylesheets. This all requires more detail than I have time to write right now, but is it even worth pursuing?

XTech Creole presentation fallout

Jeni — Wed, 16 May 2007 21:48:47 +0100

Henry Thompson had a lot to say after my Creole presentation (open takahashi.xul?data=creole.data; requires Firefox) about the benefits of stand-off markup for linguistic information. From his overview, it seems that the NITE XML Toolkit that he’s been involved with represents overlapping linguistic data by holding atoms (here meaning the “lowest common denominator” shared pieces of data) and having multiple trees marking up these atoms. The trees are independently validated (since they are pure XML), with cross-hierarchy validation done through the query language. This is pretty similar to the XCONCUR approach, which augments a CONCUR-like multi-grammar validation with a Schematron-like constraint language.

Now, I have nothing against using constraint languages (like Schematron) to validate documents, but grammars (like RELAX NG) have big advantages. Most importantly, they are easier to write (if they’re designed properly), and tools can analyse them to do useful things, such as tell you what element or attribute is expected next. If it’s possible to write cross-grammar constraints in a grammar (like Creole) then why would you use a constraint language to do it?

I think the big difference between Henry’s domain and the one that I think will move overlap into the mainstream is between global and local concurrence. With global concurrence, entirely separate hierarchies are applied to the same data, so the natural validation mechanism is to use entirely separate grammars (with perhaps a few small rules to do cross-grammar validation where that proves necessary). With local concurrence, the vast majority of the document follows a single hierarchy with concurrence happening at a low level.

Actually, the best example for this doesn’t even involve overlap. Consider HTML paragraphs, which contain various inline elements such as ,  and <a>. It doesn’t make sense for these elements to contain themselves (strong text is neither made stronger nor negated by appearing in two  elements, and it’s not allowed for links to contain other links). So the natural model in Creole is

p      = element p { mixed { strong* & em* & a* } }
strong = range strong { text }
em     = range em { text }
a      = range a { attribute href { text }, ..., text }

This model allows <a> elements to appear within  elements, or vice versa, not because of the content model of  but because the two ranges are interleaved (and one arrangement of interleaved ranges is containment). It doesn’t allow any of these elements to appear inside themselves. It would be a real maintenance headache to have separate grammars for each of these inline elements, when most of each of the grammars (all the hierarchy down to the paragraph level) would be the same.

Actually, looking at NITE, it seems like it employs a data model that’s quite like LMNL’s, in that it has the concept of layers over atoms or ranges/elements. (Interestingly it looks like they get around the problem of identifying which ranges belong to which layers purely by using their name.) Another difference here might be that while I’m talking about supporting overlap in fairly heavily structured documents (like office documents), they’re really using fairly flat annotations, where there isn’t much of a grammar anyway. But I might have that wrong: need to do more reading. The other thing to investigate is whether they have any support for self-overlap (<phrase> elements overlapping other <phrase> elements): I kinda gather that they don’t.

Anyway, Henry also made the points that (a) that he doesn’t want a new syntax for overlap and (b) stand-off markup works very well thank you. To address the latter point first, I think stand-off markup works very well if you have the tools to support it. It’s fine if you have an integrated toolkit which can pull together and display the stand-off markup as embedded markup, and let you create ranges by highlighting text with a mouse. But the great power of HTML and other web technologies is that you don’t need to use a specialised toolkit to write it: you can just use a text editor and it’s all right there in front of you with no (or minimal) cross-referencing required. Frankly, I’m not interested in “core” technologies that require me to install a particular piece of software in order to make use of them (cf Erik Meijer’s talk on LINQ, which I’ll have to discuss another time). I expect to be able to write a document containing overlap as easily as I can write a normal XML document.

On Henry’s point about yet another syntax for overlap, I am more and more coming to the conclusion that overlap will hit the mainstream if we have a simple way of encoding overlap in normal XML documents, namely something along the lines of LIX. Interestingly, Yves Savourel’s talk on Applying the Internationalization Tag Set was quite inspirational in this regard, since the working group seem to have put together a standard that both provides a set of standard elements and attributes to guide localisation, along with a method of mapping elements and attributes in existing markup languages onto those ITS elements and attributes. I wonder whether a similar approach could be used with LIX… but I’ll have to leave those thoughts for another time.

XTech Preparation

Jeni — Sun, 22 Apr 2007 21:12:16 +0100

XTech 2007 is less than a month away! I’m going to be presenting on Creole: Validating Overlapping Markup in the Core Technologies track on Wednesday 16th May at 16:00. Yes, I know it’s really an Extreme paper, but (a) I’m not going to Extreme this year, (b) I’ll be reaching out to a slightly wider audience, and (c) I just cannot wait any longer to talk about Creole!

The only trouble is: how am I going to make overlapping markup interesting to all the Web 2.0 geeks? More to the point: how do I explain the elegance of Brzozowski derivatives without losing at least half the audience?