You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2001/02/15 02:10:50 UTC
Normalizing xsp uri namespaces
Hi all
Matt Sergeant and I recently had a discussion about the URI of the XSP
namespace. He wants to release a new version of AxKit and want to make that
clear before doing so.
IIRC we dicided to follow the pattern:
http://apache.org/xsp/LOGISHEET/VERSION
for the URI of the taglib namespaces. Unforunately we didn't talked about the
namespace of the core logicsheet of xsp on the lists.
C2 for today uses
http://apache.org/xsp
and C1 is using
http://www.apache.org/1999/XSP/Core
Our proposal for a normalized version is
http://apache.org/xsp/core/VERSION
Is this ok for you all?
What version should it be?
Please give us your comments.
Giacomo
Re: SiLLy [was Re: Normalizing xsp uri namespaces]
Posted by Paul Russell <pa...@luminas.co.uk>.
* Giacomo Pati (giacomo@apache.org) wrote :
> > Well, broadly speaking, anyway. What happened to SiLLy? Do we have a
> > schema lying around?
> The only writte resources I know about is in xdocs/logicsheet-concepts.xml
> and somewhere in a cocoon-dev mail archive.
Uhuh. Not a lot there, as yet, from what I remember.
> > It shouldn't be that hard to write if we knew what
> > we were aiming for.
> Yes, likely. And now the obligate question :) do you (or anybody else here of
> course) volunteer for it?
Heh. I might be able to do it, but I'm *very* short of time at the
moment.
> Should we grab those information and design SiLLy?
Yes, I think so. Let's get the thing designed, and then we'll see who's
got the time to implement it (this might well be me by then - my
workload is likely to change a lot soonish).
> It definitively is an easier piece than the aggregation or the cache
> proposals.
One of which is *still* waiting for me to sum up everyone's opinions and
post a proposal. Real Soon Now, hopefully :/
P.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
SiLLy [was Re: Normalizing xsp uri namespaces]
Posted by Giacomo Pati <gi...@apache.org>.
Paul Russell wrote:
> * Giacomo Pati (giacomo@apache.org) wrote :
> > > > > i'll vote for
> > > > >
> > > > > http://apache.org/xsp/core/VERSION
> > > > >
> > > > > we should immediately switch c2's xsp namespace uri to use that. we
> > > > > should also switch the c2 logicsheets to use the new unified xsp
> > > > > namespace scheme.
> > > >
> > > > I totally agree.
> > >
> > > I agree as well.
>
> Thirded.
>
> > > > What pattern should we use for the version? I've actually found two
> > > > styles:
> > > > 1) http://apache.org/xsp/esql/v2
> > > > 2) http://apahce.org/xsp/foo/1.0
> > >
> > > I would suggest the use of two numbers 'dot notation' for versioning
> > > [major.minor] where major is incremented when the taglib is *NOT* back
> > > compatible, while minor is incremented if something is added or
> > > deprecated, but back compatibility is maintained.
> >
> > My preference too, so we are at 2 votes for 2) and one for 1)
>
> And mine.
>
> > > In the future, we might want to centralize the distribution of XSP
> > > taglibs from the above URI, then I suggest we place a sort of "taglib
> > > description file" that indicates where the XSP engine can find the
> > > appropriate taglib implementation for the required programming
> > > language, but this has nothing to do with embedding either the
> > > programming language or the XSP engine name (Cocoon or AxKit) in the
> > > taglib URI.
> >
> > Yes, kind a automated CPAN for taglibs. I feel sorry nobody investigated
> > into the simple logicsheet language (SILLY) where things like this coud
> > be addressed. Also because a SILLY stylesheet will be programming
> > language neutral to be ported along different implenetations of XSP.
>
> Well, broadly speaking, anyway. What happened to SiLLy? Do we have a
> schema lying around?
The only writte resources I know about is in xdocs/logicsheet-concepts.xml
and somewhere in a cocoon-dev mail archive.
> It shouldn't be that hard to write if we knew what
> we were aiming for.
Yes, likely. And now the obligate question :) do you (or anybody else here of
course) volunteer for it?
Should we grab those information and design SiLLy?
It definitively is an easier piece than the aggregation or the cache
proposals.
Giacomo
Re: Normalizing xsp uri namespaces
Posted by Paul Russell <pa...@luminas.co.uk>.
* Giacomo Pati (giacomo@apache.org) wrote :
> > > > i'll vote for
> > > >
> > > > http://apache.org/xsp/core/VERSION
> > > >
> > > > we should immediately switch c2's xsp namespace uri to use that. we
> > > > should also switch the c2 logicsheets to use the new unified xsp
> > > > namespace scheme.
> > > I totally agree.
> > I agree as well.
Thirded.
> > > What pattern should we use for the version? I've actually found two
> > > styles:
> > > 1) http://apache.org/xsp/esql/v2
> > > 2) http://apahce.org/xsp/foo/1.0
> > I would suggest the use of two numbers 'dot notation' for versioning
> > [major.minor] where major is incremented when the taglib is *NOT* back
> > compatible, while minor is incremented if something is added or
> > deprecated, but back compatibility is maintained.
> My preference too, so we are at 2 votes for 2) and one for 1)
And mine.
> > In the future, we might want to centralize the distribution of XSP
> > taglibs from the above URI, then I suggest we place a sort of "taglib
> > description file" that indicates where the XSP engine can find the
> > appropriate taglib implementation for the required programming language,
> > but this has nothing to do with embedding either the programming
> > language or the XSP engine name (Cocoon or AxKit) in the taglib URI.
> Yes, kind a automated CPAN for taglibs. I feel sorry nobody investigated into
> the simple logicsheet language (SILLY) where things like this coud be
> addressed. Also because a SILLY stylesheet will be programming language
> neutral to be ported along different implenetations of XSP.
Well, broadly speaking, anyway. What happened to SiLLy? Do we have a
schema lying around? It shouldn't be that hard to write if we knew what
we were aiming for.
P.
--
Paul Russell Email: paul@luminas.co.uk
Technical Director Tel: +44 (0)20 8553 6622
Luminas Internet Applications Fax: +44 (0)870 28 47489
This is not an official statement or order. Web: www.luminas.co.uk
Re: Normalizing xsp uri namespaces
Posted by Stefano Mazzocchi <st...@apache.org>.
Matt Sergeant wrote:
>
> On Thu, 15 Feb 2001, Giacomo Pati wrote:
>
> > Well, to be honest, I have no clue how AxKit logicsheets are written. But as
> > the syntax for XSP is normated why could AxKit not profit from a
> > preprocessing of a "raw" logicsheet? Don't you use XSLT to apply a logicsheet
> > to an XSP page?
>
> Nope, not at all. Here's our Param logicsheet in its entirity. Note that
> it's basically a SAX handler (its really an XML::Parser handler, but
> they're pretty similar):
>
> package AxKit::XSP::Param;
> use strict;
> use Apache::AxKit::Language::XSP qw(start_expr append_to_script end_expr);
>
> use vars qw/@ISA $NS $VERSION/;
>
> @ISA = ('Apache::AxKit::Language::XSP');
> $NS = 'http://axkit.org/NS/xsp/param/v1';
>
> $VERSION = 0.60;
>
> sub parse_start {
> my ($e, $tag, %attribs) = @_;
> start_expr($e, $tag);
> append_to_script($e, '$cgi->param(q|' . $tag . '|)');
> end_expr($e);
> return '';
> }
>
> 1;
>
> Thats it :-)
>
> Usage is just <param:foo/> which if this were Cocoon, would generate
> <xsp:expr>$cgi->param(q|foo|)</xsp:expr>, but it doesn't generate raw XSP,
> the parsing of AxKit XSP is one-pass, always. So this just generates raw
> perl code.
>
> Of course there's nothing *stopping* you from writing logicsheets in XSLT
> the same as Cocoon, but we just think this way is better from a simplicity
> standpoint, and a parse-time performance standpoint (because we have to
> parse once-per-child with Apache, unlike Servlets). YMMV.
I agree with Matt here: using SiLLy for that is too much since it
imposes more than necessary to XSP engine implementors. AxKit and Cocoon
rely on very similar operational concepts, but they are targetted at two
different schools of thoughts, or mental shapes.
While I believe that AxKit will be killer for ready-to-go few-men-teams
write-and-forget usage (a place were Cocoon indeed sucks!), Cocoon will
take over once the complexity starts to rise and the amount resources
invested (both technical and human) goes along.
The concept of SiLLy might be language-neutral as well as XSP, but its
based on strong architectural concepts that require an investiment from
those logicsheet writers (as well as engine implementors). A price that
might not be efficient to pay for small-to-medium projects.
This is why I believe that if such a CPAN for taglibs is written, the
file to describe the resource (yes, Giacomo, RDF comes immediately to
mind but it's not necessary once we agree on a schema) doesn't need to
be SiLLy or anything that complex... something like
<taglib>
<name>SQL</name>
<author name="Donald Ball" email="balld@apache.org"/>
<version major="2" minor="1"/>
<description xmlns:xhtml="...">
<xhtml:p>this is a short description.</xhtml:p>
</description>
<implementations>
<implementation language="http://java.sun.com/"
package="http://xml.apache.org/cocoon/xsp/taglibs/sql_2.1.war"/>
<implementation language="http://www.perl.com/"
package="http://www.axkit.org/xsp/taglibs/sql2_1.tar.gz"/>
</implementations>
</taglib>
please, consider it just a wide guess to start a discussion, I'm sure
you guys have better schemas in mind than this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Normalizing xsp uri namespaces
Posted by Stefano Mazzocchi <st...@apache.org>.
Matt Sergeant wrote:
>
> On Thu, 15 Feb 2001, Giacomo Pati wrote:
>
> > Well, to be honest, I have no clue how AxKit logicsheets are written. But as
> > the syntax for XSP is normated why could AxKit not profit from a
> > preprocessing of a "raw" logicsheet? Don't you use XSLT to apply a logicsheet
> > to an XSP page?
>
> Nope, not at all. Here's our Param logicsheet in its entirity. Note that
> it's basically a SAX handler (its really an XML::Parser handler, but
> they're pretty similar):
>
> package AxKit::XSP::Param;
> use strict;
> use Apache::AxKit::Language::XSP qw(start_expr append_to_script end_expr);
>
> use vars qw/@ISA $NS $VERSION/;
>
> @ISA = ('Apache::AxKit::Language::XSP');
> $NS = 'http://axkit.org/NS/xsp/param/v1';
>
> $VERSION = 0.60;
>
> sub parse_start {
> my ($e, $tag, %attribs) = @_;
> start_expr($e, $tag);
> append_to_script($e, '$cgi->param(q|' . $tag . '|)');
> end_expr($e);
> return '';
> }
>
> 1;
>
> Thats it :-)
>
> Usage is just <param:foo/> which if this were Cocoon, would generate
> <xsp:expr>$cgi->param(q|foo|)</xsp:expr>, but it doesn't generate raw XSP,
> the parsing of AxKit XSP is one-pass, always. So this just generates raw
> perl code.
>
> Of course there's nothing *stopping* you from writing logicsheets in XSLT
> the same as Cocoon, but we just think this way is better from a simplicity
> standpoint, and a parse-time performance standpoint (because we have to
> parse once-per-child with Apache, unlike Servlets). YMMV.
I agree with Matt here: using SiLLy for that is too much since it
imposes more than necessary to XSP engine implementors. AxKit and Cocoon
rely on very similar operational concepts, but they are targetted at two
different schools of thoughts, or mental shapes.
While I believe that AxKit will be killer for ready-to-go few-men-teams
write-and-forget usage (a place were Cocoon indeed sucks!), Cocoon will
take over once the complexity starts to rise and the amount resources
invested (both technical and human) goes along.
The concept of SiLLy might be language-neutral as well as XSP, but its
based on strong architectural concepts that require an investiment from
those logicsheet writers (as well as engine implementors). A price that
might not be efficient to pay for small-to-medium projects.
This is why I believe that if such a CPAN for taglibs is written, the
file to describe the resource (yes, Giacomo, RDF comes immediately to
mind but it's not necessary once we agree on a schema) doesn't need to
be SiLLy or anything that complex... something like
<taglib>
<name>SQL</name>
<author name="Donald Ball" email="balld@apache.org"/>
<version major="2" minor="1"/>
<description xmlns:xhtml="...">
<xhtml:p>this is a short description.</xhtml:p>
</description>
<implementations>
<implementation language="http://java.sun.com/"
package="http://xml.apache.org/cocoon/xsp/taglibs/sql_2.1.war"/>
<implementation language="http://www.perl.com/"
package="http://www.axkit.org/xsp/taglibs/sql2_1.tar.gz"/>
</implementations>
</taglib>
please, consider it just a wide guess to start a discussion, I'm sure
you guys have better schemas in mind than this.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> Well, to be honest, I have no clue how AxKit logicsheets are written. But as
> the syntax for XSP is normated why could AxKit not profit from a
> preprocessing of a "raw" logicsheet? Don't you use XSLT to apply a logicsheet
> to an XSP page?
Nope, not at all. Here's our Param logicsheet in its entirity. Note that
it's basically a SAX handler (its really an XML::Parser handler, but
they're pretty similar):
package AxKit::XSP::Param;
use strict;
use Apache::AxKit::Language::XSP qw(start_expr append_to_script end_expr);
use vars qw/@ISA $NS $VERSION/;
@ISA = ('Apache::AxKit::Language::XSP');
$NS = 'http://axkit.org/NS/xsp/param/v1';
$VERSION = 0.60;
sub parse_start {
my ($e, $tag, %attribs) = @_;
start_expr($e, $tag);
append_to_script($e, '$cgi->param(q|' . $tag . '|)');
end_expr($e);
return '';
}
1;
Thats it :-)
Usage is just <param:foo/> which if this were Cocoon, would generate
<xsp:expr>$cgi->param(q|foo|)</xsp:expr>, but it doesn't generate raw XSP,
the parsing of AxKit XSP is one-pass, always. So this just generates raw
perl code.
Of course there's nothing *stopping* you from writing logicsheets in XSLT
the same as Cocoon, but we just think this way is better from a simplicity
standpoint, and a parse-time performance standpoint (because we have to
parse once-per-child with Apache, unlike Servlets). YMMV.
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> Well, to be honest, I have no clue how AxKit logicsheets are written. But as
> the syntax for XSP is normated why could AxKit not profit from a
> preprocessing of a "raw" logicsheet? Don't you use XSLT to apply a logicsheet
> to an XSP page?
Nope, not at all. Here's our Param logicsheet in its entirity. Note that
it's basically a SAX handler (its really an XML::Parser handler, but
they're pretty similar):
package AxKit::XSP::Param;
use strict;
use Apache::AxKit::Language::XSP qw(start_expr append_to_script end_expr);
use vars qw/@ISA $NS $VERSION/;
@ISA = ('Apache::AxKit::Language::XSP');
$NS = 'http://axkit.org/NS/xsp/param/v1';
$VERSION = 0.60;
sub parse_start {
my ($e, $tag, %attribs) = @_;
start_expr($e, $tag);
append_to_script($e, '$cgi->param(q|' . $tag . '|)');
end_expr($e);
return '';
}
1;
Thats it :-)
Usage is just <param:foo/> which if this were Cocoon, would generate
<xsp:expr>$cgi->param(q|foo|)</xsp:expr>, but it doesn't generate raw XSP,
the parsing of AxKit XSP is one-pass, always. So this just generates raw
perl code.
Of course there's nothing *stopping* you from writing logicsheets in XSLT
the same as Cocoon, but we just think this way is better from a simplicity
standpoint, and a parse-time performance standpoint (because we have to
parse once-per-child with Apache, unlike Servlets). YMMV.
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Giacomo Pati <gi...@apache.org>.
Matt Sergeant wrote:
> Hey what's with stripping xsp-dev from the cc list?
Sorry, used the wrong mailer command to answer.
> On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > > > What pattern should we use for the version? I've actually found two
> > > > styles:
> > > >
> > > > 1) http://apache.org/xsp/esql/v2
> > > > 2) http://apahce.org/xsp/foo/1.0
> > >
> > > I would suggest the use of two numbers 'dot notation' for versioning
> > > [major.minor] where major is incremented when the taglib is *NOT* back
> > > compatible, while minor is incremented if something is added or
> > > deprecated, but back compatibility is maintained.
> >
> > My preference too, so we are at 2 votes for 2) and one for 1)
>
> Only consider mine half a vote - I'm so laid back about this I'm
> horizontal.
>
> > > In the future, we might want to centralize the distribution of XSP
> > > taglibs from the above URI, then I suggest we place a sort of "taglib
> > > description file" that indicates where the XSP engine can find the
> > > appropriate taglib implementation for the required programming
> > > language, but this has nothing to do with embedding either the
> > > programming language or the XSP engine name (Cocoon or AxKit) in the
> > > taglib URI.
> >
> > Yes, kind a automated CPAN for taglibs. I feel sorry nobody investigated
> > into the simple logicsheet language (SILLY) where things like this coud
> > be addressed. Also because a SILLY stylesheet will be programming
> > language neutral to be ported along different implenetations of XSP.
>
> But you're forgetting that our XSP implementation works completely
> differently to yours. While I think SILLY may work for Cocoon, I don't
> think it will work for AxKit. Sorry.
Well, to be honest, I have no clue how AxKit logicsheets are written. But as
the syntax for XSP is normated why could AxKit not profit from a
preprocessing of a "raw" logicsheet? Don't you use XSLT to apply a logicsheet
to an XSP page? So why couldn't you apply a stylesheet to the logicsheet
first befor using that to apply to the XSP page. SILLY would eliminate some
burden of off logicsheet writer which need to take care of some "convention"
for their logicsheets as there are the utility templates to copy everything
else over to the next stage or to extract parameter values out of the
different writing possibilities XSP offers. Automated taglib documentation
generation could be taken into consideration which is not possible (or only
limited) with todays logicsheets.
Giacomo
Re: Normalizing xsp uri namespaces
Posted by Giacomo Pati <gi...@apache.org>.
Matt Sergeant wrote:
> Hey what's with stripping xsp-dev from the cc list?
Sorry, used the wrong mailer command to answer.
> On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > > > What pattern should we use for the version? I've actually found two
> > > > styles:
> > > >
> > > > 1) http://apache.org/xsp/esql/v2
> > > > 2) http://apahce.org/xsp/foo/1.0
> > >
> > > I would suggest the use of two numbers 'dot notation' for versioning
> > > [major.minor] where major is incremented when the taglib is *NOT* back
> > > compatible, while minor is incremented if something is added or
> > > deprecated, but back compatibility is maintained.
> >
> > My preference too, so we are at 2 votes for 2) and one for 1)
>
> Only consider mine half a vote - I'm so laid back about this I'm
> horizontal.
>
> > > In the future, we might want to centralize the distribution of XSP
> > > taglibs from the above URI, then I suggest we place a sort of "taglib
> > > description file" that indicates where the XSP engine can find the
> > > appropriate taglib implementation for the required programming
> > > language, but this has nothing to do with embedding either the
> > > programming language or the XSP engine name (Cocoon or AxKit) in the
> > > taglib URI.
> >
> > Yes, kind a automated CPAN for taglibs. I feel sorry nobody investigated
> > into the simple logicsheet language (SILLY) where things like this coud
> > be addressed. Also because a SILLY stylesheet will be programming
> > language neutral to be ported along different implenetations of XSP.
>
> But you're forgetting that our XSP implementation works completely
> differently to yours. While I think SILLY may work for Cocoon, I don't
> think it will work for AxKit. Sorry.
Well, to be honest, I have no clue how AxKit logicsheets are written. But as
the syntax for XSP is normated why could AxKit not profit from a
preprocessing of a "raw" logicsheet? Don't you use XSLT to apply a logicsheet
to an XSP page? So why couldn't you apply a stylesheet to the logicsheet
first befor using that to apply to the XSP page. SILLY would eliminate some
burden of off logicsheet writer which need to take care of some "convention"
for their logicsheets as there are the utility templates to copy everything
else over to the next stage or to extract parameter values out of the
different writing possibilities XSP offers. Automated taglib documentation
generation could be taken into consideration which is not possible (or only
limited) with todays logicsheets.
Giacomo
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
Hey what's with stripping xsp-dev from the cc list?
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > > What pattern should we use for the version? I've actually found two
> > > styles:
> > >
> > > 1) http://apache.org/xsp/esql/v2
> > > 2) http://apahce.org/xsp/foo/1.0
> >
> > I would suggest the use of two numbers 'dot notation' for versioning
> > [major.minor] where major is incremented when the taglib is *NOT* back
> > compatible, while minor is incremented if something is added or
> > deprecated, but back compatibility is maintained.
>
> My preference too, so we are at 2 votes for 2) and one for 1)
Only consider mine half a vote - I'm so laid back about this I'm
horizontal.
> > In the future, we might want to centralize the distribution of XSP
> > taglibs from the above URI, then I suggest we place a sort of "taglib
> > description file" that indicates where the XSP engine can find the
> > appropriate taglib implementation for the required programming language,
> > but this has nothing to do with embedding either the programming
> > language or the XSP engine name (Cocoon or AxKit) in the taglib URI.
>
> Yes, kind a automated CPAN for taglibs. I feel sorry nobody investigated into
> the simple logicsheet language (SILLY) where things like this coud be
> addressed. Also because a SILLY stylesheet will be programming language
> neutral to be ported along different implenetations of XSP.
But you're forgetting that our XSP implementation works completely
differently to yours. While I think SILLY may work for Cocoon, I don't
think it will work for AxKit. Sorry.
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
Hey what's with stripping xsp-dev from the cc list?
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > > What pattern should we use for the version? I've actually found two
> > > styles:
> > >
> > > 1) http://apache.org/xsp/esql/v2
> > > 2) http://apahce.org/xsp/foo/1.0
> >
> > I would suggest the use of two numbers 'dot notation' for versioning
> > [major.minor] where major is incremented when the taglib is *NOT* back
> > compatible, while minor is incremented if something is added or
> > deprecated, but back compatibility is maintained.
>
> My preference too, so we are at 2 votes for 2) and one for 1)
Only consider mine half a vote - I'm so laid back about this I'm
horizontal.
> > In the future, we might want to centralize the distribution of XSP
> > taglibs from the above URI, then I suggest we place a sort of "taglib
> > description file" that indicates where the XSP engine can find the
> > appropriate taglib implementation for the required programming language,
> > but this has nothing to do with embedding either the programming
> > language or the XSP engine name (Cocoon or AxKit) in the taglib URI.
>
> Yes, kind a automated CPAN for taglibs. I feel sorry nobody investigated into
> the simple logicsheet language (SILLY) where things like this coud be
> addressed. Also because a SILLY stylesheet will be programming language
> neutral to be ported along different implenetations of XSP.
But you're forgetting that our XSP implementation works completely
differently to yours. While I think SILLY may work for Cocoon, I don't
think it will work for AxKit. Sorry.
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Giacomo Pati <gi...@apache.org>.
Stefano Mazzocchi wrote:
> Giacomo Pati wrote:
> > Donald Ball wrote:
> > > On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > > > Matt Sergeant and I recently had a discussion about the URI of the
> > > > XSP namespace. He wants to release a new version of AxKit and want to
> > > > make that clear before doing so.
>
> Great to hear about such an effort!
>
> > > > IIRC we dicided to follow the pattern:
> > > >
> > > > http://apache.org/xsp/LOGISHEET/VERSION
> > > >
> > > > for the URI of the taglib namespaces. Unforunately we didn't talked
> > > > about the namespace of the core logicsheet of xsp on the lists.
> > > >
> > > > C2 for today uses
> > > >
> > > > http://apache.org/xsp
> > > >
> > > > and C1 is using
> > > >
> > > > http://www.apache.org/1999/XSP/Core
> > > >
> > > > Our proposal for a normalized version is
> > > >
> > > > http://apache.org/xsp/core/VERSION
> > > >
> > > > Is this ok for you all?
> > > >
> > > > What version should it be?
> > >
> > > i'll vote for
> > >
> > > http://apache.org/xsp/core/VERSION
> > >
> > > we should immediately switch c2's xsp namespace uri to use that. we
> > > should also switch the c2 logicsheets to use the new unified xsp
> > > namespace scheme.
> >
> > I totally agree.
>
> I agree as well.
>
> > What pattern should we use for the version? I've actually found two
> > styles:
> >
> > 1) http://apache.org/xsp/esql/v2
> > 2) http://apahce.org/xsp/foo/1.0
>
> I would suggest the use of two numbers 'dot notation' for versioning
> [major.minor] where major is incremented when the taglib is *NOT* back
> compatible, while minor is incremented if something is added or
> deprecated, but back compatibility is maintained.
My preference too, so we are at 2 votes for 2) and one for 1)
> > BTW: I didn't remember if we decided how to name namespaces of cocoon
> > specific logicsheets?
> >
> > 1) http://apache.org/xsp/util/1.0 or
> > 2) http://apache.org/cocoon/util/1.0 or
> > 3) http://apache.org/xsp/cocoon/util/1.0
>
> read below
>
> > Another issue raised into my head is if we should take the targeted
> > language into the namespace url?
> >
> > 1) http://apache.org/xsp/esql/java/2.0
> > 2) http://apache.org/xsp/esql/perl/2.0
>
> I would be against such an approach.
>
> A taglib is, more or less, a namespaced schema fragment. By definitions,
> schemas are programming language neutral. The importance of a taglib is
> the contract that creates between the content and logic concerns. In a
> perfect world, the exact same logic-free page can be moved along XSP
> implementations without even touching namespaces or breaking behavior.
>
> This is clearly not possible 'by design' if we associate the URI with
> the programming language.
I agree.
> In the future, we might want to centralize the distribution of XSP
> taglibs from the above URI, then I suggest we place a sort of "taglib
> description file" that indicates where the XSP engine can find the
> appropriate taglib implementation for the required programming language,
> but this has nothing to do with embedding either the programming
> language or the XSP engine name (Cocoon or AxKit) in the taglib URI.
Yes, kind a automated CPAN for taglibs. I feel sorry nobody investigated into
the simple logicsheet language (SILLY) where things like this coud be
addressed. Also because a SILLY stylesheet will be programming language
neutral to be ported along different implenetations of XSP.
> So, let's see:
>
> - http://apache.org/xsp/major.minor
>
> indicates the XSP namespace, examples are
>
> - http://apache.org/xsp/1.0
> - http://apache.org/xsp/2.1
> - http://apache.org/xsp/103.434
>
> ('core' is implicit so we don't need that, the smaller the namespace the
> better, the easier to remember)
I think we can live with that :)
> the proposed schema for taglibs follows as
>
> - http://apache.org/xsp/taglib/major.minor
>
> where examples are
>
> - http://apache.org/xsp/esql/2.0
> - http://apache.org/xsp/request/3.23
> - http://apache.org/xsp/cookies/1.0
>
> there are a few things that we could place in the URI for the taglibs
>
> - programming language
> - engine specificity (i.e. works on Cocoon2 only since access
> internals)
> - XSP version (i.e. uses features found in 3.0 and not in the 2.x
> series)
>
> but as I wrote above I'd suggest to place this information in a resource
> located at the URI indicated by the namespace instead that placing it
> into the URI directly (which is something equivalent of what the W3C is
> likely going to do for general XML namespaces so we might even be able
> to use or extend their schema for that)
What did you have in mind? RDF?
As I suggested above thing like that could have been addressed by using SILLY
and also automatically extracted from logicsheets written in SILLY.
Giacomo
Re: Normalizing xsp uri namespaces
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
>
> Donald Ball wrote:
> > On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > > Matt Sergeant and I recently had a discussion about the URI of the XSP
> > > namespace. He wants to release a new version of AxKit and want to make
> > > that clear before doing so.
Great to hear about such an effort!
> > > IIRC we dicided to follow the pattern:
> > >
> > > http://apache.org/xsp/LOGISHEET/VERSION
> > >
> > > for the URI of the taglib namespaces. Unforunately we didn't talked about
> > > the namespace of the core logicsheet of xsp on the lists.
> > >
> > > C2 for today uses
> > >
> > > http://apache.org/xsp
> > >
> > > and C1 is using
> > >
> > > http://www.apache.org/1999/XSP/Core
> > >
> > > Our proposal for a normalized version is
> > >
> > > http://apache.org/xsp/core/VERSION
> > >
> > > Is this ok for you all?
> > >
> > > What version should it be?
> >
> > i'll vote for
> >
> > http://apache.org/xsp/core/VERSION
> >
> > we should immediately switch c2's xsp namespace uri to use that. we should
> > also switch the c2 logicsheets to use the new unified xsp namespace
> > scheme.
>
> I totally agree.
I agree as well.
> What pattern should we use for the version? I've actually found two styles:
>
> 1) http://apache.org/xsp/esql/v2
> 2) http://apahce.org/xsp/foo/1.0
I would suggest the use of two numbers 'dot notation' for versioning
[major.minor] where major is incremented when the taglib is *NOT* back
compatible, while minor is incremented if something is added or
deprecated, but back compatibility is maintained.
> BTW: I didn't remember if we decided how to name namespaces of cocoon
> specific logicsheets?
>
> 1) http://apache.org/xsp/util/1.0 or
> 2) http://apache.org/cocoon/util/1.0 or
> 3) http://apache.org/xsp/cocoon/util/1.0
read below
> Another issue raised into my head is if we should take the targeted language
> into the namespace url?
>
> 1) http://apache.org/xsp/esql/java/2.0
> 2) http://apache.org/xsp/esql/perl/2.0
I would be against such an approach.
A taglib is, more or less, a namespaced schema fragment. By definitions,
schemas are programming language neutral. The importance of a taglib is
the contract that creates between the content and logic concerns. In a
perfect world, the exact same logic-free page can be moved along XSP
implementations without even touching namespaces or breaking behavior.
This is clearly not possible 'by design' if we associate the URI with
the programming language.
In the future, we might want to centralize the distribution of XSP
taglibs from the above URI, then I suggest we place a sort of "taglib
description file" that indicates where the XSP engine can find the
appropriate taglib implementation for the required programming language,
but this has nothing to do with embedding either the programming
language or the XSP engine name (Cocoon or AxKit) in the taglib URI.
So, let's see:
- http://apache.org/xsp/major.minor
indicates the XSP namespace, examples are
- http://apache.org/xsp/1.0
- http://apache.org/xsp/2.1
- http://apache.org/xsp/103.434
('core' is implicit so we don't need that, the smaller the namespace the
better, the easier to remember)
the proposed schema for taglibs follows as
- http://apache.org/xsp/taglib/major.minor
where examples are
- http://apache.org/xsp/esql/2.0
- http://apache.org/xsp/request/3.23
- http://apache.org/xsp/cookies/1.0
there are a few things that we could place in the URI for the taglibs
- programming language
- engine specificity (i.e. works on Cocoon2 only since access
internals)
- XSP version (i.e. uses features found in 3.0 and not in the 2.x
series)
but as I wrote above I'd suggest to place this information in a resource
located at the URI indicated by the namespace instead that placing it
into the URI directly (which is something equivalent of what the W3C is
likely going to do for general XML namespaces so we might even be able
to use or extend their schema for that)
Comments?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Normalizing xsp uri namespaces
Posted by Conny Krappatsch <co...@smb-tec.com>.
On Thu, 15 Feb 2001 10:42:32 +0100
Giacomo Pati <gi...@apache.org> wrote:
> Another issue raised into my head is if we should take the targeted
> language
> into the namespace url?
>
> 1) http://apache.org/xsp/esql/java/2.0
> 2) http://apache.org/xsp/esql/perl/2.0
If both implementations define the same syntax (the same tags and
attributes with the same behaviour) in my opinion they shouldn't differ in
namespace.
The editor (i.e. the one who writes XSP pages or stylesheets)
won't/shoudn't care about the language of the XSP processor of a system.
In addition this would make it possible to exchange the editors work
between systems using different target languages.
(Besides, this would put some (little) preasure on the logicsheet
designers to keep there design clear and documented, so that different
implementations stay in sync. ;-)
Just my humble opinion!
Conny Krappatsch
--
______________________________________________________________________
Conny Krappatsch mailto:conny@smb-tec.com
SMB GmbH http://www.smb-tec.com
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> I totally agree.
>
> What pattern should we use for the version? I've actually found two styles:
>
> 1) http://apache.org/xsp/esql/v2
> 2) http://apahce.org/xsp/foo/1.0
I prefer the former, but not for any particular reason.
> BTW: I didn't remember if we decided how to name namespaces of cocoon
> specific logicsheets?
>
> 1) http://apache.org/xsp/util/1.0 or
> 2) http://apache.org/cocoon/util/1.0 or
> 3) http://apache.org/xsp/cocoon/util/1.0
Note that util isn't cocoon specific :-)
Maybe if you had some logicsheet that retrieved information from cocoon's
config files, that would be, but anything else is game for being ported to
AxKit.
> Another issue raised into my head is if we should take the targeted language
> into the namespace url?
>
> 1) http://apache.org/xsp/esql/java/2.0
> 2) http://apache.org/xsp/esql/perl/2.0
I don't think so. I mean ESQL is now 90% or more compatible between the
two implementations (I say only 90% because in the end I decided to rip
out the error handling from ESQL and implemented an exception taglib to do
that).
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> I totally agree.
>
> What pattern should we use for the version? I've actually found two styles:
>
> 1) http://apache.org/xsp/esql/v2
> 2) http://apahce.org/xsp/foo/1.0
I prefer the former, but not for any particular reason.
> BTW: I didn't remember if we decided how to name namespaces of cocoon
> specific logicsheets?
>
> 1) http://apache.org/xsp/util/1.0 or
> 2) http://apache.org/cocoon/util/1.0 or
> 3) http://apache.org/xsp/cocoon/util/1.0
Note that util isn't cocoon specific :-)
Maybe if you had some logicsheet that retrieved information from cocoon's
config files, that would be, but anything else is game for being ported to
AxKit.
> Another issue raised into my head is if we should take the targeted language
> into the namespace url?
>
> 1) http://apache.org/xsp/esql/java/2.0
> 2) http://apache.org/xsp/esql/perl/2.0
I don't think so. I mean ESQL is now 90% or more compatible between the
two implementations (I say only 90% because in the end I decided to rip
out the error handling from ESQL and implemented an exception taglib to do
that).
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Giacomo Pati <gi...@apache.org>.
Donald Ball wrote:
> On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > Matt Sergeant and I recently had a discussion about the URI of the XSP
> > namespace. He wants to release a new version of AxKit and want to make
> > that clear before doing so.
> >
> > IIRC we dicided to follow the pattern:
> >
> > http://apache.org/xsp/LOGISHEET/VERSION
> >
> > for the URI of the taglib namespaces. Unforunately we didn't talked about
> > the namespace of the core logicsheet of xsp on the lists.
> >
> > C2 for today uses
> >
> > http://apache.org/xsp
> >
> > and C1 is using
> >
> > http://www.apache.org/1999/XSP/Core
> >
> > Our proposal for a normalized version is
> >
> > http://apache.org/xsp/core/VERSION
> >
> > Is this ok for you all?
> >
> > What version should it be?
>
> i'll vote for
>
> http://apache.org/xsp/core/VERSION
>
> we should immediately switch c2's xsp namespace uri to use that. we should
> also switch the c2 logicsheets to use the new unified xsp namespace
> scheme.
I totally agree.
What pattern should we use for the version? I've actually found two styles:
1) http://apache.org/xsp/esql/v2
2) http://apahce.org/xsp/foo/1.0
BTW: I didn't remember if we decided how to name namespaces of cocoon
specific logicsheets?
1) http://apache.org/xsp/util/1.0 or
2) http://apache.org/cocoon/util/1.0 or
3) http://apache.org/xsp/cocoon/util/1.0
Another issue raised into my head is if we should take the targeted language
into the namespace url?
1) http://apache.org/xsp/esql/java/2.0
2) http://apache.org/xsp/esql/perl/2.0
Giacomo
Re: Normalizing xsp uri namespaces
Posted by Giacomo Pati <gi...@apache.org>.
Donald Ball wrote:
> On Thu, 15 Feb 2001, Giacomo Pati wrote:
> > Matt Sergeant and I recently had a discussion about the URI of the XSP
> > namespace. He wants to release a new version of AxKit and want to make
> > that clear before doing so.
> >
> > IIRC we dicided to follow the pattern:
> >
> > http://apache.org/xsp/LOGISHEET/VERSION
> >
> > for the URI of the taglib namespaces. Unforunately we didn't talked about
> > the namespace of the core logicsheet of xsp on the lists.
> >
> > C2 for today uses
> >
> > http://apache.org/xsp
> >
> > and C1 is using
> >
> > http://www.apache.org/1999/XSP/Core
> >
> > Our proposal for a normalized version is
> >
> > http://apache.org/xsp/core/VERSION
> >
> > Is this ok for you all?
> >
> > What version should it be?
>
> i'll vote for
>
> http://apache.org/xsp/core/VERSION
>
> we should immediately switch c2's xsp namespace uri to use that. we should
> also switch the c2 logicsheets to use the new unified xsp namespace
> scheme.
I totally agree.
What pattern should we use for the version? I've actually found two styles:
1) http://apache.org/xsp/esql/v2
2) http://apahce.org/xsp/foo/1.0
BTW: I didn't remember if we decided how to name namespaces of cocoon
specific logicsheets?
1) http://apache.org/xsp/util/1.0 or
2) http://apache.org/cocoon/util/1.0 or
3) http://apache.org/xsp/cocoon/util/1.0
Another issue raised into my head is if we should take the targeted language
into the namespace url?
1) http://apache.org/xsp/esql/java/2.0
2) http://apache.org/xsp/esql/perl/2.0
Giacomo
Re: Normalizing xsp uri namespaces
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> Matt Sergeant and I recently had a discussion about the URI of the XSP
> namespace. He wants to release a new version of AxKit and want to make that
> clear before doing so.
>
> IIRC we dicided to follow the pattern:
>
> http://apache.org/xsp/LOGISHEET/VERSION
>
> for the URI of the taglib namespaces. Unforunately we didn't talked about the
> namespace of the core logicsheet of xsp on the lists.
>
> C2 for today uses
>
> http://apache.org/xsp
>
> and C1 is using
>
> http://www.apache.org/1999/XSP/Core
>
> Our proposal for a normalized version is
>
> http://apache.org/xsp/core/VERSION
>
> Is this ok for you all?
>
> What version should it be?
i'll vote for
http://apache.org/xsp/core/VERSION
we should immediately switch c2's xsp namespace uri to use that. we should
also switch the c2 logicsheets to use the new unified xsp namespace
scheme.
- donald
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> Our proposal for a normalized version is
>
> http://apache.org/xsp/core/VERSION
>
> Is this ok for you all?
>
> What version should it be?
BTW: Nobody has answered the above question. For AxKit it makes perfect
sense to be 1.0 (or v1, whichever versioning way you prefer), but Cocoon's
implementation has come a lot further down a path. Of course you're
changing the namespace anyway, so maybe 1.0 is just fine.
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Matt Sergeant <ma...@sergeant.org>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> Our proposal for a normalized version is
>
> http://apache.org/xsp/core/VERSION
>
> Is this ok for you all?
>
> What version should it be?
BTW: Nobody has answered the above question. For AxKit it makes perfect
sense to be 1.0 (or v1, whichever versioning way you prefer), but Cocoon's
implementation has come a lot further down a path. Of course you're
changing the namespace anyway, so maybe 1.0 is just fine.
--
<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 **
\\//
//\\
// \\
Re: Normalizing xsp uri namespaces
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 15 Feb 2001, Giacomo Pati wrote:
> Matt Sergeant and I recently had a discussion about the URI of the XSP
> namespace. He wants to release a new version of AxKit and want to make that
> clear before doing so.
>
> IIRC we dicided to follow the pattern:
>
> http://apache.org/xsp/LOGISHEET/VERSION
>
> for the URI of the taglib namespaces. Unforunately we didn't talked about the
> namespace of the core logicsheet of xsp on the lists.
>
> C2 for today uses
>
> http://apache.org/xsp
>
> and C1 is using
>
> http://www.apache.org/1999/XSP/Core
>
> Our proposal for a normalized version is
>
> http://apache.org/xsp/core/VERSION
>
> Is this ok for you all?
>
> What version should it be?
i'll vote for
http://apache.org/xsp/core/VERSION
we should immediately switch c2's xsp namespace uri to use that. we should
also switch the c2 logicsheets to use the new unified xsp namespace
scheme.
- donald