ntsOId and xNId

[emiltin]

Messages include the fields ntsOId and xNId. They seem to refer to a Swedish national system of ids? From https://github.com/rsmp-nordic/rsmp_core/blob/master/rst/rsmp.rst:

• ntsOId | NTSObjectId | Component id for the NTS object which the message is referring to.
• xNId | externalNtsId | Identity for the NTS object in communcation between NTS and other systems. The format is 5 integers. Defined in cooperation with representatives from NTS. Unique for the site.

To ensure RSMP is useful as a regional/international standard, it would be best to avoid attributes that are particular to Sweden or any other single country.

[otterdahl]

I agree. Originally it seemed like a good idea to have these in the protocol, but they never got the used the way that it was originally intended. However, there need to be some discussions with other technical areas (beyond traffic signal)s to make sure that no one else is using them.

[emiltin]

We depreciate these two fields. Will be removed in a later release (not 3.1.5)

[otterdahl]

The relation between ntsOId and componendId is used to logically group grouped objects and single objects together. For instance, traffic signals has Traffic controller as a grouped object with each associated signal group and detector logic as single objects.

This needs to be resolved before removing these fields

[emiltin]

I don't understand the relation between ntsOId and componendId, that you mentioned above.

[otterdahl]

On second thought, they might not be needed after all.

The relation between which component (e.g. signal group) that belongs to which main object (e.g. Traffic controller) isn't really important from the protocol point of view.

The reason for my hesitation is due to the fact that RSMP supports multiple main components in the same SXL (and optionally multiple site-id). We don't use multiple main components in the SXL for Traffic signals, but it is used in other SXL's, such as congestion tax or intelligent street lighting.

That means that it is technically possible to send alarms, commands and statuses for several traffic controllers in the same RSMP connection. This is needed in order to support infrastructure-to-infrastructure (I2I)

[emiltin]

So can the ntsOId and xNId attributes be deprecated from 3.1.6 or is this still pending further investigations?

[otterdahl]

Pending further investigation. I'm inviting people responsible for VMS-signs in upcoming working group meetings to discuss this.

[emiltin]

ok

[emiltin]

There has been some recent discussion in https://github.com/rsmp-nordic/rsmp_validator/issues/59.

Reading core spec, the ntsOId and xNId are described under Basic Message Structure, under 'variable content': https://rsmp-nordic.org/rsmp_specifications/core/3.1.5/applicability/basic_structure.html#basic-structure

It states that the content is defined in the SXL. What does that mean? Looking in the SXL for TCL's I see no explanation of these two fields.

Another question is related to whether these fields are optional or required. It seems TLCs expect xNId to be an empty string "" and returns errors if null is used, or the attribute is left out. Most (all?) json examples also use the empty string "" for the nXId attribute. If we can clarify this we could also update our JSON schema. Currently the scheme does required neither ntsOId nor xNId.

Back in 2020 we wrote that depreciating the ntsOId and xNId attributes was pending further investigation. Is there news on this, or is it something we should pick up again?

In any case I think it would be nice to expand the explanation about the fields in the core spec. These fields have confused me quite a bit.

[emiltin]

since this is a breaking change (though a smaller one) we will push this to 4.0