cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: Small note on sitemap configuration
Date Wed, 31 May 2000 16:05:31 GMT
On Wed, 31 May 2000, Stefano Mazzocchi wrote:

> > 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 :)

I strongly disagree here. We're going to have to present the sitemap
author with some way to access request-time information in their
conditionals, right? Whatever scheme we use, we're going to have to limit
it to the request-information that is likely to be relevant (e.g. all
information about the request itself and a little bit about local state -
current time, etc.) So saying that allowing access to request-time
information via XPath expressions is a bad idea because we could overload
it with too much information is fatuous. The same criticism can be
levelled at any method of allowing access to request-time information.

Go back to my language example:

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

How would you propose to rewrite this example using your matcher elements?

> -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. 

I don't see anything in that proposal about accessing the value of
request-time variables in the configuration of the resolver components -
which I think is key. I don't see any problems with XPath expressions that
don't apply equally well to anything else that accomplishes the same goal.
Maybe I have missed something though?

- donald


Mime
View raw message