Virtual Filesystems Are Virtual Office Documents

 in
Use libferris, XML and XSLT to create virtual filesystems and virtual documents.
Manufacturing Filesystems with xsltfs://

Translated filesystems can be accessed through the xsltfs:// scheme. This filesystem can be interacted with using the libferris clients or exposed using Filesystem in Userspace (FUSE) through the Linux kernel.

As libferris allows you to see an XML file as a filesystem, the XML file shown in Listing 1 will be used as the input filesystem.

The XSL file shown in Listing 2 will create our translated filesystem from the input filesystem. It is important to keep in mind that although the input filesystem in this case is generated from an XML file, it could just as easily be data from a mounted LDAP server. The XSL will create two elements under the document root element. The file3 element will have the original contents of the virtual “file” for file3 in the input filesystem. The file7 will have the attribute myattr as its contents.

The translated filesystem can be used just like any other filesystem with the command-line utilities ferrisls, fcat, ferriscp and so on. The xsltfs:// URL scheme in libferris lives above most other URL schemes and allows you to materialize a filesystem at any point by supplying an XSL transform to apply. The location of the XSL files themselves is determined based on an xsltfs path you set in libferris. The use of an xsltfs path avoids embedding full stylesheet paths into xsltfs:// URLs. As the stylesheets are specified using a CGI-like syntax, avoiding the use of the / character means that there is no ambiguity for filenames in xsltfs://.

You can apply a stylesheet at any point in your virtual filesystem. The result of applying a stylesheet to the example.xml filesystem will become the contents of a directory rooted at the example.xml?stylesheet=example.xsl virtual directory.

Without any use of / in the xsltfs:// parameters, the filename and parameters together are used to specify the name of a virtual directory that xsltfs:// makes on demand. Because there is no unambiguity, you then can navigate directly into the translated filesystem rooted at this virtual directory. This is shown in the examples below.

Part of a filesystem is shown in Listing 3 to make things clearer. I have applied the foo.xsl to the example.xml file using the special CGI-like syntax to name a virtual directory. libferris creates this virtual directory for me to allow direct navigation into the translated filesystem. The rootElement is the root of the translated filesystem; in XML terms, it is the document root of the result of applying the foo.xsl stylesheet to the filesystem rooted at example.xml. Filesystems live inside the context subdirectory of xsltfs:// to allow other parameters and expansion to be done in xsltfs:// at a later time.

The xsltfs path can be set using the XSLT stylesheets page of the ferris-capplet-general configuration tool. In addition to setting the XSLT path with ferris-capplet-general, you can use the LIBFERRIS_XSLTFS_SHEETS_URL environment variable to pass in the path explicitly where your forward and reverse stylesheets are located. This makes using xsltfs with the FUSE module from shell scripts quite simple, as you do not need to install your stylesheet files. Stylesheets can be stored in any filesystem libferris can reach.

For the purposes of this example, I have the files and stylesheets stored in file://tmp/example. If I am running my examples from the example directory, it is sufficient to put . into my XSLT path—see the example in Listing 4.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Reverse stylesheet

Virtual Office's picture

Interesting, a great read Ben!
Using an explicit reverse makes updating a breeze! I like how you are able to modify the data on it's way back.

Just wondering, how do you find OpenOffice compared to other open source virtual office apps?

Dave

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions