inkdroid

> Maybe this little post will whet someone else’s appetite to looking closer at PURL as a web infrastructure. I think it also is a great example of how exposed pipes are useful when building applications that are meant to be infrastructure.

I come away with the opposite reaction: exposed "pipes", in this instance, are undesirable. Their being exposed raw probably contributes to the kind of problem that PURLs were created to cure.

URLs are document identifiers foremost—that's what they're supposed to be. Too often, though, they reflect instead the organizational scheme of the current content hierarchy (apt to change at someone's whim sometime in the future) or expose details of the underlying tech stack. You see this in blogs a lot. Take this post, for example. This document's identifier is <https://inkdroid.org/2021/12/16/purl/>. It could just as easily be <https://inkdroid.org/blog/2021/12/16/purl/> or <https://blog.inkdroid.org/2021/12/16/purl/>, and at some point in the future, after a tech migration, it very well might be. This is a problem. I've seen companies submit blog posts to HN, and then just a month or two later switch something up in their publishing pipeline, so now the link at the top of the discussion doesn't resolve anymore. Nobody seems to care about this. In a concrete example I recall, I reached out to someone involved to say that their link is returning a 404, and the response was basically, "Yep. It is. We switched things up," and not, "Oh…

Douglas built the JSON spec

1) to be language agnostic. Following ES5's syntax directions is fine for ES5 focused development, possibly not for others.

2) to be final - i.e. there is no version number. If you want to extend or build something else, I am fairly certain Douglas would prefer that you call it something else. See http://inkdroid.org/journal/2012/04/30/lessons-of-json/ at 5:30 in the video.

Don't take these points as criticisms, I too would like to be able to use single quotes and trailing commas and everything else here. I think though that in order to work with JSON as a static spec, an alternative approach could be to have your project be a layer like HAML, SASS or CoffeeScript. Each of those tools compiles or transforms to conforming input for their target specs rather than replacing them.

You are correct - confirmed in this video: Lessons of JSON

'A recent (and short) IEEE Computing Conversations interview with Douglas Crockford about the development of JavaScript Object Notation (JSON) offers some profound, and sometimes counter-intuitive, insights into standards development on the Web.'

http://inkdroid.org/journal/2012/04/30/lessons-of-json/

{ Thank you Douglas for your vision :) }