Return-Path: <balld@webslingerZ.com>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 1221 invoked from network); 31 May 2000 04:59:56 -0000
Received: from balld-0.dsl.speakeasy.net (HELO localhost.localdomain)
 (@216.254.77.75)
  by locus.apache.org with SMTP; 31 May 2000 04:59:56 -0000
Received: from localhost (balld@localhost)
	by localhost.localdomain (8.9.3/8.9.3) with ESMTP id XAA11833
	for <cocoon-dev@xml.apache.org>; Tue, 30 May 2000 23:50:44 -0400
X-Authentication-Warning: localhost.localdomain: balld owned process doing -bs
Date: Tue, 30 May 2000 23:50:44 -0400 (EDT)
From: Donald Ball <balld@webslingerZ.com>
X-Sender: balld@localhost.localdomain
To: Cocoon <cocoon-dev@xml.apache.org>
Subject: Small note on sitemap configuration
Message-ID: <Pine.LNX.4.10.10005302346210.11438-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

First, some terminology to help me reduce clutter: a resolver consists of
one generator, any number of filters, and one serializer. The function
that maps requests to resolvers is called the map function.

In the sitemap file, a process element can contain one generator, any
number of filters, and one serializer (a resolver). The process element
may also contain match elements, which specify request-time conditions
that must be met. The match element may contain alternate resolver
components. Assuming the match elements provide us with true boolean
expression evaluation, we can build a sitemap that accomplishes the design
goals delineated above, at least on a per-URI basis.

The sitemap for a complex set of criteria may prove to be overly
cumbersome, though. For instance, if the map function depends on uri,
preferred language, and user agent, the sitemap might look like this:

<process uri="/foo/**">
 <match type="language" value="en">
  <generator type="parser" src="./foo/en/**"/>
 </match>
 <match type="language" value="fr">
  <generator type="parser" src="./foo/fr/**"/>
 </match>
 <match type="format" value="html">
  <filter type="xslt" src="./style/html.xslt"/>
  <serializer type="html"/>
 </match>
 <match type="format" value="wml">
  <filter type="xslt" src="./style/wml.xslt"/>
  <serializer type="xml"/>
 </match>

Problems become evident at this point. How do we specify a default
language? We could say that a resolver component specified by a match
overrides a top-level resolver component. But suppose we have more
languages than we want to enumerate in a sitemap repeatedly, and suppose
the configuration of a resolver component could depend on a request-time
variable? We could write it like this:

<process uri="/foo/**">
 <match type="language" value="*">
  <generator type="parser" src="./foo/{language}/**"/>
 </match>
 <match type="format" value="*">
  <filter type="xslt" src="./style/{format}.xslt"/>
 </match>
 ...
</process>

That's better, but still not perfect. We still don't have a default
language. For that, and for other reasons, I think we'd do better to add
conditional processing:

<process uri="/foo/**">
 <choose>
  <when test="language">
   <generator type="parser" src="./foo/{language}/**"/>
  </when>
  <otherwise>
   <generator type="parser" src="./foo/en/**"/>
  </otherwise>
 </choose>
 ...
</process>

Of course, this requires that we make request-time information available
via named variables in the sitemap (e.g. language). Virtually speaking, we
could construct an XML fragment for the request:

<request>
 <uri value="/foo/bar"/>
 <parameter name="foo" value="bar" method="get"/>
 <header type="http" name="Referer"/>
</request>

And allow the sitemap author to construct simple XPath expressions to
reference that information:

header[@name='Referer']

We could provide parameters for frequently accessed information or
information that might be composed from multiple pieces of information
(namely, the preferred language which might depend on a header or a
cookie). e.g. $referer == header[@name='Referer'].

Note we don't actually have to construct the request document - generally,
I don't think we'll want to since much of the request time information is
irrelevant. We can write our own simple XPath expression resolver, or if
we use Xalan's XPath module to do the resolution we could write a small
DOM implementation that acted as a decorator for the HttpServletRequest
methods.

So the upshot of my random thoughts here - I propose that we replace the
match element with conditionals ala XSLT and allow sitemap authors to
reference request time information using XPath expressions into the
request data represented as an XML fragment. Any takers?

- donald