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 Tue, 17 Dec 2002 14:07:57 GMT

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. This is important. This is why I say 
that you are mixing concerns.

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 described this notion of separating the Source and Destination URI
>>>space in a RT:
>>I read it, and I basically agree with it, except the above distinction 
>>which wasn't clear to me in the first place.
>>>So that is the theory: it is better to have an explicit file: scheme,
>>>because it distinguishes those URIs from the implied 'cocoon:' scheme,
>>>and fits in better in a world where there are schemes everywhere.
>>Please expand on this. Do you mean file scheme=sources and cocoon 
>>scheme=resulting URI space?
> Yes.
> In a perfect world, the default scheme would be file:, not cocoon:.  So
> we could have <link href="primer.xml">, or <link href="hello.pdf">.
> Then, a linkmap would genuinely be an aliasing mechanism, but aliasing in
> the _Source_ URI space.  Eg, <link href="site:/primer"> would be exactly
> equivalent to <link href="primer.xml"> (or ../primer.xml or
> ../../primer.xml etc).  Ignore this paragraph if it doesn't make sense..

It kinda does.
I buy in the idea that I should link only to source files, and have the 
resulting URI space be created by the sitemap. But I don't buy the fact 
that in the perfect world I use the extension to reference the file, 
this because of the last comment below.

>>>Practically, right now, what is the difference?
>>>Well for a start, if we consistently used 'file:' for URIs identifying
>>>static files, we could throw away the current resource-exists action:
>>> <map:match pattern="**">
>>>   <map:act type="resource-exists">
>>>    <map:parameter name="url" value="content/{1}"/>
>>>    <map:read src="content/{../1}"/>
>>>   </map:act>
>>>   ....
>>>And replace it with a simple sitemap rule:
>>> <map:match pattern="file:**">
>>>   <map:read src="content/{1}"/>
>>> </map:match>
>>Which is something I don't like.
>>Again, you are telling Cocoon how to treat that file, which is not a 
>>concern of the editor.
> The implied URI scheme is 'cocoon:'.  By adding a 'file:' prefix, the
> user is saying "no, this file is local".  There is nothing wrong with
> this, and no other way to distinguish between, say, a static index.pdf
> and one generated from index.xml.  

And there should not be. Se below again.

>>>Having to interrogate the filesystem to decide a URI's scheme is a total 
>>>What happens if our docs are stored in Xindice, or anything other than a
>>>filesystem?  Resource-exists is going to break.
>>Hmmm, this is a good point, but not a resource-exists "conceptual" 
>>problem. I can test if a resource exists also in remote repositories.
>>If the "file:" thing takes care different backends, there is no reason 
>>why a better resource-exists cannot. So seems is more about the 
>>deficiencies of the resource-exists implementation rather than the need 
>>of a site: scheme.
> Say I want to link to a static index.pdf, but I forget to create it.  I
> want that link to break!  I don't want Cocoon to be clever, and create
> one from index.xml.  Resource-exists is an utter hack that doesn't
> (cannot!) meet use-cases like this, because ultimately, only the user can
> know if they are referring to a local file, or one generated by Cocoon.

Given that we have ruled out extensions in the links, there can be only 
one file with the same name in the same dir. Hence there is no ambiguity.

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


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


and have one or other result?

What would the above URL yield?

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

View raw message