Virtual Filesystems Are Virtual Office Documents

Use libferris, XML and XSLT to create virtual filesystems and virtual documents.

Virtual filesystems can be made into writable virtual office documents.
The old UNIX slogan “everything is a file” together with the xsltfs://
virtual filesystem allows for transparently editing relational databases,
RDF and arbitrary XML with OpenOffice.org.

The libferris virtual filesystem presents both files and their metadata as
a virtual filesystem. The boundaries of what is considered a filesystem
by libferris include such interesting data sources as PostgreSQL, LDAP
and
Firefox as well as standard Web items, such as HTTP, FTP and RDF.

Many virtual filesystems allow directory contents to be synthesized from
other directories. The classic example of this is a union filesystem
where a collection of existing filesystems are taken as input to generate
a filesystem showing the set union of the base filesystems.

Recently, the libferris filesystem has gained support for performing XSLT
on a filesystem and exposing the result as a virtual filesystem. To
keep things simple, I refer to the original virtual filesystem as
the input filesystem and the filesystem that results from the XSL
transform as the translated filesystem. As the main use of XSL is to
describe translations on trees, this fits nicely for the use of creating
translated filesystems.

Although there are differences between a libferris filesystem and the XML
data model, there are also many similarities. A file's contents map
to the text content of an XML element. A file's metadata is exposed by
libferris as Extended Attributes (EAs), which map to XML attributes on
the file's XML element. A notable difference between a filesystem
and an XML data model is that the document ordering in XML is not always
easy to preserve. To keep the mapping simple, a file can generate
only one text node in an XML document. Technically, an XML element can have
multiple text nodes as children.

Because of the close relation with the XML data model, the libferris
filesystem supports viewing any filesystem as a Document Object Model
(DOM), which is created on demand. The inverse also is true: you can expose
a DOM as a filesystem. As libferris can mount XML as a filesystem, the
lines between what is a filesystem and what is XML are somewhat blurred.

Many modern applications store their documents as XML files. As
filesystems and XML can be interchanged with libferris, this allows you to
use those applications to edit filesystems directly. The main problem
with having such applications edit filesystems directly instead of XML
is that the schema of the application's XML file usually does not match the
layout of the filesystem.

This is where xsltfs:// can be used to create a translated filesystem
that matches the layout the application is expecting. For example,
you could take a table in a PostgreSQL database as the input filesystem
and have the XSL massage that table into a virtual spreadsheet file,
which you load into OpenOffice.org.

The possibilities become even more interesting when write support in the
translated filesystem is considered. After you have made some changes to
the above virtual spreadsheet file in OpenOffice.org, you
“save” the file.
The filesystem then applies a reverse XSLT and updates the input
filesystem (in this case a PostgreSQL table) to reflect your changes.

To support this, you have to have two XSL files. The first stylesheet
translates an input filesystem into the format you are interested
in. The second XSL file (the reverse stylesheet) provides the inverse
translation. In the future, the second XSL file should become optional
if it can be inferred from the actions of the initial translation.

Reverse stylesheets can specify updates either using explicit URLs for
each file to change or relative paths. The explicit URLs method expects
the reverse stylesheet to specify the absolute URL for each file to
be updated. This can be convenient for xsltfs:// applications where
URLs play a role in both the source and translated filesystem. For
example, when editing some RDF files with OpenOffice.org, the subject URI will
be available to allow the reverse stylesheet to use explicit updates.

The relative paths method is conceptually similar to applying diff and patch to
your filesystems. The reverse stylesheet generates a list of changes to
make using a relative path for each file to change. Some options from
the patch utility are available to the reverse stylesheet as well. The
root element can contain a strip attribute that works similarly to the
strip option of patch. The autocreate attribute, when set to true, will
make libferris try to create new files where the reverse stylesheet
specifies a relative path that does not exist in the source filesystem.

Currently, both reverse stylesheets must supply the entire contents of
each file to update. This is not a major drawback, as that information
already will be fully available in the translated filesystem.

The following sections show two uses: creating new virtual filesystems
and directly interacting with them from the console and creating virtual
office documents. This is followed by some advice for creating custom
stylesheets by hand.