Following up on this, given recent discussion of adding a <uuid> field to solve the problem of ids that get changed.
Above, I proposed simply freezing existing ids and using UUIDs for new ones, and updating the spec to clarify that the id field is an opaque string rather than a URI.
Adding a <uuid> field has some advantages:
-
People creating new styles wouldn’t be confused by seeing two different
<id>formats in existing styles and not know which to use. -
Implementations that treat the id as anything other than an opaque string now might behave unexpectedly if UUIDs started appearing in
<id>. Hopefully most such code is resilient enough to handle unexpected values when, say, deriving a filename from the id (e.g., to simply use the full string +.cslif there are no slashes, which it should, because technically “a URI” could also mean a URN), but it’s not impossible that there could be unexpected behavior.
But there are also some downsides to having two fields:
-
We’d have to update every single style. That’s easily automated, but it would mean a ton of churn and a loss of meaningful last-update times.
-
Authors would have to populate two id fields in new styles, which would continue the confusion about what exactly was supposed to go in
<id>. -
Implementations would still need to deal with styles without UUIDs as long as they supported older CSL formats, which would mean continuing to treat
<id>as an identifier of some sort. (That could create some weird situations if, say, you installed an old version of the APA style with just an id but had a newer version with both the same id and also a UUID. Are those two styles treated as equivalent, because the id is the same, or is an id in a UUID-less style treated as the same sort of opaque identifier as a UUID and therefore treated as a different style?) This would be more complicated than just making sure<id>was treated as an opaque string. -
I’m not sure we would ever actually want to remove
<id>, because if we did then anyone who still had a pre-UUID style and installed a newer version without an id would end up with a totally separate style. So we’d likely end up keeping this superfluous, confusing field forever.
So while I understand the appeal of transitioning to a new, consistent format, for simplicity I’d probably stick to a single field that was simply defined as opaque.