forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: File prefix again (Re: Cocoon CLI - how to generate the whole site)
Date Tue, 17 Dec 2002 15:52:22 GMT
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:
> [...]
> >
> >Your view is perfectly clear and simple: schemes are aliasing mechanisms
> >to simplify linking to the destination URI space.
> >
> >My view only makes sense once you a) buy into the notion that the Source
> >URI space exists and is distinct from the Destination URI space, b)
> >understand that, given a), the implied *source* protocol for links is
> >currently 'cocoon:'.  Only then does the reason for file: become
> >apparent: static links do _not_ have the implied 'cocoon:' scheme.  We
> >need a different scheme to disambiguate, say, a static index.pdf, and an
> >index.pdf generated from index.xml.
> 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.

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

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

> >>>Secondly, introducing a 'file:' prefix fixes the current name clash
> >>>problem.  What if I have a static file called 'index.pdf'?  How do I
> >>>access the index.pdf generated from XML?  I can't, because the
> >>>resource-exists will always choose for me.
> >>
> >>Which is another seemingly good point, but since we have decided that 
> >>link URIs should not end in extensions, because of many reasons one of 
> >>which is the fact that a URI can reference different formats at 
> >>different times in history, having a scheme that effectively makes me 
> >>serve two different versions of the same file is totally off-target.
> >
> >See above.  There is _no way_ that a sitemap, with MIMETypeActions and
> >resource-exists and any other crazy hacks you care to name, can 100%
> >correctly choose between a static index.pdf and one generated from
> >index.xml.  Simply cannot, because there is missing info only the user
> >knows.  That is what the file: prefix adds.
> Reread my point.
> 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.

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?

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.

If you agree to both of those, then you'll agree that adding a file:
prefix to address static files makes conceptual sense.  If, in
pathological cases, that causes conflicts in the destination URI space,
well that's too bad; we'll fix it eventually.  Conceptually we did the
right thing.


View raw message