Body: <p>I'm writing a <a href="https://github.com/revl/vcf_scanner" rel="nofollow noreferrer">VCF parser</a>, so I have to consider and handle all corner cases regardless of how contrived they may seem. The specification is a bit unclear about the MISSING value ('.') in the ALTS column:</p>
  <blockquote>
  <p>Options are base Strings made up of the bases A,C,G,T,N,*, (case insensitive) or a MISSING value ‘.’  (no variant) or an angle-bracketed ID String (“”) or a breakend replacement string.</p>
  </blockquote>
  <p>I've seen examples with a single dot in the ALTS column:</p>
  <pre><code>4       31789170        PTV021  G       .       77      PASS    .
  </code></pre>
  <p>The question is whether the following data lines are also valid:</p>
  <pre><code>1       12345   ID1     A       .,T,.   22.88   PASS    .
  1       12346   ID2     G       C,.     22.88   PASS    .
  </code></pre>
  <p>In other words, does MISSING indicate that the entire ALTS field is missing, or does it mean that there's a missing allele?</p>
  <p>By extension, how do I represent the case when there's a single dot in the ALTS field (as in the first example)? Is it an empty list (because the whole field is MISSING) or is it a list containing a MISSING value? In other words, is it <code>[]</code> or <code>[&quot;.&quot;]</code>?</p>
  <p>At the moment, the parser does not validate the contents of the ALT field and does not even attempt to resolve any ALT IDs from the header. Interpretation of the ALT values is left entirely to the client code.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-08-05T14:31:58.747Z
Comments.Text: Is your parser intended to parse vcfs containing just SNPs, or different kinds of structural variants as well?
Comments.UserDisplayName: user438383
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-08-06T21:35:18.033Z
Comments.Text: At the moment, the parser does not validate the contents of the ALT field and does not even attempt to resolve any ALT IDs from the header. Interpretation of the ALT values is left entirely to the client code.
Comments.UserDisplayName: revl
Tags: <vcf><parsing>
Title: VCF spec: is it possible to have other alleles in addition to the MISSING value ('.') in ALTS?
ThreadText: # VCF spec: is it possible to have other alleles in addition to the MISSING value ('.') in ALTS?
  
  (Asked by: username_0 on 2020-07-18)
  
  I'm writing a [VCF parser](https://github.com/username_0/vcf_scanner), so I have to consider and handle all corner cases regardless of how contrived they may seem. The specification is a bit unclear about the MISSING value ('.') in the ALTS column:
  
  > Options are base Strings made up of the bases A,C,G,T,N,\*, (case insensitive) or a MISSING value ‘.’ (no variant) or an angle-bracketed ID String (“”) or a breakend replacement string.
  
  I've seen examples with a single dot in the ALTS column:
  
  ```
  4       31789170        PTV021  G       .       77      PASS    .
  
  ```
  
  The question is whether the following data lines are also valid:
  
  ```
  1       12345   ID1     A       .,T,.   22.88   PASS    .
  1       12346   ID2     G       C,.     22.88   PASS    .
  
  ```
  
  In other words, does MISSING indicate that the entire ALTS field is missing, or does it mean that there's a missing allele?
  
  By extension, how do I represent the case when there's a single dot in the ALTS field (as in the first example)? Is it an empty list (because the whole field is MISSING) or is it a list containing a MISSING value? In other words, is it `[]` or `["."]`?
  
  At the moment, the parser does not validate the contents of the ALT field and does not even attempt to resolve any ALT IDs from the header. Interpretation of the ALT values is left entirely to the client code.
  
  **Tags:** vcf, parsing
  
  > **Comments:**
  > **username_1**: Is your parser intended to parse vcfs containing just SNPs, or different kinds of structural variants as well?  
  > **username_0**: At the moment, the parser does not validate the contents of the ALT field and does not even attempt to resolve any ALT IDs from the header. Interpretation of the ALT values is left entirely to the client code.  
  
  ---
  
  ## 0 answers
  
  