representing a directory structure in XML

[James Owens]

I'm a relative newbie, interested in storing the information from several
server directories and subdirectories in XML so that I can present it
selectively using XSL (all files updated today or last MOnday, files from
several drirectories in alphabetical order, things like that).

To represent directories and subidrectories, is it advisable to nest the
same element:

<directory>
<directory>
<directory>

or is there a better way?

 

[Tjerk Wolterink]

I'm a relative newbie, interested in storing the information from several
server directories and subdirectories in XML so that I can present it
selectively using XSL (all files updated today or last MOnday, files from
several drirectories in alphabetical order, things like that).

To represent directories and subidrectories, is it advisable to nest the
same element:

<directory>
<directory>
<directory>

or is there a better way?



--
"For it is only of the new one grows tired. Of the old one never tires."
-- Kierkegaard, _Repetition_

James Owens, Ottawa, Canada

You can create your own xml structure, so
you can represent directories and subdirectories in many ways.

lik this

<dir>
<dir name="directory1">
</dir>
<dir name="dir2">
<dir name="subdir"/>
</dir>
</dir>


or like this:

<dir name="/directory1"/>
<dir name="/dir2"/>
<dir name="/dir2/subdir"

There are many ways.

 

[Peter Flynn]

You can create your own xml structure, so
you can represent directories and subdirectories in many ways.

lik this

<dir>
<dir name="directory1">
</dir>
<dir name="dir2">
<dir name="subdir"/>
</dir>
</dir>


or like this:

<dir name="/directory1"/>
<dir name="/dir2"/>
<dir name="/dir2/subdir"

There are many ways.

True, but hard-naming subdir or directory{1|2...} is a case of premature
binding. I think the nesting of directory as originally suggested is
probably fine for this purpose.

///Peter

 

[Tjerk Wolterink]

Tjerk Wolterink wrote:




True, but hard-naming subdir or directory{1|2...} is a case of premature
binding. I think the nesting of directory as originally suggested is
probably fine for this purpose.

///Peter

I dont know what you mean, the names directory1, or subdir are just
examples... the attribute name stands for the name of that directory.

 

[Richard Tobin]

To represent directories and subidrectories, is it advisable to nest the
same element:

<directory>
<directory>
<directory>

There is no reason to avoid nesting elements with the same name if
that reflects the structure you want to represent, which it does in
this case.

-- Richard

 

[Peter Flynn]

I dont know what you mean, the names directory1, or subdir are just
examples... the attribute name stands for the name of that directory.

Sorry, you're quite right, and I didn't read carefully enough.
Serves me right for doing news too late

///Peter

 

[James Owens]

Thanks for the replies. I'll go with nesting if there's no problem with
it. (For some reason, none of the books I've read so far have examples of
nested elements.)

 

[Ken Starks]

I'm a relative newbie, interested in storing the information from several
server directories and subdirectories in XML so that I can present it
selectively using XSL (all files updated today or last MOnday, files from
several drirectories in alphabetical order, things like that).

To represent directories and subidrectories, is it advisable to nest the
same element:

<directory>
<directory>
<directory>

or is there a better way?



--
"For it is only of the new one grows tired. Of the old one never tires."
-- Kierkegaard, _Repetition_

James Owens, Ottawa, Canada

You might like to look at the kind of xml that the Apache
Cocoon project produces. It is the nested variety that you
proposed, with most of its workload carried as
attributes.

In fact, I reckon you should download and install Apache and Cocoon,
even if you only use for it is as a environment for learning
xsl-t and xsl-fo. Its NOT easy, however.

see 'Guide to using Cocoon for Directory Listings'
----------------------------------------------
at the bottom of this message, which I hope contains
enough to get you going.


You wrote of
'storing the information from several
server directories and subdirectories in XML so that I can present it
selectively'

There is no real need to __store__ it as xml. The
Cocoon system will recalculate it on-the-fly, and feed
it to the xsl that you write.

Finally, it will spit it out using (if required) a non-xml
format, but you may prefer to skip this step for now, and
produce xhtml as the final product.

All you have to do, once the system is set up, is type a url of a
particular 'pattern' into your browser. Although this may look
like a typical hierarchical file-path, it doesn't have to resemble
your actual file system at all.

The crucial thing about this (for a 'relative newbie' ) is that
once you have a bare-bones Cocoon pipeline working that starts with
the supplied 'Directory Generator', you can spend 100% of your
time playing around with the xsl stage, which I guess is what you
want.


The 'Cocoon' component you need is called the
'DirectoryGenerator' and it produces (using
a namespace prefix of 'dir:' ) something like:

<?xml version="1.0" encoding="utf-8" ?>

<dir:directory
name="cocoon"
lastModified="1032027000636"
date="14/09/02 19:10"
xmlns:dir = "http://apache.org/cocoon/directory/2.0" >

<dir:directory
name="mount"
lastModified="1031537875786"
date="09/09/02">

