Re: URL Theory & Best Practices

[Justin Fagnani-Bell]

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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>