From b0c376d2a7ded722cd49f88e515c53632ec75730 Mon Sep 17 00:00:00 2001 From: Owen Jacobson Date: Wed, 28 May 2014 16:11:01 -0400 Subject: Typographic fixes around double quotes. --- wiki/cool-urls-can-change.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'wiki/cool-urls-can-change.md') diff --git a/wiki/cool-urls-can-change.md b/wiki/cool-urls-can-change.md index 54795f9..b0c489b 100644 --- a/wiki/cool-urls-can-change.md +++ b/wiki/cool-urls-can-change.md @@ -7,21 +7,21 @@ When I wrote [Nobody Cares About Your Build](http://codex.grimoire.ca/2008/09/24/nobody-cares-about-your-build/), I set up a dedicated publishing platform - Wordpress, as it happens - to host it, and as part of that process I put some real thought into the choice of -"permalink" schemes to use. I opted to use a "dated" scheme, baking the +“permalink” schemes to use. I opted to use a “dated” scheme, baking the publication date of each article into its name - into its URL - for all eternity. I'm a big believer in the idea that a URL should be a long-term name for the appropriate bit of data or content, and every part of a dated scheme -"made sense" at the time. +“made sense” at the time. This turned out to be a mistake. The web is not, much, like print media. Something published may be amended; you don't even have to publish errata or a correction, since you can correct -the original mistake "seamlessly". This has its good and its +the original mistake “seamlessly.” This has its good and its [bad](http://en.wikipedia.org/wiki/Memory_hole) parts, but with judicious use and [a public history](https://github.com/ojacobson/grimoiredotca), amendment is more of a win than a loss. However, this plays havoc with the idea of a -"publication" date, even for data that takes the form of an article: is the +“publication” date, even for data that takes the form of an article: is the publication date the date it was first made public, the date of its most recent edit, or some other date? @@ -33,9 +33,9 @@ willing to commit to. Had I left the date out of the URLs, I'd feel more free to judiciously amend articles in place and include, in the content, a short amendment summary. -The W3C's informal suggestions on the subject state that "After the creation +The W3C's informal suggestions on the subject state that “After the creation date, putting any information in the name is asking for trouble one way or -another." I'm starting to believe that this doesn't go far enough: _every_ +another.” I'm starting to believe that this doesn't go far enough: _every_ part of a URL must have some semantic justification for being there, dates included: @@ -44,7 +44,7 @@ included: render stable, the meaningless blob renders the name immemorable. 2. *Each part must be stable*. This is where I screwed up worst: I did not - anticipate that the "date" of an article could be a fluid thing. It's + anticipate that the “date” of an article could be a fluid thing. It's tempting to privilege the first date, and it's not an unreasonable solution, but it didn't fit how I wanted to address the contents of articles. @@ -59,7 +59,7 @@ for resources that are, themselves, references to other URLs. HTTP is a good example, providing a fairly rich set of responses that all, fundamentally, tell a client to check a second URL for the content relevent to a given URL. In protocols like this, you can easily replace the content of a URL with a -reference to its new, "better" URL rather than abandoning it entirely. +reference to its new, “better” URL rather than abandoning it entirely. Names can evolve organically as the humans that issue them grow a better understanding of the problem, and don't always have to be locked in stone from -- cgit v1.2.3