Flaky CSS implementations don’t detract at all from another role played by the class attribute. It is, fundamentally, a selector that operates on a document and returns a subset of its elements. Normally it’s a CSS-aware application (e.g., your browser) that does the selection in order to apply a style. But any other application can use the selectors too. Suppose you want to create a view of the docbase that presents report summaries containing a search term. In SQL terms, you’d like to issue the query:

select summary from docbase where summary like '%LDAP%'

Example 6.9 demonstrates a filter, called xml-grep, that reads one of the HTML/CSS/XML files in this docbase and performs the same query.

#   usage: xml-grep FILENAME TAG PATTERN
# example: xml-grep 000127.htm summary LDAP

use XML::Parser;

my $xml = new XML::Parser (Style => 'Stream'),  

$xml->parsefile($ARGV[0]);         # parse the file

sub StartTag {}                    # not needed here

sub EndTag {}                      # not needed here

sub Text
  {
  my $expat = shift;
  if  (
      $expat->current_element eq 'td'        and  # table cell
      $_{class}               eq $ARGV[1]    and  # of class 'summary'
      m/$ARGV[2]/                                 # matching LDAP
      )
    {   print "$_{class}: $_
";    }             # found a hit
  }

This script expects three arguments: a filename, a class attribute, and a search string. It’s a whole lot slower than grep. But it’s more flexible, because it will match, for example, either of these patterns:

<td class="summary" width="20%">...</td>

<td valign="top" class="summary" align="left" colspan="2">...</td>

What’s more, this approach can deal with inheritance in the same way that CSS display processors do. For example, the analyst field might not always be immediately contained within a cell of an HTML table. Suppose that inside that cell, the name is wrapped up in link syntax, like this:

<td class="analyst"><a href="mailto:[email protected]">
Jon Udell</a></td>

We can still capture my name like this:

if  (
    $expat->within_element('td')                and  # inside a table cell
    $last_seen_class_attr        eq $ARGV[1]    and  # class="analyst"
    m/$ARGV[2]/                                      # match "Jon Udell"
    )

If we saved the value of the last-seen class attribute as $last_seen_class_attr, then this fragment—which runs in the context of the <a href> tag—will succeed. A line-oriented grep can’t do this. But an XML query that understands the hierarchy of an attributed docbase can find things that are nested in other things. Several formal query languages are proposed for XML, notably XQL (http://www.w3.org/TandS/QL/QL98/pp/xql.html) and XML-QL (http://www.w3.org/TR/NOTE-xml-ql/). Even without a general-purpose XML query language, though, you can see that it’s not hard to write parser-enabled code to do simple queries.

The XML nature of the docbase records created by the template in Example 6.8 solves another important problem too. When I managed the Virtual Press Room, I sometimes had to make wholesale changes to the docbase. That was never a problem with the BYTE docbase, because its “object code” was routinely “compiled” from its “source code.” But the VPR’s “object code” was its “source code,” and there was no “compiler” in the same sense.

Because the VPR’s HTML pages were machine written, they exhibited regular patterns that Perl scripts could latch onto and use to make systematic transformations. But the pages weren’t trivially rewritable. Creating those scripts was feasible but was a time-consuming and ultimately wasteful exercise. XML means never having to waste your time writing custom parsing code.

Docbases need to evolve. Inevitably you’ll run into situations that require wholesale rewriting of a set of records. The XML discipline makes that kind of rewrite vastly simpler than it otherwise would be. That’s a huge bonus for a manager of semistructured information.

HTML’s <meta> tag has for years provided a way to make the header of a web page behave much like the header of an email or news message. You can use the <meta> tag to tuck a set of name/value pairs into a document header. In the long run, XML may obselete this way of maintaining a structured header inside a web page. But for the near future, it’s a really useful technique. Like email headers, these kinds of web-page headers are easy to parse and manipulate, using a variety of tools. Because the <meta> tags in Example 6.1 are well-formed XML, any XML parser can work with them. But as we’ll see in the next chapter, sometimes that can be overkill. It’s faster and easier to deal with a simple pattern like this one using Perl’s native regular-expression engine.

In Chapter 7, we’ll use the meta-tagged header in the docbase record to build indexes that enable several modes of navigation. In Chapter 8, we’ll see how full-text indexers can automatically recognize the meta-tagged header and use it to support field-level as well as full-text search of the docbase. That’s a powerful capability, but one that’s seldom used. Why? It requires a tagging discipline that many web archives lack. By doing that tagging automatically, the Docbase system creates potential value. A smart navigational system is one way to actualize that potential; a smart search system is another.

Note that some of the fields defined in Example 6.8 with <meta> tags duplicate fields governed by CSS class attributes. Why do it both ways? Sometimes you just need to scan for indexable fields, as we’ll be doing in the next chapter, and then it’s handy to have a nice neat header tucked into the top of every docbase record. Sometimes you need to do a wholesale transformation of the docbase, in which case you’ll want to deal with XML elements rather than simple text patterns. There’s more than one way to do it!

Now let’s see how a record, having been previewed and submitted by a user, enters the docbase. The preview is hardwired to a common script, final-submit.pl, shown in Example 6.10.

#!/usr/bin/perl -w

use strict;
use TinyCGI;
my $tc = TinyCGI->new();
print $tc->printHeader;
my $vars = $tc->readParse();

use Docbase::Docbase;
my $db = Docbase::Docbase->new($vars->{app});

use Docbase::Input;
my $di = Docbase::Input->new($db);

$di->writeDoc($vars);

It’s brief, needing only to pass a hashtable of CGI variables to the Docbase::Input method writeDoc( ), shown in Example 6.11.

sub writeDoc
  {
  my ($self,$vars) = @_;
  my $app = $self->{app};
  my $cgi_absolute = $self->{docbase_cgi_absolute};
  my $web_absolute = $self->{docbase_web_absolute};
                                                    
  my $db_template =                               # make template name
    "$cgi_absolute/$app/docbase-template.htm"; 
                                                    
  my $content .=                                  # interpolate vars into template
     _fillTemplate($db_template,$vars);
                                                    
  my $docnum =                                    # get next record number
    _nextFilenum("$web_absolute/$app/docs","htm");
             
  my $docfile =                                   # make record's filename
    "$web_absolute/$app/docs/$docnum.htm";
                                                    
  if ( open(F,">$docfile") )
    {
    print F $content;                             # store record
    close F;
    print "<br>Done. Your reference number is $docnum
";
    }
  else    
    {
    print "<p>cannot open docfile $docfile";
    }
  }

The writeDoc( ) method is also brief. It uses _fillTemplate( ) again to interpolate form variables into the record template, asks for the next available record number, creates a file named for that record number, and writes the record to the file.