SAM: add a sentence on case-insensitivity of RG PL (PR #684) #684
Conversation
…itive This is pre-emptively testing a spec change that allows this. See samtools/hts-specs#684.
|
I thought in the meeting we coalesced on the "also accept lowercase" slightly more conservative wording, rather than "accept case insensitively" — though to be sure the effect is similar. |
|
That's possible. I see we now have Otter-AI meeting transcripts as minutes, but I haven't got access (sent a request off). I'm happy to reword it. Thanks for the comments. |
This is not changing what is valid / permitted, and indeed this hopefully clarifies it further. However the practicality of dealing with wide-spread non-compliant data with lowercase PL values is that tools may wish to be lenient and use case-insensitive matching. Fixes samtools#679
|
Updated wording. |
This is not changing what is valid / permitted, and indeed this hopefully clarifies it further. However the practicality of dealing with wide-spread non-compliant data with lowercase PL values is that tools may wish to be lenient and use case-insensitive matching. Fixes samtools#679
… mixed-case This is in response to the change in samtools/hts-specs#684.
|
Also need to update test/sam/failed/hdr.RG6.sam, which lists this file as failed due to |
This is not changing what is valid / permitted, and indeed this hopefully clarifies it further. However the practicality of dealing with wide-spread non-compliant data with lowercase PL values is that tools may wish to be lenient and use case-insensitive matching. Also removes test/sam/failed/hdr.RG6.sam due to explicitly testing against the use of lower-case PL fields. While strictly not conforming, it's overly harsh if we are advocating a more spec-tolerant testing regime for PL. Fixes samtools#679
|
This raises an interesting question on the use of the test data. From above:
I'm hesitant to move test/sam/failed/hdr.RG6.sam to the test/sam/passed directory, as that implies we consider it to be valid. We are clearly still stating that it is not strictly valid. However we are saying that tools need to be lenient and should consider being pragmatic and implement checks in a case-insensitive manner due to widespread non-adherance to the specification. I feel if we wish to have lowercase in the passed folder, then we're pretty much also stating that we should just make the rule case insensitive and drop the statement that it should be in uppercase. So I've simply removed the test file, as a middle ground. Ideally we'd have passed, failed, and warn, but personally I don't have the bandwidth to do that justice. I think it's more in the grey area that Daniel is exploring with StrictSAM, and there are many severity layers of warning too (some of which in my personal view come under the "just write your tool to be more robust" category). |
This is not changing what is valid / permitted, and indeed this hopefully clarifies it further. However the practicality of dealing with wide-spread non-compliant data with lowercase PL values is that tools may wish to be lenient and use case-insensitive matching.
Fixes #679