<dir:file
name="Hi.txt"
lastModified="1031537875786"
date="09/09/02"
size="2245" />


</dir:directory>
</dir:directory>


<--! ************** variations follow ************* -->

To use it, you can specify some parameters, in the 'sitemap'
which is another xml file.

<!-- defaults to 1, which is the depth to which
recursion into the subdirectories will happen) -->
<maparameter name="depth" value="5" />


<maparameter name="dateFormat" value="dd-MMM-yyyy hh:mm:ss />

<!-- leave the next parameter out (which is simplest for a beginner)
to get the directory tree starting at the current folder
The directory from which the generator was called always
gets an extra attribute
requested="true"

-->
<maparameter name="root" value="cocoon" />


<!-- the next parameter is a regular expression which tells
the generator which file and folder names to include -->
<maparameter name="include" value=".*" />


<maparameter name="exclude" value="\.bak$" />


<--! ************** variations ( of
the DirectoryGenerator ) follow ************* -->


Cocoon also has some specialist directory Generators.

A. ImageDirectoryGenerator
--------------------------

..... selects JPEG and GIF files and adds attributes
for the width and height of each image


B. MP3DirectoryGenerator
------------------------

..... selects mp3 files and adds lost of attributes such as
frequebcy, bitrate, mode, variablerate, title, artist, album,
comment, Etc which it extracts from the mp3 embedded data.




By the way, if you _do_ want to roll your own xml for
directory structure, the task is given as an example sub-task in
the O'Reiley book 'Python and XML', where the main task is to
build a file of 'thumbnails'. The python script index.py
does the work; make sure you don't leave it in the
state where it follows symbolic links as well as true
file-hierarchy children, or you might well hit an
infinite loop. This caution applies to other programmes you
might write as well.


It would be easy to modify this script to extract information
sometimes embedded (like the mp3 example above) in certain
pixel graphics formats. Last time I looked, the Cocoon version
didn't do that, I don't know why not, and only dealt with
jpegs and gifs.




'Guide to using Cocoon for Directory Listings'
---------------------------------------------

There is a sample 'DirectoryLisings' project in
path.to.cocoon-2.1.5/webapp

As an experiment ( but NOT unless your server is
secure from intruders ) let us do Direcory Listings
of part of your system, starting at

path/to/where/to/start

Go into ..webapp/DirectoryListings, and open
'sitemap.xmap' in your editor.

Actually, if you are cautious, perhaps you should first
save a copy to a version control system or other backup, in
case you mess everything up.


copy (twice) the two nested elements
<mapipeline>
<map:match pattern="**.xml" >

blah blah blah

</map:match>
</mapipeline>


Edit the copies as follows:

<mapipeline>
<map:match pattern="**.Homexml">
<map:generate type="directory" src="/path/to/where/to/start/{1}" >
<maparameter name="depth" value="7" />
<maparameter name="reverse" value="true" />
<maparameter name="root" value="path/to/where/to/start" />
</map:generate>
<map:transform src="style/xmllist.xsl" />
<map:serialize type="xml"/>
</map:match>
</mapipeline>



<mapipeline>
<map:match pattern="**.VersionOne">
<map:generate type="directory" src="/path/to/where/to/start/{1}" >
<maparameter name="depth" value="7" />
<maparameter name="reverse" value="true" />
<maparameter name="root" value="path/to/where/to/start" />
</map:generate>
<map:transform src="style/list2VersionOne.xsl" />
<map:serialize type="xhtml"/>
</map:match>
</mapipeline>


Make sure these two new items are safely inside the
<mapipelines> ... </mapipelines> part of the file.

********************** First Test **********************

Now, in your browser (eg Mozilla - it needs to be one that will
display xml without fuss:

http:8080/DirectoryListings/One/Two.Homexml

should produce the xml version of directory
path/to/where/to/start/One/Two/

************* Write your own xsl, and second test **********

When you have written suitable xsl to transform this to xhtml, and
saved it as
..cocoon-2.1.5/webapp/DirectoryListings/style/list2VersionOne.xsl

Your browser should display the xhtml when you type the url

http://localhost;8888/DirectoryListings/One/Two/VersionOne


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Now you can play with the xsl.

Add an entry to the pipeline, with its own 'pattern' and one or more
<xsl:transform> elements similar to those above, where the 'src'
attribute matches the filename of your xsl file in the 'style'
subdirectory of the DirectoryListings Project.

Note that you can daisy-chain more than one xsl transformation in
the sitemap, which sometimes makes for a cleaner design.

*******************************************************************

 

[Tjerk Wolterink]

Tjerk Wolterink wrote:




True, but hard-naming subdir or directory{1|2...} is a case of premature
binding. I think the nesting of directory as originally suggested is
probably fine for this purpose.

///Peter

I dont know what you mean, the names directory1, or subdir are just
examples... the attribute name stands for the name of that directory.