cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Fagnani-Bell <jus...@paraliansoftware.com>
Subject Re: URL Theory & Best Practices
Date Sun, 10 Nov 2002 00:23:21 GMT

On Saturday, November 9, 2002, at 12:08  PM, Miles Elam wrote:

> Tony Collen wrote:
>
>> Comments inline...
>>
>> Miles Elam wrote:
>>
>>> But can't delivered types differ by the incoming client?
>>
>> Yes, but a problem then arises when someone is using IE and they want 
>> a PDF, when your user-agent rules will only serve a PDF for FooCo PDF 
>> Browser 1.0.  IMO browsers should respect the mime-type header.  I 
>> believe the mime-type headers is very useful when you want to use 
>> something like a PHP script to send an image or a .tar.gz file.  In 
>> fact, it's essential for it to work, otherwise the browser interprets 
>> the data as garbage.
>
> No, that's wasn't my intention at all.  If someone is using IE and 
> they want a pdf (not a default expectation for that particular browser 
> like html or xml), then the URL they would get directed to would be 
> *.pdf. This is not the intrinsic resource.  You are explicitly asking 
> for the PDF representation of that resource.
>
> If the browser's default expectation is PDF (like in your FooCo PDF 
> Browser 1.0 example), the trailing slash resource would give it PDF. 
> However, it could still be pointed to *.pdf if you wanted to make it 
> explicit.

This is very well put Miles, and was my intention with the previous 
email I wrote. Content negotiation and file extensions can (and IMO 
should) exist side-by-side. There is no precedent for a browser 
changing its accept header on a per-request basis, as someone 
suggested, not is there a way to specify this behavior in a hyper-link. 
If you have a link on a site that says "Click here for a PDF" then I 
would expect that the URI would end in .pdf, at least that's what makes 
the most sense to me.


> In those cases where only PDF is available (common when it's not 
> dynamically generated), I see no reason why the URI wouldn't be *.pdf.

Exactly.

>>> This is where we differ slightly.  In my mind /a/b/ is the intrinsic 
>>> resource.  /a/b/index.html is the explicit call for HTML 
>>> represention of /a/b/.  If you redirect a client to /a/b/index.html 
>>> and the client bookmarks it, they are bookmarking the HTML 
>>> representation, not the intrinsic resource.

This is definitely where we differ. I don't see why an intrinsic 
resource should always end in a '/'. If /a/b.pdf is the PDF 
representation then why shouldn't /a/b be the intrinsic resource? The 
only reason I see why the trailing slash is recommended is because 
developers are used to having their URI space tied to their filesystem 
structure with a static server like Apache. The trailing slash, from 
our experience with filesystems,  indicates that something is a 
directory, that it has children. But in a URI a resource can be both a 
viewable resource and a container node at the same time. There's 
certainly nothing stopping /a/b/, /a/b, /a/b.pdf and /a/b/c.pdf from 
all being valid URI's in the same space. To me the trailing slash 
simple indicates that there's more to come at lower levels, and the 
absence of it means the resource is a leaf.

As for redirects, I don't see it being too much of a problem with more 
recent protocols. Also it should only happen when a visitor is being 
referred from an external page, since all the URL's in your site should 
be in the correct form. If you are linking to the intrinsic resource, I 
don't see the need for a redirect (as long as the browser correctly 
understands the mime-type header), so I don't see a problem with 
bookmarking.

> - Miles
>
> P.S.  Thank god for the mailing lists.  They actually encourages me to 
> write down some of my thoughts.  Even they are off the mark more often 
> than not...  Does this make email better than web or simply justify 
> the need for more discussion on the web?

Here here. I say both, linear discussion is good, so is collaboration. 
A discussion board combined with a wiki would be awesome. Discuss a 
topic and collaborate on a document summing up the ideas at the same 
time. Hmm... Cocoon could do that :)

-Justin


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message