Daniel Cameron

Yes, the essence of the request is the same as those.

>However, [test/vcf/4.3/passed/passed_body_format.vcf](https://github.com/samtools/hts-specs/blob/7ab198a5b665766c039dc980d802dce299795e67/test/vcf/4.3/passed/passed_body_info.vcf) shows Flag INFO fields with explicit values (0 and 1). Is this valid? The example is incorrect and they should fail validation. There's no exception to Number=0 in...

>The deprecation seems to be motivated purely by the redundancy brought by SVLEN. Quite the opposite. END was deprecated in favour of FORMAT LEN as END is incompatible with per-sample...

It does sound like some more clarifying text is needed. > It should state correctly that INFO/END can be derived from FORMAT/LEN, when the latter is present, and is not...

It's also confusing that `END` is defined both in Section 1.6.1.8 and in Section 3 but the section 3 copy has basically no information in it and doesn't cross-link back...

@pd3: please provide feedback on the #844 PR as to whether it adequately addresses your concerns around INFO END deprecation. Sorry for the delay in getting the PR together.

> `G,G,C` These aren't valid `ALT` alleles. The wording of that particular sentence in 1.6.1.5 was indeed unclear but was updated in 4.4 to explicitly seperate the "strings of bases"...

> This is also the case for for the symbolic allele , but that is stated to be an exception in section 1.6.1 REF: The way it is currently worded...

> Considering the following alignment, how can the three alternative alleles be specified as symbolic : ``` 1 234 ref POS -G-GGG ref -GAGGG alt1 AG-GGG alt2 -CAGGG alt3 ```...

Secondary are supplementary are quite different. Secondary is an entirely different alignment, where as supplementary records encode chimeric alignments. The tags by themselves leave ambiguity but that is resolved by...