innerjoin

Using Mozilla? Downloaded the calendar extension? Want to export events in XML format? or create calendars which can be published on the web and imported?

• Publish, Subscribe, Import and Export
• To XML and back
• Round trips and URL's
  • Reimporting a URL parameter
  • Specifying URL as an ENTITY
• XML Transforms
  • Client-side and Server-side

Mozilla Calendar maintains clear distinctions between publishing, subscribing, exporting and importing data.

• Publishing is the saving a copy of your personal calendar to a location where others can make use of it.
• Subscribing is telling Mozilla Calendar to look at this location and display all the events and information in that file together with your personal data.
• Exporting is telling Mozilla Calendar to take an event and dump all the information about it into a separate file. You specify which format you want the data to end up in, it might be the iCal format as an .ics file, XML as .xcs or RDF formats
• Importing is telling Mozilla Calendar to read an event and include the information in your personal calendar (they call it the 'default' calendar in Calendar 0.8, 'My Calendar' afterwards).

The difference for the user is that, if they subscribe to a published calendar, if the source data changes then they see the results of the change, if they have imported an event however there is no reference back to the original source.

Mozilla Calendar's native format is iCalendar (see 'the source', RFC 2445, or a cross-referenced subset of the file format) These are conventionally held as .ics files. Information about events can however be exported (in the Mozilla Calendar) in several formats, iCal to .ics files, xCal to .xcs, RDF and CSV.

A test event in the iCalendar format might look like:

• BEGIN:VCALENDAR
• VERSION:2.0
• PRODID:-//innerjoin.org//NONSGML Innerjoin Events Publisher V1.0//EN
• BEGIN:VEVENT
• UID:200201012-8560@innerjoin.org
• DTSTART;VALUE=DATE:20020923
• DTSTAMP;VALUE=DATE:20020630
• URL:
•   http://www.somewhere.net/sometestpage.html
• SUMMARY:
•   some test summary
• DESCRIPTION:
•   some test description
• END:VEVENT
• END:VCALENDER

which can be exported in xCal format, giving a transliteration of the original data:

• <?xml version="1.0" encoding="UTF-8"?>
• <iCalendar>
• <vcalendar>
• <prodid>-//Mozilla.org/NONSGML Mozilla Calendar V 1.0 //EN</prodid>
• <version>2.0</version>
• <vevent>
• <uid>200201012-8560@somewhere.net</uid>
• <summary>some test summary</summary>
• <dtstamp>20020629T220000Z</dtstamp>
• <dtstart value="DATE">20020923</dtstart>
• <description>some test description</description>
• <url>http://www.somewhere.net/sometestpage.html</url>
• </vevent>
• </vcalendar>
• </iCalendar>

This is a slightly tidied rendering of the export, Calendar does not bother splitting up the data into separate lines. If .xcs files are given a text/xml MIME type by the webserver, Mozilla will treat them as 'well formed' XML documents (see moz-0-8/xcal.xcs).

The idea is that there is nothing new in the xCalendar format, the data is just wrapped up in a different fashion to let XML tools handle it.

There are two main criteria for exporting and importing data:

• The export format should be completely and formally correct according to the standards
• The process should allow 'round trips', all the data present in the original event should to be present in the export and this can be safely imported again

URL parameter

If you export an event in xCal format which includes a URL attribute from Mozilla, the URL is exported as a string:

• <url>http://www.somewhere.net/somepage.html</url>

If you then import it, that URL information is not picked up (Calendar 0.8). This may be a bug or that Calendar is not using the proper mechanism.

URL as ENTITY

The xCal draft spec (calsch archive) does not show URL's as strings, where they give examples they follow a far more formal route and define the URL as an ENTITY:

• <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN" "http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-02.txt"
  • [
  • <!ENTITY ref-20021012-5961 SYSTEM "http://www.somewhere.net/sometestpage.html" NDATA HTML>
  • ]>

and refer to that within the event

• <url uri="ref-20021012-5961"/>

The issues are:

• Calendar 0.8 does not export in this format - and the question is whether this is actually required by the spec or whether Calendar is cutting corners.
• It does not recognise events to be imported if they are in this format, if you download and try to import this test data, you get '0 events' in the pop-up dialog.

It is possible to transform the exported .xcs file, as it is XML, so it can be displayed in a browser. This can be done on the client or server.

Client-side Transforms

The transformation can, theoretically at least, be done at the client. This means that the browser downloads the XML, downloads the code to transform it (some XSL code) and does the conversion itself. Typically the XML data is converted to XHTML so that a browser can render it. Of course this means that you are prepared to target your pages at the subset of browsers which understand XML and can apply XSL transforms.

You tell the browser about the XSL by adding a separate line, a xml-stylesheet directive, to the .xcs file which says which .xsl file to use:

• <?xml version="1.0" encoding="UTF-8"?>
• <?xml-stylesheet type="text/xsl" href="xcs-mozilla.xsl"?>
• <iCalendar>
• .....

Server-side Transforms

If you want to serve your calendar as HTML from the server and not depend on the browser to do the conversion you need an application on the server to do the transformation work.

With Apache / Tomcat / Cocoon this is straightforward, or it is straightforward once you have Tomcat and Cocoon running and configured. You still include extra lines in the .xcs file, this time for Cocoon to recognise:

• <?xml version="1.0" encoding="UTF-8"?>
• <?cocoon-process type="xslt"?>
• <?xml-stylesheet type="text/xsl" href="xcs-cocoon.xsl"?>
• <iCalendar>
• .....

The server then takes the XML, follows the instructions in the .xsl file and serves HTML.

Note that both these options depend on an editing step to add the xml-stylesheet directive to the .xcs file. The difficult step is, of course, writing the XSL transform.