cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Normalizing xsp uri namespaces
Date Thu, 15 Feb 2001 10:46:05 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



Mime
View raw message