forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: URI spaces: source, processing, result
Date Wed, 11 Dec 2002 20:35:47 GMT
Nicola Ken Barozzi wrote:

> 
> Does this make sense?
> 

I really don't know. I have been talking offlist to both you and Jeff, 
and some of this is above my drugged head these days.

Trying to bring the town of you together, I see there is some general 
tendency to tolerate and even advocate some source:/ or scheme:/ like 
think, if not for the same reason. While I love to KISS, the aspect of 
having to declare my links in my future Forrest docs like <link 
href="protocol:name"/> feels kinda good, protocol being things like

  - javadoc
  - code
  - keyword
  - index
  - raw
  - href (default)
  - linkmap (indirection layer, also to aforementioned protocols)

and name being a filename or a named resource name depending on the 
protocol and the eventual indirection

In terms of implementation, some of this will point towards SAXable 
information that must be passed across Cocoon pipelines, some of this is 
external data, perhaps binary in the sense of not being based on XML and 
not serializable as such. So some of this information will require its 
own Source implementation or Generator, some will just need to be copied 
around, either as a file, or as a collection of files. Some of it will 
require link augmentation or resolution, if linkmaps/indirection has 
been used.

With regards to greater datasets, such as massive Javadoc collections, 
I'm not sure whether we would need to try and keep this within the 
concern of Forrest, at least in terms of the static generation of it - 
there exist tools to do that. In terms of doing something with tools 
like qdox, I'm not sure - I think this can be a value for the Forrest 
user: <link href="src:/org.apache.cocoon.foobar"/> bring up a 
syntax-highlighted version of that class.

So maybe we end up with a number of scenarios for these scheme 
implementations:

  - triggering a pipeline generating the target of the link, where we 
need mimetype based extension generation (see, I concur with you, Nicola!)
  - triggering some funny SourceWritinglikeTransformer, _moving_ 
information as-is from source layout to output layout and 'tagging' the 
link so that it doesn't get traversed anymore by the beloved CLI
  - rewriting a link so that, based on some configuration, <link 
href="javadoc:/org.apache.foobar"/> will be rewritten as <a 
href="../../../build/javadocs/foobar.html"/> (I forgot how Javadoc 
generates filenames)

That's the few scenarios I could come up with now. Do we need separate 
components for those? Separate <link/> notations? Have these scenarios 
implemented through passive or active components?...

IMHO: "as few as possible", "no" and "active".

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0103539/
stevenn at outerthought.org                stevenn at apache.org


Mime
View raw message