Proposal: Make style ids immutable

CSL Development
5

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.

1 Like