Caltrop - an XML/XSLT calendar toy

The Goal | What happens and how to make it happen | How it works | To Do | What I learned

Note about this URI...

This is going to have a schema describing the XML/XSLT calendar system that I am building. But at the moment it is a placeholder for the Namespace - http://www.w3.org/2000/09/calendar/alpha1 - please use that exact string if you are going to link to it (can't imagine why you would at the moment - the thing is an alpha that doesn't work yet), since the HTML version may disappear by and by or morph into some other form.

The goal:

Produce a calendar system implemented in XML, using XSLT to generate various views of the calendar. The idea is that this will allow multiple content-types to be generated (I was initially looking for XHTML and iCal to be generated from one source), and that it is relatively easy to add data. It's really just a database application - it could be done in SQL/PHP (which is how I was initially going to do what I wanted) but this seems like a neat implementation demo like this. It struck me that we could also use the source to provide different calendars.

How it works

The XML source document uses a schema that I am in the process of making up. There is an XSLT transform to produce XHTML (for the WAI Conferences page - the original motivator for this work). They are linked, so anyone with an XSLT browser should get the calendar list. There is also an online version of the service that can be used (but it produces an xml file, so if you can't deal with those you need to save it and pretned it is HTML..

At the moment there is a calendar element, with any number of event elements as children.

each event can have the following attibutes (the xlink namespace prefix refers to http://www.w3.org/1999/xlink throughout)

date

The date of the event. (this is a start date, and should be expressed as the standard schema date format @@reference)

xlink:href

A URI for information about the event

An event can have the following children:

name

a name for the event. This is PCDATA

type

a type for the event. This should be an RDF property as soon as I figure out a decent RDF schema for it, and could probably be an attribute of the event element.

country

The country where the event is taking place. (Haven't figured out what to do if it takes place in cyberspace yet - maybe that is a country). There are plenty of schemes for this - the two letter codes must be an RDF schema somewhere.

location

A more detailed location. At the moment this is just PCDATA, but it might be useful to make it a description of a location, and allow an attribute which is an RDF property really describing a place/telephone number/irc channel/...

topic

This is probably a good candidate either to be an RDF property, or a PCDATA description plus an RDF property attribute

org, contact and desc

PCDATA for the organisation hosting it, a contact, and a description of the event. Each of these can have an xlink:href attribute giving a URI for each of these.

rsvpdate

Date by which a response or registration is required. I am not sure how to handle multiple deadlines (for example in an academic conference abstract deadline, paper deadline, registration deadline...) yet - maybe they should have a schema for deadline types. This could easily be an empty event.

language

the natural, or humanlanguage in which the event will be conducted. This is an empty element, and has an xml:lang attribute for the language required. (Is this a legitimate use of xml:lang ?)

acl

I am not sure what this looks like yet. It is to provide control over who can read (or do other things with?) the event. (Note that it is a bad idea to serve bare xml source and a transformation that will remove things so people don't see them). I guess this is expressed in RDF.

To Do:

• Add transformations to other formats, as well as the transformation to XHTML
• Write an XML schema for it (at the moment I don't have one, since I haven't really figured out what the scheme I am using is. (Just one of the reasons this is an alpha <grin/>)
• Write an RDF schema for it
• Implement a mechanism for choosing what kind of events we want (which needs some scheme of its own)
• Find someone who is happy adding content :-)
• Make it output stuff that can be XSLT'ed back to the source format (and provide appropriate XSLT to do so)
• Work out how to deal with things that are going to repeat. I think this is a matter of learning some more XSLT.
• Work out how to provide access control - partially in the schema, partially in putting this online (which probably requires system specific magic at the moment)
• Make an HTML form interface for adding events
• Oneday make an Xform to add stuff (or ask Xforms group to do so...)

What I learned:

Want more out of stylesheet linking

There is no sepcified way to get an XML document linked to several XSLT sheets that produce different content-types (for example HTML, iCal, RDF, SVG all seem good targets for a calendar) and select according to the type that I want. I don' think it can be done to select for languages either, although I might be wrong there and it might be a trickier problem. I should read the CC/PP stuff - maybe that is the answer I need to be looking at, but ther are implications for xml-stylesheet and for use cases of Xlink.

The value of this would be that authors could use a tool to create some XML data format, and another tool to create some XSLT sheets, and then just put them on the web and not have to worry about talking to their sysadmin about how to make content-negotiation work on their particular server.

Personal value

I learned some XSLT. And something about XML Schema.