That's _almost_ suitable input - the XML source looks like this:

      <filesystem>
        <directory>
          <filesystemname>analysis-1</filesystemname>
          <filesystemdesc></filesystemdesc>

          <directory>
            <filesystemname>static</filesystemname>
            <filesystemdesc>Contains the output of a run of the
            QuickDiagnostic script.</filesystemdesc>

            <file>
              <filesystemname>QTDiagnosticLog.txt</filesystemname>
              <filesystemdesc>The file QuickDiagnostic
              generates</filesystemdesc>
            </file>

            <file>
              <filesystemname>QTDiagnosticLog.txt.log</filesystemname>
<filesystemdesc>stdout/err for QuickDiagnostic</ filesystemdesc>
            </file>
          </directory>

          <file>
<filesystemname>profiling_stopped_at_118728</ filesystemname> <filesystemdesc>A timestamp of the time the profile-stop scrip
            completed.</filesystemdesc>
          </file>

          <file>
            <filesystemname>bchd.tgz</filesystemname>
            <filesystemdesc>The bootchart compatible data, see
            below.</filesystemdesc>
          </file>

          <directory>
            <filesystemname>bash.1.1187799454</filesystemname>
<filesystemdesc>This directory, with the lowest pid, is a special. It contains the memorymap and symbols information for dynamite and
            the locally installed libraries it has linked
            with.</filesystemdesc>

            <directory>
              <filesystemname>analysisData</filesystemname>
              <filesystemdesc></filesystemdesc>

              <file>
                <filesystemname>libraries.txt</filesystemname>
                <filesystemdesc>A list of the libraries linked
                in.</filesystemdesc>
              </file>

              <file>
                <filesystemname>symbols.txt</filesystemname>
<filesystemdesc>All the symbols we can determine in each of the mapped libraries and their addresses.</ filesystemdesc>
              </file>
            </directory>
          </directory>

          <directory>
            <filesystemname>bash.2.1187799455</filesystemname>
<filesystemdesc>The analysis directories containing the new format
            of sample and region data.</filesystemdesc>
          </directory>
        </directory>
      </filesystem>

The names are placed in their own filesystemname tag so that you can use other tags within it. Principally this is to support <phrase>, plus tags that we've added specially for our product - for example, <targetos/>. (Actually, I meant to post that here, too - we've added our own tags - <targetos>, <productfilename> and so on, and use XSLT to expand them to the appropriate words when we build the documentation, because we couldn't find a better way).

The names 'filesystemname' and 'filesystemdesc' were chosen because I didn't know if it was acceptable to use generic-sounding 'name' and 'description' tags in such a specific context.

I extended the Docbook 5 RELAX NG schema to add these elements - I wanted the XMLMind XML Editor to have full support for visually editing these trees, so that was a requirement.

So currently my work consists of extensions to:

  - The RELAX NG Schema
  - The XMLMind CSS files for Docbook 5
  - XSLT to generate HTML and FO for these tags.

How do people generally distribute these enhancements - do they get rolled into the main Docbook schema, or is there some mechanism for distributing and managing these enhancements?

Thanks,

Geraint North
Principal Engineer
Transitive


On 10 Sep 2007, at 12:37, Dave Pawson wrote:

Geraint North wrote:
I often want to include example directory trees in my documentation. I've extended Docbook 5 to add the obvious tags (directory, disk, file) that can nest in the obvious way and include 'name' and 'description' tags, and I've modified the XSL stylesheets to produce nice PDF/HTML representations, like so:
http://geraintnorth.com/docbook_directories.pdf
This seems too generic and useful to keep to myself - is there a route whereby these could be considered for inclusion in Docbook itself, or some domain-specific subclass thereof?



The (a?) complimentary piece of code to this, dirlist.py
generates some XML which *may* feed into this.
http://www.dpawson.co.uk/java/dirlist.html

Not sure how an extension would work, but I'd be more
than willing to add the customization (if that's what it is)
to the docbook faq?

Did you extend the DTD/Schema to cope with this Geraint?

regards DaveP

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to