forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <>
Subject RE: [VOTE] Usage of file.hint.ext convention
Date Mon, 02 Sep 2002 10:32:25 GMT
> From: Steven Noels [] 
> 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.

IMO, the URI should indicate the output format and that's why usually *.html
is used in pipelines instead of XML or so, even the source is XML. 
So, I'm with Steven on this: -1 on URIs, as for the source files - that can
use any naming format that is needed, so +0.

>  >
>  > 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.

The document URL can be indication of the DTD. You can use:
/my-dtd/doc.html to process one kind of documents
/other-dtd/doc.html to process the other kind

What's wrong with it?

> 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.

I think that the only indication of the document type should be the URI and
not the filename. We can use any complex URIs for document handling, e.g.:
/faq/*.html, /index.html, /docs/primer.html[1], etc. The URI prefix can
define the processing pipeline for a particular document type, the extension
of the doc will indicate the output format and at last some additional
information can come from the postfix - [1] in this case is the page number.

> Consider this scenario:
> URI:
> http://somehost/documentnameA.html
> http://somehost/documentnameB.pdf
> source          step 1         |   step 2        step 3      step4
>                                 |
> A.docv11.xml      -            |   web.xsl      (skin.xsl)   serialize
> B.docbook.xml   db2xdoc.xsl    |   paper.xsl                 serialize
>                                 |
>                                 ^
>                              logical
>                                view
>                             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

Where should this information come from? Is the document itself responsible
for carring this information, or it will be hard-coded in sitemap or matched
by a special matcher? Or some other way?

> 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>
>            <map:when test="html"/>
>          </map:select>
>        </map:match>

Why would you need a selector if Cocoon can do the same thing without it?
The views were invented exactly for this kind of things. You can put a label
on the generator and then implement all the needed transformations in the
definition of the view. Isn't it what you are proposing or I got you wrong?

> Or we could write some Action which uses the URI to specify 
> the choosen 
> view/rendition.
> 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.

The same is here. 
And I am currently working on non-Cocoon related things, so maybe I didn't
up-to-date with the current state of Forrest. Hope to be back in a couple of


> </Steven>
> ----
> [1]
> </Steven>
> -- 
> Steven Noels                  
> Outerthought - Open Source, Java & XML Competence Support Center

View raw message