If you ain't got Style you ain't got Nothin'

Well we now know how to get some live data about the virtual filesystem. It's in the form of an XML document. Hmmmm...

What is the predominant technology for processing XML documents?
Come along. Come along. I haven't got all day.
Err, please Sir ... XSLT Sir?
Hmmm, very good Potter, you've been paying attention and no magic. Two points to Gryffindor!

... Sorry, slipped into a Rawlingesque fantasy for a moment. I really should take off this xsl:sorting hat. But when you've got an XML document why not transform it...

Try this application here

My eyes! My eyes! I can see!

As you will have found from the application, the transition from monochrome to colour can be quite a shock. Many people put the move from black and white to colour television as being the entire cause of the sixties social revolution. I put it down to the birth of unix, but maybe I'm missing something.

You're already well ahead of me by now. What you will have understood is that we are applying a style sheet to the result of the mls instruction. This can be seen in the second instruction which uses the xslt URA.

The overall details are that the result of the first instruction (available here) are put into a variable var:list. This variable is then used as the <operand> in the xslt instruction. As in the previous example there is an <operator>, this time the operator is a relative URI reference to the xslt stylesheet to use to transform the operand. Below we explain the file system and how relative URIs are resolved.

You can examine the xslt stylesheet transform1.xsl here but don't worry if you can't grasp one end of an xsl:template from the other. XSLT is just one of several xml processing technologies available, as we'll soon see.

VFS - Very Funny Sunshine

You are probably wondering about the virtual filesystem structure now that you've seen it in technicolor. The reason it's called the virtual filesystem is because it consists of more than one kind of underlying filesystem. Here we'll give a brief overview of the virtual filesystem, an in-depth discussion is available here.

The NetKernel allows applications and library modules to be dynamically discovered. Applications are composed from modules and each module has a URI address space of resources. Compressed modules use the JAR standard and are similar to war files.

The module filesystem is actually provided by a modified version of the Java classpath mechanism. The NetKernel allows module resources to be written to as well as read - in it's terminology a resource request may be a source or a sink. However a Module's resources are protected - they are immutable and cannot be overwritten. In order to support sinking, a module resource may be overridden in a scratch directory for the module. By default a module's scratch directory is located below [install]/scratch and stores state, intermediate processing results, or overridden module resources.

So what the heck is ffcpl:

Having gone into painstaking detail about the module filesystem, we can finally explain the ffcpl: URI scheme. FFCPL stands for File First ClassPath Later and is mapped as a request the Module Universal Resource Accessor. It's method for obtaining a resource is to first interrogate the SCRATCH filesystem and if the resource is not found next interrogate the module filesystem.

ffcpl: is extremely useful since it means that application modules can be shipped with default resources but they may be overridden by resources in the SCRATCH system. In short, using ffcpl: allows the SCRATCH filesystem to provide a transparent application state space. In a later section we discuss transactional creation and updates of resources.

ffcpl: is always used as the scheme to address module resources.

Access Control - You're barred

Within an application a request for a file: resource will retrieve a resource from the real filesystem of the host operating system. Administrators should take appropriate precautions to ensure user and group privileges are assigned correctly for their operating system and that NetKernel is running as an appropriate user.

A system guide to security administration is available here

You can choose your friends and with DPML you can choose your relatives!

As the final necessity for understanding the application we need to discuss how URI's are resolved. Returning to the XSLT we said that the <operator> contained a relative URI. But relative to what? In a web-server relative URI's are resolved relative to the URL of the request. In DPML we introduce the concept of the Current Working URI or CWU.

Anyone who's used a shell, DOS, bash whatever. Is familiar with the concept of the current working directory. It is the location from which resources relatively referenced within an application are resolved. The CWU is exactly the same.

By default the CWU is the URI of the idoc that is being executed. Usually, though not exclusively, an idoc will have come from a XAR and will have a URI in ffcpl: scheme. Therefore usually relative resources are also resolved using ffcpl:. It is not necessary to dwell on the CWU, generally we treat relative URI's just as we do in a web-server, however later we will show how the CWU can be modified at runtime.

Include me in.

Lastly, many XML technologies allow external resources to be included but don't specify how they are actually to be obtained. The most obvious example is XSLT with xsl:include and xsl:import. Fortunately the NetKernel takes care of this for us. The XSLT accessor, and several others that consume external resources, may reference resources using URI's. These may be absolute or relative and can use ffcpl: , file: or http: schemes and the kernel will take care of providing the resource to the accessor.

Summary

In this section we discovered the xslt accessor. We also learnt a little about the Virutal File System.

In the next section we'll stop messing about...