Return-Path: 
 <cocoon-dev-return-12740-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 7740 invoked by uid 500); 23 Apr 2001 00:43:55 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 7726 invoked from network); 23 Apr 2001 00:43:54 -0000
Message-ID: <004001c0cb8e$957dad50$ea4dfea9@spukny>
From: Allan Erskine <a.erskine@cs.ucl.ac.uk>
To: cocoon-dev <cocoon-dev@xml.apache.org>
References: <B7087886.2726%jafoster@engmail.uwaterloo.ca>
Subject: Re: [C2] Protected area app
Date: Mon, 23 Apr 2001 01:44:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

Jason,

I'm not sure if this is what you were thinking, but one of my first C2 posts
was on XPath and the sitemap.  My reasoning was that C2 seemed to be
adopting a declarative style of programming/configuring (whatever you want
to call it), esp when it came to sitemaps.  If you are wanting to base a
declaritive behaviour choice on some aspect of the state of your system,
then what could seem more natural than having that state represented by XML
(eg an abstract XML representation of request, session, action state always
available in for use in the sitemap)?

And then what more natural tool to evaluate tests on that XML than to use
XPath?  AFAIR Donald Ball replied and said that Ricardo had argued against
this in the past, something about an XPath hammer and a sitemap screw...but
I still hold a small candle for this idea.

On Donald's suggestion I even looked into ways of going about it, but was
put off but the lack of a SAX API for XPath.  Recently Berin mentioned
starting a project on sourceforge for one, but I don't know how far this got
either.

Allan

----- Original Message -----
From: "Jason Foster" <jafoster@engmail.uwaterloo.ca>
To: "cocoon-dev" <cocoon-dev@xml.apache.org>
Sent: Sunday, April 22, 2001 5:01 PM
Subject: Re: [C2] Protected area app


> <snip>
>
> >>> <map:match pattern="protected**">
> >>>     <session validator action>
> >>>         <any protected content generated/>
> >>>     </session validator action>
> >>>     <action failed>
> >>>         <back to login/>
> >>>     </action failed>
> >>> </map:match>
> >>>
>
> <snip>
>
> >> No problem. Replace the <any protected content.../> above with a
<mount>
>
> This has probably been mentioned before, but doesn't this look a lot like
> Xpath/XSLT? The more example of actions I see, the more it look like a
> recursive, set-based mindset is being applied.
>
> Going from a very hazy memory it would look something like...
>
> <xsl:template match="//protected">
>   <xsl:apply-template name="validate-action/>
>   <xsl:choose>
>     <xsl:when test="$validated='TRUE'">
>       <xsl:apply-templates/>
>     </xsl:when>
>     <xsl:otherwise>
>       <xsl:apply-template name="back-to-login"/>
>     <xsl:otherwise/>
>   </xsl:choose>
> </xsl:template>
>
> I'm curious as to how hard it would be to use XSLT/XPath to generate the
> appropriate processing chain?  The model would be something like:
>
>   URL --> XSLT --> SiteMap XML Fragment --> SiteMap XSL --> execution
>
> While this does shoehorn XSL/XPath into yet another purpose, it does allow
> for the reuse of skills and XSL tools.  If the XML fragment can be
captured
> it also allows for (hopefully) easier debugging of how various URLs are
> being interpreted.
>
> More thoughts from a very confused, and very apologetic for his previous
> post, pseudo-lurker.
>
> Jason Foster
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org