README: Make an explicit commitment to case-insensitive uniqueness #651
Conversation
|
discussed on call June 14th. Good thing to clarify and really is about over-arching goal of not duplicating identifiers (in any way). But readme is not the right place, this should be part of field description here: https://spdx.org/spdx-license-list/license-list-overview proposed changes to be made via mailing list and will close this PR once changes are made on website. |
If this gets documented somewhere else, I think we need to link that commitment from both this repo and the wording in spdx/spdx-spec#37. I prefer versioned locations for links like that, because they are more resistant to link rot. But this particular issue isn't that important, so some link-rot exposure is acceptable. And personally, I prefer our current in-repo docs for this repo (in the schema XSD) to unversioned external docs (#391). I have no problem with anyone maintaining external docs about the local XML format and semantics, but think those will be much harder to keep current as our schema evolves. |
|
This repo does not exist in a vacuum; it is perfectly reasonable to assume that whoever access this has also access to the main SPDX website where things are explained. |
I'm worried about discoverability, not access. I've been fairly involved with the license list for several months, and feel like I have a fairly good grasp of this repo. But while I know the wiki has team pages and or-later design discussion, I don't know what other information is there or how it's organized. Perhaps some newcomers would guess to look there for this repo's copying statement, but I'd be very surprised if all newcomers guessed to look there. |
|
Ahh, not sure why I thought this would go in the wiki. I'm more comfortable with using the non-wiki portion of spdx.org, but still think it would be easier for all parties to have everything related to maintaining this repo live in or be linked from this repo. The related list thread is here. |
Encouraging case preservation while allowing for case-insentive comparison matches the spec possition discussed in [1]. Note that this is just the list commitment. It *allows* the spec, tools, and other list consumers to decide to be case-insensitive, but does not require them to be either case-sensitive or case-insensitive. [1]: spdx/spdx-spec#63
|
closing as already covered in SPDX spec |
Encouraging case preservation while allowing for case-insentive comparison matches the spec position discussed in spdx/spdx-spec#63. Note that this is just the list commitment. It allows the spec, tools, and other list consumers to decide to be case-insensitive, but does not require them to be either case-sensitive or case-insensitive.