forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: [VOTE] Usage of file.hint.ext convention
Date Mon, 02 Sep 2002 09:33:59 GMT
Nicola Ken Barozzi wrote:

 > Since our users also want to put all the files in a single dir, and
 > since Cocoon needs hints about the contents of the file for an easy
 > usage, I propose that we formalise the
 > file.hint.ext
 > convention, and keep it also in the output of the files.

+0 on source files, -1 on URIs

 > We should always make ext as the *target* or the *source* extension,
 > so that it becomes natural to link for users. Seeing mypage.xml and
 > having to link to mypage.html has confused many already.
 > It could be mypage.html or mypage.xml, but links and filenames need
 > to be the same.
 > IMHO it should be the sources, for multiple output processing.
 > This also comes with the implicit need to change the sitemap to
 > handle all filetypes.

Good argument.

 > Files that don't need to be necessarily processed have no hint
 > (javadocs are html for example).
 > Finally, I have already demonstrated how hints don't break IoC and
 > SoC, since Cocoon can decide what to do with the hint indipendently
 > from the doc writer; it could for example ignore it completely.

But it requires the docwriter to think about the management concern, IMO.

I'm still thinking about those content-aware pipelines, and for some app 
we are developing, we actually have been using this technique doing a 
XML Pull Parse on the document to check its root element - here, we 
could check for its DTD identifier.

I'm vigourously opposing the idea of encoding meta-information twice and 
in different places: inside the document, using its filename, and in the 
request URI.

Consider this scenario:



source          step 1         |   step 2        step 3      step4
A.docv11.xml      -            |   web.xsl      (skin.xsl)   serialize
B.docbook.xml   db2xdoc.xsl    |   paper.xsl                 serialize
                            format [1]

There's two concepts that could help us here:

1) content-aware pipelines, as being articulated in some form in - the grammar of 
the XML source document as being passed across the pipeline will decide 
what extra preparatory transformation steps need to be done

2) views - simple Cocoon views instead of the current skinning system, 
which would oblige us to seriously think of an intermediate 'logical' 
page format that can be fed into a media-specific stylesheet (web, 
paper, mobile, searchindexes, TOC's etc) resulting in media-specific 
markup that can be augmented with a purely visual skinning transformation

Views are currently specified using the cocoon-view request parameter, 
so maybe we could use the request-parameter Selector for that purpose:

       <map:match pattern="**">
         <map:select type="request-parameter">
           <map:parameter name="parameter" value="cocoon-view"/>
           <map:when test="pdf">
             pdf pipeline acting on a 'logical page' view?
           <map:when test="html"/>

Or we could write some Action which uses the URI to specify the choosen 

I know all this is bring us to a slowdown, but I couldn't care less: I 
feel we are deviating from best practices in favor of quick wins.

Caveat: I haven't spent enough time thinking and discussing this, and 
perhaps I have different interests (pet peeves) than others on the list.



Steven Noels                  
Outerthought - Open Source, Java & XML Competence Support Center            

View raw message