xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Erskine <a.ersk...@cs.ucl.ac.uk>
Subject Re: Re-purposing XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects))
Date Wed, 07 Mar 2001 15:40:34 GMT
> > I'm glad you think that...I'm quite new to XSP - if it's agnostic to how
it
> > gets used, how would you say extensions to it would affect versioning?
If
> > we propose to manipulate some XML outwith the page construct but within
XSP,
> > it seems reasonable that this takes place within tags other than
<xsp:page>.
> > But this would seem to indicate the XSP version should be bumped up to
1.1.
> >
> > Would you be happy with this?
>
> This is already in the spec. AxKit implements this. Cocoon doesn't, IIRC.

oh, right.  I've looked at AxKit, but obviously not closely enough.  Well in
that case you're probably right that what's being proposed might not impinge
on XSP so much.

Just for definiteness then, you're happy that having root level XSP
namespaced tags to represent other XML server entities than pages (e.g.
<xsp:transform> or <xsp:process>) is kosher within XSP's current spec?

This is probably all that's required in the XSP front for the first stage of
Ricardo's proposal (I'm sure I'll be corrected if I'm wrong), which is to
decouple XSP from just pages.  I have interpreted this as being able to have
other XSP root elements than page, and use this to decide what nature of
server entity to contruct.

If this is definitely OK with XSP, I'll keep my future Cocoonistic
discussion off this list, and save my cross-posting for any other worries
(such as banning programming!)

----- Original Message -----
From: "Matt Sergeant" <matt@sergeant.org>
To: "Allan Erskine" <a.erskine@cs.ucl.ac.uk>
Sent: Wednesday, March 07, 2001 9:27 AM
Subject: Re: Re-purposing XSP (was Re: [RT] Rationalizing XSP (was: XSP and
aspects))


> On Wed, 7 Mar 2001, Allan Erskine wrote:
>
> > > > Ricardo's proposal is a move in this direction, with some great
looking
> > > > structural ideas to back it up.  From what you say here, it looks
like a
> > > > convergence towards AxKit's way of doing things - so I'd hope you'd
> > share
> > > > our expectation that all XSP platforms could have something to gain.
> > >
> > > Yep, I share that view, sure. It ends up being a cocoon-dev issue
though,
> > > not an xsp-dev issue. XSP itself is agnostic about how it gets used.
> >
> > I'm glad you think that...I'm quite new to XSP - if it's agnostic to how
it
> > gets used, how would you say extensions to it would affect versioning?
If
> > we propose to manipulate some XML outwith the page construct but within
XSP,
> > it seems reasonable that this takes place within tags other than
<xsp:page>.
> > But this would seem to indicate the XSP version should be bumped up to
1.1.
> >
> > Would you be happy with this?
>
> This is already in the spec. AxKit implements this. Cocoon doesn't, IIRC.
>
> --
> <Matt/>
>
>     /||    ** Founder and CTO  **  **   http://axkit.com/     **
>    //||    **  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** mod_perl news and resources: http://take23.org  **
>      \\//
>      //\\
>     //  \\
>


Mime
View raw message