cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject [PROPOSAL] XSP taglibs project
Date Thu, 22 Mar 2001 12:52:49 GMT
Hi all,

Would the various taglib authors around here be interested in forming a project
to host them all? I'm thinking of a Cocoon equivalent of the jakarta-taglibs
project (http://jakarta.apache.org/taglibs/)

									 - o -

1) General motivation:

    1.1) Centralize access, unify build system

It seems there are a lot of taglibs scattered around, in various states of
maintenance. Each taglib has it's own setup instructions, documentation (well
some do..), examples, and license. For a new user, the cost of evaluating the
usefulness of these taglibs (and hence Cocoon) is quite high. This could be
greatly improved if these taglibs:
 - were all in one place
 - had a uniform directory structure
 - had a uniform build system for generating examples and documentation

    1.2) Improve quality

It's not simply an issue of pulling together existing taglib distributions
either. Most taglibs are a single file, with perhaps a scattering of examples
and documentation. Taglib authors rightly feel that setting up a formal
"project" around this, with an Ant-based build system, CVS version tracking and
a buglist, is overkill. By pooling these taglibs together, this project
management "overhead" is overcome *once*. From then on, all taglibs may
benefit.

    1.3) Share knowledge

A taglibs project would also provide authors with a focused place for sharing
knowledge, tips, and code. Commonly used templates could be pooled, and
testbeds for clever techniques formed. Increased collaboration should
ultimately increase the quantity and quality of taglibs.

    1.4) Desynchronize taglib releases from Cocoon releases

Another small but important motivation: currently, some important taglibs (fp,
esql, etc) are part of Cocoon, and hence tied down to Cocoon's release
schedules. Users of old versions of Cocoon automatically use old versions of
the taglibs, leading to unnecessary development pain, and traffic on
cocoon-users. Putting these taglibs in a separate project would allow them to
develop according to their own timeframes, and legitimize the process of
upgrading for users who insist on "the official, released" version of things.


2) Cocoon Motivation

There are more Cocoon-specific benefits to be had from pooling taglibs. Each
Cocoon taglib requires a unique namespace. Most taglib authors pick a namespace
URI derived from the company they work for. There are numerous obvious
disadvantages:

 - The company may have nothing to do with the development of the taglib
 - The taglib author typically does not have write access to the location which
   the URI references.
 - The taglib author may change company, rendering the namespace "inappropriate".

If taglibs were kept together, a common, company-neutral namespace could be
chosen, alleviating all the above problems. Users would benefit, because URIs
would be easy to remember, avoiding hard-to-debug errors based on typos.

Having all namespace URIs under central control allows additional interesting
possibilities. One could have all taglibs' namespace URIs point to RDDL[1]
documents. For the user, this would be an instantly-visible link to the
documentation. Cocoon itself could use this metadata in interesting ways:

 - Cocoon could locate the taglib schema from the RDDL doc, and validate the
   user's XSP.
 - Cocoon could fetch the taglib itself! There could be multiple flavors
   of a functionally-equivalent taglib (Cocoon 1, Cocoon 2, AxKit) all
   referenced from the RDDL doc, and Cocoon or AxKit would download and apply
   the appropriate one. Taglibs could ultimately be "self-installing". This
   seems largely in line with Stefano's comments in [2].
 - XSP "IDE" developers (one day..) could exploit this taglib metadata.

None of these exciting possibilities are likely to occur, unless taglibs can be
centralized. Without centralization, the cost to each taglib author of setting
this all up is way too high.


									 - o -

Whew! So, do people think? Are taglib authors interested? In particular, are
the authors of taglibs in the Cocoon distribution (Donald, Jeremy) and in
favour of this? How about AxKit people?

I'd be happy to set up a proposed project structure and build system (based
largely on jakarta-taglibs) of taglibs whose authors give me permission. I
propose the name "xsp-taglibs".

Does this sound like something the XML PMC would consider? Given the precedent
of jakarta-taglibs, this seems reasonable. Otherwise, sourceforge would be a
reasonable alternative.


Thanks for your attention. I do tend to go on a bit, but the whole
namespace/RDDL thing in particular got me excited.

--Jeff


PS: If your name is Matt and you're highly annoyed at my Cocoon-centricity,
please 's/Cocoon/XSP/g' and accept my apologies :) Using "XSP implementation"
instead of "Cocoon" seems too cumbersome, given the target audience. For the
record, none of this is Cocoon-specific.


[1] RDDL: http://www.xml.com/pub/a/2001/02/28/rddl.html
[2] "Re: Normalizing xsp uri namespaces",
  "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."
 -- Stefano Mazzocchi,
  http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=98223507011823&w=2

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message