cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Small note on sitemap configuration
Date Wed, 31 May 2000 10:31:11 GMT
Donald Ball wrote:
> 
> 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>

I agree on the idea of a pipeline conditional model. In fact, I already
changed the matching architecture with this (look into the Cocoon2
/xdocs/sitemap-working-draft.xml.... grrrr, damn broken CVS update
mails)
 
> 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'].

Careful: this is a very dangerous path.

True, we could virtually embed request information into a schema, but
what about _any_ state information? server name, machine load, time of
the day in Australia, density of population in antartica, local
temperature, number of subscribed people to the cocoon-dev mail list, an
so on...

Do you _really_ want to write a schema (or RDFSchema, for that matter)
for all that? I don't think so :)
 
> 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?

+1 on the conditional model

-1 on the use of XPath as testing logic (for the problems outlined
above).

You might want to look into the "Pipeline Conditional Model" thread and
comment on what I proposed there. 

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message