Update format of component ids

[emiltin]

Based on discussion in https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/issues/187, we should update the definition of how component ids must be structured.

We should remove reference to STA (Swedish Transport Administration).

Messages like S0002 uses string like "0001000" to indicate the value of all component of a particular type. This depend on mapping character positions to components in an unambiguous way. E.g. the 1 at position 4 refers to a component KK+AG0506=000DL004 (which has 4 at the end).

We've specified component id in the definitions section

The format used for the STA’s sites is specified in the STA publication TDOK 2012:1171, e.g. AA+BBCDD=EEEFFGGG. According to the publication, the GGG part is consecutive numbering.

To ensure mapping is possible, a simple option is to reuse the STA format:

• AA+BBCDD=EEEFFGGG, with GGG being a consecutive number starting from 1.

But in general I think it's suboptimal to include the site name in the component id. It causes a lot of extra bytes to be send when you refer to components. Since messages are send to a particular site, we could just use "type/integer" as component ids:

DL/1 DL/2 DL/3

For S0002 the component type "DL" would be implied. So character position 4 refers to "DL/4". In a similar way S0001 would imply the component type "SG", etc. Other messages that imply a particular component type could similarly use just the integer id.

BTW, these short component paths are essentially the current idea for RSMP 4.

[marcgarba]

Yes, using a generic/entier type is a format that could be more universal. (That's exactly the object type format we're planning to use !). We've also defined "/" for the "root" device (instead of an empty string, preferably).

We've also defined a possible "shortcut", e.g. "DL/" in this type of example, when we want to access all the object types defined (to quickly subscribe to a signal for all these type of objects).

A useful object type for us is "CA" for a logical intersection ('carrefour' in french...).

So much for our thoughts on this subject...

[emiltin]

Thank you for the input. It's quite similar to our thoughts regading RSMP 4 (which is so far a research topic), you have have a look here if you're interested: https://github.com/rsmp-nordic/rsmp_core_v4/discussions/6

It's also similar to file paths, urls, etc, so hardly anything new as such.

[emiltin]

It would be good to be able to fetch the mapping betweeen object indexes and names, e.g. between signal groups indexes and their names: 1: A1 2: A2 3: B1 ...

[emiltin]

We might want to split out the isse of removing reference to STA (Swedish Transport Administration).

[emiltin]

JSON requires UTF-8. Should we have requirements regarding which characters can be used. e.g. for component ids? For example, are control characters allowed? https://en.wikipedia.org/wiki/List_of_Unicode_characters. Non-latin, e.g. japanese ひほわれよう? Symbols and emojis like ☀☁☔🚀?

[emiltin]

The PR #178 proposed to remove any reference to STA, and also removes requirements on the form of component ids.

What's missing is how to deal with SXL messages like TLC S0021 https://rsmp-nordic.github.io/rsmp_sxl_traffic_lights/1.2.1/sxl_traffic_light_controller.html#s0021, which uses a string to encode status for multiple components, relying on an implicit ordering. I plan to deal with this in the TLC SXL.

[emiltin]

Proposal for updated description of S0023: https://github.com/rsmp-nordic/rsmp_schema/pull/114 I guess this would be repeated in other statuses/commands, so perhaps we should have a general section about this?

[emiltin]

Current RSMP 3 component format: AA+BBCDD=EEEFFGGG # FF=type, GGG=index KK+AG0506=000DL004 # example, DL=detector logic, 004 = index

The format AA+BBCDD=EEEFFGGG does not work for France because:

• Don't want to repeat the site id part (AA+BBCDD=) in component ids.

In France, the current proposal is to use component names like this: DL/ # all detector logics DL/0 DL/1

CA/ # all intersections (carrefour) CA/0 CA/1 CA/2

GR/1/CA/0 # group 1, intersection 0

We could define a new format that starts with a certain symbol, like slash or dot. That would make it easy to identify the type of component id:

.CA.1 .DL.1 # detector logic 1 . # shortcut to the main component

Current supervisors often show just the component id, which include the site id: KK+AG0506=000DL005 KK+AG0506=000DL006

If we allow short component ids, it might be shown without the site id, so there would be some changes required to the UI: .DL.1 (site: KK+AG0506=) .DL.2 .DL.3

How to make indexes in status strings like "1011" unambiguos? 1: KK+AG0506=000DL001 2: KK+AG0506=000DL003 # 2 or 3´? 3: KK+AG0506=000DL004

For example, given these components: DL/ DL/BUS01 DL/CAR02

Should S0001 be send as "111" or "1-11"?

[marcgarba]

Concerning the last remark of making a possible link between component name and data content for index. There should be no possible link ! Either index present in the component name, or provide a list in the string data with ALL elements each time.

Typical use for a boolean value 0/1, with 12 detectors of index 0/1/2/3/6:7/8/10/11 defined: ObjectName "DL/" => stringValues:"0011--010-10" (char index = detector index ; '-' if not defined ; string length to last defined) ObjetName "DL/2" => boolValue: true

For some signals on root equipment for component, a signal could also provide all the informations in one string (example with physical inputs).

[emiltin]

Related issue opened by Lightmotion https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/issues/192

[emiltin]

Proposed defining two formats, original and new, in https://github.com/rsmp-nordic/rsmp_core/pull/178/files

[marcgarba]

Regarding the problematic of allowing the choice of whether a subpart is in the same index range or not, in addition to the separator character “/”, we could introduce also the separator “~”, which would mean that in this case, the index for this sub-section should not be reset.

Example with the pull request proposal 178 for detector logics can be organized into radars and video detectors :

choice 1: independent index for each sub category

    /dl/radar/1
    /dl/radar/2
    /dl/video/1
    /dl/video/2

choice 2 : shared index for all sub categories

    /dl~radar/1
    /dl~radar/2
    /dl~video/3
    /dl~video/4
    (here we consider "dl~xxxxxxx" at the same level)

With both, in a tree for a user graphical interface, we would retreive the same tree structure

    "dl" +-> "radar"
         |-> "video"

[emiltin]

I prefer not to introduce additional separators:

• it increases complexity
• it does not fit well with RSMP 4 MQTT topic paths, where "/" is used to separate parts that you can filter on with wildcards

[emiltin]

The device must maintain a index for each component, that's unique per component type. How they are organized in sub trees matter less, as long as you can retrieve the mapping, organized by component id and index:

{
  "dl": {
    "1": "/dl/radar/1",
    "2": "/dl/radar/2",
    "3": "/dl/video/1",
    "4": "/dl/video/2"
  } 

[emiltin]

We could also choose to make indexes local to the status message, and simply not deal with them in the core spec.

For example, when you subscribe to S0001, there could be an attribute called indexes, that would provide the mapping, much as shown above, but since S0001 deal only with signal groups, we would not need to map by component type, so it's just an integer to id mapping:

{
    "1": "/dl/radar/1",
    "2": "/dl/radar/2",
    "3": "/dl/video/1",
    "4": "/dl/video/2"
  } 

Or using an array

[
    "/dl/radar/1",
    "/dl/radar/2",
    "/dl/video/1",
    "/dl/video/2"
]

You would only get this mapping once, and in case it changes later.

With this approach, we don't have to descibe/require indexing as part of the core spec. Instead it's just something related to a specific status mesages in an SXL.

• simpler core with no component indexes, just ids
• messages like S0001 becomes a bit more complex and require new 'indexes' attribute
• possible duplication between message that use similar indexes