nasa-ammos/seq-json-schema

Standardized JSON Schema for authoring multi-mission sequences.

seq-json-schema

Standardized JSON Schema for authoring multi-mission sequences. You can read the schema definition here.
You can use our validation site to validate a .seq.json document against the latest schema.

JavaScript or TypeScript

Install

npm install @nasa-jpl/seq-json-schema --save

Basic Usage

import seqSchema from '@nasa-jpl/seq-json-schema/schema.json' assert { type: 'json' };
console.log(seqSchema);

TypeScript Types

This library also ships with automatically generated TypeScript types from the schema. For example:

import type { Command, SeqJson } from '@nasa-jpl/seq-json-schema/types';

const command: Command = {
  args: [],
  stem: 'SEND_DATA',
  time: { type: 'COMMAND_COMPLETE' },
  type: 'command',
};

const seqJson: SeqJson = {
  id: 'sequence0',
  metadata: {},
  steps: [command],
};

console.log(seqJson);

Python

Install

pip install seq-json-schema

Basic Usage

import importlib.resources
import json

with importlib.resources.path('seq-json-schema', 'schema.json') as schemaPath:
  file = open(schemaPath)
  schema = json.load(file)
  print(schema)

Note if you are using a Python version lower than 3.7 you will have to import the schema using the importlib-resources library.

seq-json-schema's Issues

Make argument format more explicit

We need to make the argument format more explicit for the args definitions. Here is the proposed new format:

{
  "name": "some_arg_name",
  "type": "number",
  "value": 0.0
}

Each argument type (string, number, boolean, symbol, hex, repeat), should have a type and value with an optional name.

Enforce repeat arg arrays have the same types

Currently the schema allows the following:

{
  "type": "repeat",
  "value": [
    [
      { "type": "number", "value": 10 },
      { "type": "string", "value": "another_test" },
      { "type": "boolean", "value": false }
    ],
    [
      { "type": "string", "value": "5" },
      { "type": "string", "value": "repeat_test" },
      { "type": "boolean", "value": true }
    ]
  ]
}

This is objectively wrong. Can we enforce each inner-array has the same set of types (in order)? Not sure if this is possible.

SEQ JSON Schema $id URI resolvable

Checked for duplicates

Yes - I've already checked

Is this a regression?

No - This is a new bug

Version

1.3.0

Describe the bug

$id should be a resolvable URI.
For Example: v1.0.17 should be:
https://github.com/NASA-AMMOS/seq-json-schema/tree/v1.0.17

This would allow users to validate against the schema without downloading and including in code.

Reproduction

visual

Logs

No response

System Info

v1.0.17

Severity

Annoyance

Make structure of all argument types consistent

Currently the step agrs types use both primitives and objects. For example strings, booleans, and numbers just use the base JSON schema primitive types (e.g. "", false, or 0.0).

Where hex or symbol arguments use the format { "hex": "0x0001AC34" } or { "symbol": "Local_Var_A" } respectively.

This task is to make the formats consistent. So for strings, booleans, and numbers we would use the format:

{ "string": "" }
{ "boolean": false }
{ "number": 0.0 }

This would make the format of args consistent for all args and thus make downstream parsing easier.

Disallow additional properties in top-level schema

Additional top-level properties are currently allowed in the schema. We should add "additionalProperties": false to the top-level schema to prevent.

Repeat argument fixes

We need to:

1. Remove the nested repeat argument since it's not supported in the AMPCS command dictionary spec:
   

   seq-json-schema/schema.json

   Line 445 in b56782b

   "$ref": "#/$defs/repeat_argument"

2. Make the repeat arg an array of arrays so we can actually repeat the arguments.
   

   seq-json-schema/schema.json

   Line 424 in b56782b

   "value": {

We should add tests that cover both of these changes.

Step Time Schema Improvements

Capturing ideas from a couple different conversations for consideration here.

1. Enforce in the schema that absolute, epoch-relative, and command-relative times all have the tag field populated
2. Enforce a format on the tag fields (e.g., YYYY-DOYTHH:MM:SS[.sss] for absolute, [DOYT]H:MM:SS[.sss] for command-relative, and [+|-][DT]HH:MM:SS[.sss] for epoch-relative).

Add multiple numeric argument types (int, float, and unsigned)

Currently numeric arguments only support the number type. This task is to replace number with more numeric argument types in accordance with the AMPCS command dictionary argument types. The AMPCS types are:

• int
• float
• unsigned
• numeric (this is deprecated according to AMPCS so we probably should not include it)

Handle repeat arguments in steps

This is to add arrays to the args to handle repeat arguments. For example for a command step this would look something like:

{
  "stem": "FAKE_COMMAND1",
  "args": [
    { "hex": "0xFFFFFFFF" },
    [
      [0, 1],
      [0, 1]
    ]
  ],
  "time": { "type": "COMMAND_COMPLETE" },
  "type": "command"
}

Where the second argument is a repeat arg with two repeating arguments, each consisting of two number arguments. The first argument is not a repeat arg.

Replace hardware_commands and immediate_commands with realtime_commands

This task is to replace hardware_commands and immediate_commands with an array called realtime_commands. The array should still take the immediate_command and hardware_command objects, but add a type property to them with the value "immediate_command" and "hardware_command" respectively. Immediate and hardware command objects should still not be allowed in the steps array.

SLIM integration: Infusion of Lab-approved documentation and templating standards

Checked for duplicates

Yes -- New feature, new files.

Alternatives considered

Yes - This is a Lab-approved and suggested addition to all NASA-AMMOS repositories.

Related problems

Many repos don't provide comprehensive documentation and/or are missing key areas of standardized documentation focus. This feature adds standardized documentation per Lab-approved standards.

Describe the feature request

A number of template and documentation files are being added to the repository in support of the SLIM project. These files are suggested by MGSS and will serve to promote cohesion between NASA-AMMOS products. The files provided are tailored to the current repository with minimal integration assistance and upkeep requested of the CogE and/or developers.

See commit history in the slim_infusion branch for added files.