cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Squaring the sitemap circle...
Date Fri, 26 May 2000 13:53:15 GMT
John Prevost wrote:
> 
> >>>>> "sm" == Stefano Mazzocchi <stefano@apache.org> writes:
> 
>     sm> the need for a "default" matcher emerged and I agree that the
>     sm> syntax above can lead to problems for users thinking that the
>     sm> <generator> at the end is executed no matter what.
> 
>     sm> Possible solutions are:
> 
>   <process uri="*">
>      <match type="load" greater-then="2.5">
>          <generator type="parser" src="./*.xml" />
>          <filter type="xslt" src="./stylesheet/low-graphics.xsl" />
>          <serializer type="html" />
>      </match>
>      <match type="browser" is="Mozilla5">
>          <generator type="parser" src="./*.xml" />
>          <filter type="xslt" src="./stylesheet/xul-enabled.xsl" />
>          <serializer type="html" />
>      </match>
>      <otherwise>
>       <generator type="parser" src="./*.xml" />
>       <filter type="xslt" src="./stylesheet/general-browser.xsl" />
>       <serializer type="html" />
>      </otherwise>
>   </process>
> 
>     sm> which can be rewritten less verbosely as
> 
>   <process uri="*">
>     <generator type="parser" src="./*.xml"/>
>     <match type="load" greater-then="2.5">
>      <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
>     </match>
>     <match type="browser" is="Mozilla5">
>      <filter type="xslt" src="./stylesheet/xul-enabled.xsl"/>
>     </match>
>     <otherwise>
>      <filter type="xslt" src="./stylesheet/general-browser.xsl"/>
>     </otherwise>
>     <serializer type="html"/>
>   </process>
> 
>     sm> is this readable enough for everybody?
> 
> Hmm.  I think this would be better:
> 
> <process uri="*">
>   <generator type="parser" src="./*.xml"/>
>   <case>
>     <match type="load" greater-than="2.5">
>       <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
>     </match>
>     <match type="browser" equal-to="Mozilla5">
>       <filter type="xslt" src="./stylesheet/xul-enabled.xsl"/>
>     </match>
>     <otherwise>
>       <filter type="xslt" src="./stylesheet/general-browser.xsl"/>
>     </otherwise>
>   </case>
>   <serializer type="html"/>
> </process>
> 
> First, because greater-than is better than greater-then, and equal-to
> is more like greater-than (and hence more consistent).  ;>
> 
> But more importantly, because it allows for the possibility of more
> than one match case grouping in a row:
> 
> <process ...>
>  <generator .../>
>  <case>
>   ...
>  </case>
>  <case>
>   ...
>  </case>
>  <serializer .../>
> </process>
> 
> In this example, one choice from the first case would run, then one
> choice from the second case would run.  We could further add syntax
> sugar to make:
> 
> <process ...>
>  ...
>  <match ...>
>   ...
>  </match>
>  ...
> </process>
> 
> where the match isn't in a case be equivalent to:
> 
> <process ...>
>  ...
>  <case>
>   <match ...>
>    ...
>   </match>
>  </case>
>  ...
> </process>
> 
> Which in my example would mean "if it matches do it, if not, don't".
> So match on its own is equivalent to xsl:if, and match and otherwise
> inside case are equivalent to xsl:when and xsl:otherwise inside
> xsl:case.

Ok, I understand.

Should we _clone_ the XSLT conditional paradigms "in toto"?

