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 +.csl
if 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.