forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: File prefix again (Re: Cocoon CLI - how to generate the whole site)
Date Wed, 18 Dec 2002 14:23:03 GMT

Jeff Turner wrote:
> On Tue, Dec 17, 2002 at 03:07:57PM +0100, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote:
>>>On Mon, Dec 16, 2002 at 04:08:37PM +0100, Nicola Ken Barozzi wrote:


>>Static or generated there is no difference. The use should not even know 
>>if Cocoon does something with it.
> Yes! +1000.  But first, the user needs to identify what "it" is.  Is "it"
> the PDF rendition of index.xml, or the index.pdf file sitting on my
> harddisk?  They are two different Sources, containing completely
> different content, and they deserve different Source URIs.

My point is that there should be just one "index" file, whatever 
extension it has.

>>This is important. This is why I say that you are mixing concerns.
> Identifying the source is the user's concern.  That is the I in URI.  We
> have two different Sources, we need two different URIs.

Excactly the point. Me says that we can have only one source with the 
same name. I don't see the need of having two.

>>What if the sitemap guy would want to take the PDF and transform it; 
>>with the file: protocol you are making this not possible. You are taking 
>>away from the sitemap the possibility of doing what the heck it wants 
>>with the files.
> I don't get this.  How can PDFs be transformed?

There are Java libraries that read PDFs. What would be really cool is to 
have a reader or something like it that uses a PDF as a template.
Using FOP for just filling out forms is overkill, we just need templating.

This is a general use case of PDF transformation, and another that I 
would really like to see is to generate a "non-controlled copy" stamp on 
the PDF for the management of ISO9001 documentation.

Or simply by adding a copyright statement.


>Imagine I have
>> ./index.xml
>> ./index.pdf
>>If I link like this
>>  <link href="index"/>
>>Cocoon serves only one, as defined in the sitemap rules.
>>If I introduce the file: protocol, I can do:
>>  <link href="index"/>           ->  serve index.xml
>>  <link href="site:index.pdf"/>  ->  serve index.pdf
>>Problem is, how can the browser as for
>>  http://domain.ext/path/to/index
>>and have one or other result?
>>What would the above URL yield?
> Excellent point :)  One I completely missed.  So you're saying that
> disambiguating 'cocoon:index.pdf' and 'file:index.pdf' is well and good,
> but it causes a name clash in the Destination URI space.
> Simple enough answer: we need two create two destination URIs, because
> there are two Source URIs.  Eg, generate:
> http://localhost:8888/index.pdf    # The static index.pdf
> http://localhost:8888/index~.pdf   # index.pdf generated from XML   
> But this is an implementation detail.  What I'm concerned about now is
> whether disambiguating the sources makes sense _conceptually_.
> So say we have two distinct Source URIs: a static index.pdf file, and the
> PDF rendition of index.xml.  In "ideal world" syntax, we can write those
> two as:
> <link href="index.pdf">
> <link href="index.xml" type="application/pdf">
> In "real world: Jeff style" syntax, they'd be written as:
> <link href="file:index.pdf">
> <link href="index.pdf">
> In "real world: Nicola style" syntax, there'd just be:
> <link href="index.pdf">
> and you simply can't have an index.pdf file.

Not exactly.
If you have index.xml, that becomes the index.pdf.
If you have index.pdf, that becomes the index.pdf.

One filename, one result.

> Firstly: do you agree that there _are_ two Sources?  That the user
> _could_ create an index.pdf?  In fact, considering that the user isn't
> meant to know that index.xml even *has* a PDF rendition, why shouldn't
> they create an index.pdf?

I don't agree here. The user creates documents to explain a concept. 
"index" means it's the index. Who cares what the rendition is.
Imagine the user making an index.xml and index.xhtml file in the same 
dir. Does it make sense?

> Secondly, do you agree that conceptually, any source of content should be
> assigned a Source URI?  _Regardless_ of whether it has a Destination URI?
> Because Source and Destination URI spaces have no direct relation.  Heck,
> I could generate a single PDF containing the entire site, thus mapping
> lots of Source URIs to a single Destination URI.

Yes, on this I agree. We should always link to source URIs, so that what 
you explain about a single PDF can be possible. And it's also easier for 
the user. +1

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message