Re: explanation for ensuring no duplicate identifiers
W. Trevor King
On Thu, Jun 14, 2018 at 01:28:11PM -0600, J Lovejoy wrote:
• Short identifiers must not be duplicative: newly added shortWherever we put this commitment, I think we also want something like [1]: List consumers are enouraged to use the canonical identifier casing, but this uniqueness commitment ensures that case-insensitive comparison with listed identifiers will be unambiguous. In a spec, I'd make that a SHOULD recommendation [2]. Encouraging the use of canonical casing reduces the need for a case-canonicalizer [3], by giving tools that choose not to implement a canonicalizer something to point at if/when users complain about unrecognized, non-canonical identifiers. It also makes it less likely that tools decide to change the case without thinking about downstream compatibility (e.g. [4]). I also prefer focusing on the list state (across versions) instead of using "newly added" to focus on changes to the list state. For example, my earlier wording [5]: This project commits to never, in any past or future version, contain identifiers which differ only in case but have different semantics. makes it clear that the current list is already free of case-insentive ambiguity. With the "newly added" wording, we could already have case-insentive ambiguous IDs and just be committing to not adding more. Cheers, Trevor [1]: https://github.com/spdx/license-list-XML/pull/651/files#diff-04c6e90faac2675aa89e2176d2eec7d8R16 [2]: https://tools.ietf.org/html/rfc2119#section-3 [3]: https://github.com/spdx/spdx-spec/issues/63#issuecomment-366370691 [4]: https://github.com/benbalter/licensee/issues/282 [5]: https://github.com/spdx/license-list-XML/pull/651/files#diff-04c6e90faac2675aa89e2176d2eec7d8R14 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy |
|