... more try-outs

testing ideas for more VRS compatibility - absolute WiP!

schemas/LegacyRangeRequest.yaml

@@ -0,0 +1,41 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+$id: https://genomebeacons.org/schemas/beacon/BeaconRangeRequest/v1.1.0
+title: VariantRangeRequest
+description: >-
+  A request for matching variants in a genomic range. This request type requires
+  to provide *exactly* 1 `start` and 1 `end` position, which are both 0-based and
+  define the base range with which variants should be associated. The exact way
+  of variant association (e.g. complete or partial overlap or even proximity) is 
+  being left to the individual implementations and use cases.
+  Beacon version: v2.0
+  Future considerations: There are some inherited ambiguities
+  * `assemblyId` and `referenceName` should be deprectated in favour of a versioned
+    `sequenceId`
+  * the shared use of the `start` and `end` parameters for both base positions and
+    bracket positions is not ideal - here addressed by the `sequencePosition` type
+    but still existing in parameters
+type: object
+required:
+  - referenceName
+  - start
+  - end
+
+properties:
+  referenceName:
+    $ref: variantRequestParameters.yaml#/$defs/referenceName
+  start:
+    $ref: variantRequestParameters.yaml#/$defs/sequencePosition
+  end:
+    $ref: variantRequestParameters.yaml#/$defs/sequencePosition
+  alternateBases:
+    $ref: variantRequestParameters.yaml#/$defs/alternateBases
+  variantType:
+    $ref: variantRequestParameters.yaml#/$defs/variantType
+  assemblyId:
+    $ref: variantRequestParameters.yaml#/$defs/assemblyId
+
+examples:
+  - referenceName: 17
+    assemblyId: GRCh38
+    start: [7572826]
+    end: [7579005]

schemas/VariantRangeRequest.yaml

@@ -7,32 +7,27 @@ description: >-
   define the base range with which variants should be associated. The exact way
   of variant association (e.g. complete or partial overlap or even proximity) is 
   being left to the individual implementations and use cases.
-  Beacon version: v2.0
-  Future considerations: There are some inherited ambiguities
-  * `assemblyId` and `referenceName` should be deprectated in favour of a versioned
+  Beacon version: v2.n
+  There are some inherited ambiguities
+  * referenceName` should be deprectated in favour of a versioned
     `sequenceId`
   * the shared use of the `start` and `end` parameters for both base positions and
     bracket positions is not ideal - here addressed by the `sequencePosition` type
     but still existing in parameters
 type: object
 required:
-  - referenceName
-  - start
-  - end
+  - sequenceId
+  - sequenceInterval
 
 properties:
-  referenceName:
+  sequenceId:
     $ref: variantRequestParameters.yaml#/$defs/referenceName
-  start:
-    $ref: variantRequestParameters.yaml#/$defs/sequencePosition
-  end:
-    $ref: variantRequestParameters.yaml#/$defs/sequencePosition
-  alternateBases:
+  sequenceInterval:
+    $ref: variantRequestParameters.yaml#/$defs/sequenceInterval
+  sequence:
     $ref: variantRequestParameters.yaml#/$defs/alternateBases
   variantType:
     $ref: variantRequestParameters.yaml#/$defs/variantType
-  assemblyId:
-    $ref: variantRequestParameters.yaml#/$defs/assemblyId
 
 examples:
   - referenceName: 17

schemas/variantRequestParameters.yaml

@@ -93,7 +93,7 @@ $defs:
     minItems: 1
     maxItems: 1
 
-  sequenceBracket:
+  sequenceInterval:
     description:
       This is an explicit 2-values version of the `basePositions` generic, for use
       in e.g. `VariantBracketRequest`.