move files to core/sxl repos

[emiltin]

If we like the json schema approach, then i think it would be better to move the schema files into the core and TLC sxl repos, so they are maintained in step with the other documentation. Thoughts, @otterdahl?

[emiltin]

That would include the cucumber tests

[otterdahl]

It is generally a good idea. My only thought is that there might be a slight risk that one might forget to update the schema while updating core/sxl, thus render the repo in an inconsistent state temporarily. But perhaps the risk is low

[emiltin]

Maybe I misunderstand you, but my suggestion is to remove this rsmp_schema repo, and instead maintain the schema files as part of the core/sxl repos. That way we don't have two separate repos we have to keep in sync.

[otterdahl]

I think that is OK. We can start thinking on how add the json schema and the yaml sxl file to the core/sxl repos.

[emiltin]

The json schema file should not be moved. We still needs this repo as a stand-alone repo you can include when you need to do automatic validation of rsmp json messages. It's impractical to have to include the entire sxl repo which includes all the documentation. Either this repo should pull the yaml files from the sxl repo, or perhaps better the yaml should be moved to a separte repo?

[otterdahl]

I'm not sure what the pros and cons are with each option. From my perspective it would make sense to include the yaml in the sxl repo since the sxl and yaml are closely related together and represents the same type of data - but I can understand your argument about it being impractical when converting to json schema.

[emiltin]

Do we have a authoritative YAML file (converted from Excel) yet, and where is it currently stored?

[otterdahl]

It is not stored anywhere yet. However, the Excel SXL is located in the release for the SXL.

I've created a gist for the yaml. The first one contains everything we've discussed earlier.

The extended yaml is needed for compatibility with Excel format and the RSMP simulator. It is possible the convert the extended format back to excel and retain 100% of the information. You can read about it here

• SXL yaml
• SXL extended yaml

[emiltin]

OK. I see a 'sites:' section at the bottom. This is not part of the SXL spec, but specific to a particular installation? I think that should be moved out from the SXL yaml. After that, I think we should pick the extended version as our new authoritative source and commit it to the sxl repo, and update by hand from then on, as well as create a convert to JSON Schema.

[otterdahl]

OK. I see a 'sites:' section at the bottom. This is not part of the SXL spec, but specific to a particular installation? I think that should be moved out from the SXL yaml.

It is possible to remove the 'sites:' section for traffic signals, but I think it might cause compatibility issues for other types of SXL, where more than one "main object" may exist. The sites section defines the relationship between "single objects" and "group objects", e.g. which signal groups belongs with which TLC. (signal group: ntsObjectId is equal to traffic light controller: componentId) It is possible in a single RSMP connection to contain communication for several TLC's. It is used in some cases, e.g. congestion tax SXL.

[emiltin]

But isn't the content of the sites section specific to a particular installation? I think the yaml file should only contain what is general for the type of equipment it describes. Or do I misunderstand the content of the sites section? It starts like this:

sites:
  AA+BBCC:
    description: Anl. ??
    objects:
      Traffic Light Controller:
        Traffic Light Controller:
          componentId: AA+BBCCC=DDDEEFFF
          ntsObjectId: AA+BBCCC=DDDEEFFF
      Signal group:
        SG1:
          componentId: AA+BBCCC=DDDEEFF1
          ntsObjectId: AA+BBCCC=DDDEEFFF

What is the meaing of this?

[otterdahl]

But isn't the content of the sites section specific to a particular installation?

Yes it is. It's specific for a particular installation, since it defines descriptions, componentId as so forth. But at the same time it also describes the relationship between objects.

I think the yaml file should only contain what is general for the type of equipment it describes.

Yeah, I understand your argument. This dual purpose makes it a bit tricky. As said earlier, it is possible to drop the sites section, but at a cost which are outlined in my previous post.

[emiltin]

If the relationsship between objects is the same for all installations, I think we should include it in this sxl yaml. It it's particular to each installation, I suggest we create a separate format for that info which can be used when documenting installations.

[emiltin]

It would be good to move ahead on a reorganization of the repos, and get a first version of the yaml for TLCs committed.

Suggsted repos. Core and tlc is split into separte repos, because we need to start versioning them separately, so you can validate with a specific core and sxl version:

rsmp_schema_core json schema for validating core parts of rsmp messages. maintained by hand, or by generating json from ruby to get formatting and indentation consistent

rsmp_schema_tlc json schema for validating TLC sxl messages. generated by converting the TLC yaml to json schema using our converter.

rsmp_schema an umbrella repo, which includes the core, tlc (and later vms, etc) schema repos as submodules (or subtrees), so you have everything needed to validate rsmp message. a sxl schema repo can be included multiple times for different versions (e.g tcl sxl 1.0.7, 1.0.8, 1.013, 1.0.14, 1.0.15), so that you can validate messages according to different sxl/core versions.

rsmp_sxl_tlc documentation of the TLC sxl. includes the yaml file, and various documentation.

rsmp_converters tools for converting between various rsmp formats. eg. yaml to excel, and yaml to json schema

[emiltin]

Instead of splitting the rsmp_schema repo into core and sxl repos, we can maintain core and tlc branches. The umbrella repo can then check our these branches multiple times for different versions.

However, this will make versioning a bit harder, since core and sxl are versioned separately

[emiltin]

For now I'm trying to keep the rsmp_schema repo for both core and tlc, and using branches. For starters, there's a core and a tlc branch, pruned to contain only what's relevant. Later we can add branches for the various versions, e.g tlc_1.0.7, tlc_1.0.13, etc. and similar for core.

I added a new repo called rsmp_schemer, https://github.com/rsmp-nordic/rsmp_schemer, which includes these branches as submodules. You can then validate against core and tlc separately.