> As an example of how you might want to use this (now we get to see how
> much I remember from your message yesterday without looking at it
> again.):
> 
> <process uri="*">
>  <case>
>   <match type="load" greater-than="3.5">
>    <generator type="parser" src="./pre-processed/*.xml"/>
>   </match>
>   <otherwise>
>    <generator type="parser" src="./*.xml"/>
>    <filter type="xslt" src="./logicsheet/blah.xsl"/>
>    <filter type="xsp"/>
>   </otherwise>
>  </case>
>  <case>
>   <match type="load" greater-than="2.5">
>    <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
>   </match>
>   <match type="browser" equal-to="Mozilla5">
>    <filter type="xslt" src="./stylesheet/xul.xsl"/>
>   </match>
>   <otherwise>
>    <filter type="xslt" src="./stylesheet/plain.xsl"/>
>   </otherwise>
>  </case>
>  <serializer type="html"/>
> </process>
> 
> The goal of the above is: normally, use Mozilla5 XUL or normal
> stylesheets depending on the browser, and read from ./*.xml.  But if
> the load goes above 2.5, we want to use the low-graphics sheet no
> matter what browser.
>
> But then, if the load is still high, and goes above 3.5, we also bail
> on doing xsp work (which is going to a database or something and
> provides neat dynamic stuff) and drop down to a static content only
> site until things calm down a bit.
> 
> Sound reasonable?  Sounds reasonably complex.  :)

Complex things require complex logic. But this is _much_ less complex
that any mod_rewrite stuff that provide equal functionality.
 
> On the "naming things" warpath again, I noticed when looking back at
> your original message (yes, I cheated) that you have:
> 
> <match type="ip-filter" allowed-address="...">
> <match type="browser" accepts="...">
> <match type="user" belongs-to="...">
> <match type="load" greater-than="...">
> <match type="browser" is="...">
> 
> This looks to me like another case of "the loaded class chooses what
> attributes it can have", which is easy to code and pretty friendly,
> but not so XMLish sometimes.  I'm almost starting to think that you
> almost ought to be ripping XSL's expression syntax and conditionals
> off completely here, and say:
> 
> <if test="allowed-address($ip-filter)">
> <if test="accepts($browser, 'blah')">
> <if test="belongs-to($user, 'group')">
> <if test="$load &gt; 2.5">
> <if test="$browser = 'Mozilla5'">
> 
> The above isn't a good choice of syntax, and I'm not entirely sure
> what is, but with choices that are this free-form, I think you really
> do start dropping into a place where a fuul expression syntax is
> needed.  And that's not even counting the pain of creating halfway
> complex logical expressions with nested match tags.

Ok, we are clearly back again to the XSLT/XPath realm.

_PLEASE_ listen carefully: I _do_ understand that code-influenced
schemas are _not_ XMLish. But this is only because you think of Valid
XML as something that can be validated using a DTD or an XMLSchema!!!

There is no point on having a DTD-validated sitemap if we encode all the
logic into unparsable strings. XPath is different because reused by
other specs (xpointer, XQL), but do we really want to create another
one-liner scripting language for matching rules?

I admit I'm not happy with the current matching framework myself, but
_please_ let's not use the "this is not XMLish" argument anymore, ok?

I think it's much easier to validate something that has code-driven
attributes, provided that there is an automatic way to generate a DTD
out of code... much like you do javadocs for your code documentation.
(in fact, you could use a doclet to do it!)

So

 <if test="belongs-to($user, 'group')"/>

is actually worse than

 <if type="user" belongs-to="group"/>

for both validation and readability once you have your code-generated
DTD.

> I say +1 to most of what I see in the sitemap, but 0 to the way the
> match stuff works right now.  I apologize for not being able to come
> up with a better proposal.

Don't worry..
 
> Hrm.  Okay, a slight proposal, but it still makes me feel icky.  You
> could have match like:
> 
> <match type="foo" test="bar">
>  ...
> </match>
> 
> where foo gets to interpret bar however it pleases.  Hence:
> 
> <match type="ip-filter" test="allowed">
> <match type="browser" test="accepts('...')">
> <match type="user" test="member-of('...')">
> <match type="load" test="&gt; 2.5">
> <match type="browser" test="is('Mozilla5')">
> 
> But this is still a big mess--trying to integrate the expression
> evaluation stuff from XPath might actually be easier.

We are slowly converging to the mod_rewrite complexity.... and this
scares the hell out of me :(

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