Typographic fixes around double quotes.

1 files changed, 8 insertions, 8 deletions

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