Although, if this were to be a URN it would be: urn:uuid:db99a770-f281-11e3-ac10-0800200c9a66 as per RFC 4122.
RFC 4122 also specifies algorithms for generating a UUID from a string using either SHA1 or MD5, which means it could fill the same purpose as your first example below.
From: Brian Slesinsky [mailto:firstname.lastname@example.org]
Sent: Thursday, June 12, 2014 3:47 PM
To: Andy Sterland
Cc: Conrad Irwin; email@example.com; John Lenz; Ron Buckton
Subject: Re: Adding checksums to source maps
I think that sounds pretty reasonable. Agreed that we're not going to put UUID's in source files, so a checksum makes more sense.
Perhaps put the scheme in front:
This looks suspiciously like a URN so maybe we could just use that:
On Thu, Jun 12, 2014 at 3:09 PM, Andy Sterland > wrote:
I think the main reason I was leaning away from the embedded identifier approach is that one of the scenarios where the feature needs to work is when the generated JS file has no source map comments. That enables developers debugging production sites that strip comments to use source maps still. Take for example jQuery which now removes the sourceMappingURL comment from the minified jQuery file.
The jQuery file is here:
They have a comment at the top, so it seems they're not opposed to all comments?
In the release notes , they say: "If you want to use the map file for debugging the minified code, copy the minified file and add a //# sourceMappingURL comment to the end of the file."
So they're aware of the issue and they could have kept the sourceMappingURL comment if they wanted to, but decided it was better to make the developer do it.
We would have to ask them why they took it out, but I would guess that one issue is that it's unclear where the URL should point to avoid a broken link. (Absolute versus relative URL, and so on.) This wouldn't be an issue with a URN, so maybe they'd be fine with leaving it in?