forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [VOTE] Usage of file.hint.ext convention
Date Mon, 02 Sep 2002 10:05:47 GMT

Steven Noels wrote:
> 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.

They still write mydoc.xml or mydoc.gif, no?
This isn't a management concern, no?

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

It's neat, but a PITA for many users.

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

Conceptually I agree, the hint is a "hack".

> 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 
> http://marc.theaimsgroup.com/?t=102767485200006&r=1&w=2 - the grammar of 
> the XML source document as being passed across the pipeline will decide 
> what extra preparatory transformation steps need to be done

Ok.

> 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

Man, that's what I've been advocating all along.

I think that the document.dtd can be such a step.
The switch to using XHTML for it is *exactly* this.

Users that want to write a generic document use that dtd.
All other content that must be "skinned" by forrest must be pregenerated 
by other tools to give that dtd.

We still have status.xml... etc files that get automatically transformed 
to that format.

I have been advocating the two step process since I started using Cocoon 
(see also mails to the cocoon users for example), so I'm +10000 for it 
being formailzed :-D

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

*This* -1.

The hack of putting the intermediate step in the name is to make URI 
space indipendent from the output space; you say that even that pollutes 
the URI (I agree), and this is a step back.

The best think would be to understand something about the client 
automatically, but also a request parameter can be ok.

The point is, can we use them in statically generated documentation?

We cannot.  :-/

So we simply should say that the output format is given by the filename, 
but this is the output, not th input, and this brings us back to the 
problem that writers should concentrate on the input, and use that for 
the links to have view indipendence.

See, browser technology constrains us :-/

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

What you propose is the best route, but we need to be faster.

Ok, let's go into it.

1) have two step process standard +1
2) switch documentdtd to be the intermediate format and become akin to 
XHTML2 as in previous mails +1
3) use content-aware pipelines - see below
4) link the sources, not the results.

This is cool but what gets generated when I have
  file.xml -> file.html
  file.html -> file.html
Both in the same dir?

If I link to file.xml, I get the link translated to file.html, but then 
what file do I get to see?

This is the reason why we need a 1-1 relationship.

Now to explain the why of the double ext (again):

We have file.xml

- user must link using the same filename

  link href"file.xml"

- the browser needs the filename with the resulting extension:

  file.html

- the system needs to have unique names

So this brings us *necessarily* to having both xml and html included in 
the extension.
xml for unicity, html for the browser.

Or maybe have it just become with double extension only with clashing 
names, but then, how can the user tell to generate a pdf out of it if 
there is only .xml extension?

You say it shouldn't know, because part of the view?
Go tell the users.
And how can they do it without breaking the uri?

Ha.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message