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 Thu, 01 Jun 2000 12:56:00 GMT
Donald Ball wrote:
> 
> 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? 

Oh, well, no. Not in my proposals.... I assumed we could skip that
complexity alltogether.

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

I'm sorry, I didn't not understand your points. I thought you were
asking to create a schema to translate the request into a virtual XML
document and then apply the XPath on that "as a condition".

Sort of like

 <process uri="/foo/**">
  <choose>
   <when test="/request/language[language='it']">
    ...
   </when>
   <otherwise>
    ...
   </otherwise>
  </choose>

I was indicating -1 on that, nothing else.
 
> Go back to my language example:

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

 <process uri="/foo/**">
  <generator type="lang-dependent-parser" src="./foo/**"/>
 </process>

the "lang-dependent-parser" will _know_ how to handle the request
parameters it needs.

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

Right

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

No, I did.

Anyway, I think we are starting to get into the FS path and the sitemap
complexity is starting to grow much higher than I want.

We should _NOT_ forget that programming is done using programming
languages. Sam is right advocating this all the time.

Going into the XPath or XSLT param/variable design you are, in fact,
making the sitemap dangerously programmable, but you are loosing power
instead of gaining it! And, in fact, you are breaking the administration
- logic contract by giving more turing-power to administrators (which
should _not_ have it for design).

Let's make an example to show you how dangerous things can get:

 <process uri="/foo/**">
  <generator type="parser" src="./foo/**"/>
  <choose>
   <when test="machine-load gt 1.0">
    <filter type="parser"
src="./foo/styles/style-{round-to-integer(machine-load)}.xsl"/>
   </when>
   <otherwise>
    <filter type="parser" src="./foo/styles/normal-style.xsl"/>
   </otherwise>
  </choose>
  ...
 </process>

I don't think you could make such thing pass the (now infamous)
"Stefano's girlfriend test".

But I admit I'm not 100% sure about all this....

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