View Issue Details

IDProjectCategoryView StatusLast Update
000906210000-014: PubSubSpecpublic2024-01-16 16:17
ReporterThilo Bellinger Assigned ToMatthias Damm  
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionopen 
Product Version1.05.02 
Summary0009062: Clarify mandatory ID configurations from JsonDataSetMessageContentMask
Description
  • A JSON DataSetMessage can optionally send a DataSetWriterId and a DataSetWriterName (maybe both, maybe one, maybe none).
  • A subscriber needs some kind of identification to map a DataSetMessage to a DataSetReader / SubscribedDataSet.

Receiving different DataSetMessages from the same PublisherId on the same channel / DataSetReader without any identifier can practically not be used.
A subscriber would have to try to identify the DataSetMessages by comparing the ambiguous JSON contents.

It is nowhere described which setting combinations are expected to be valid or invalid, thus implementers have to guess (and may guess in different ways).
My intention is to prevent an SDK user or application configurator from accidentially setting not usable configurations while I also want to make sure to accept the intended valid use cases.

My assumptions are:

  • DataSetWriterId and DataSetWriterName can be treated equally. (Or is the DataSetWriterName just some display text but no identifier?)
    • The WriterId seems to be the "OPC UA" identifier where the WriterName might be intended for the non OPC UA subscribers on MQTT (e.g. for the non-reversible representation).
    • Subscribers may not support both identifiers but should support at least one. (Or should all subscribers be able to use both?)
  • I guess normally either the DataSetWriterId or the DataSetWriterName (or both) should be provided but there might be several exceptions where using none might be a valid use case.

I guess any scenario where only DataSetMessages of the same layout arrive on the same channel could be valid.

  • Is this interpretation correct?
  • Does this apply only for using JsonNetworkMessageContentMask_SingleDataSetMessage or is it OK to also have multiple DataSetMessages per NetworkMessage (where all have the same layout)?
  • Is it OK that multiple writers (with same layout) of the same publisher write into the same queue? (A subscriber has no way to distinguish, as the PublisherId is the same)

Note: In theory it could work that all DataSetMessages except one have an identify, thus the writer could be identified by excluding the others. In my opinion that would be an invalid configuration.

As it might be tedious to describe the valid cases, please clarify and specify the configurations which should be treated as invalid.
Also please describe the purpose of sending a DataSetWriterName (Is it a display text or an alternate identifier?)

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Jim Luth

2024-01-02 16:53

administrator   ~0020553

Please review this request in reference to the updated 1.05.03 version of Part 14.

Thilo Bellinger

2024-01-08 14:29

reporter   ~0020588

1.05.03 clarifies some of the questions but not all:
Solved:

  • There are intended configurations which have neither the IDs nor the names (see Header Layouts for JSON in Annex A)
  • (1.05.03 is now able to send the WriterGroupName)

Still Open:

  • The purpose of the name fields (WriterName and WriterGroupName) are still unclear.
    Are they intended to be used as filters, similar to the ID filters (WriterId and WriterGroupId)?
    If yes, where would a generic reader configure those filters? (Or is it intended for cloud applications only?)
    What is the benefit compared to the ID filters?
  • "I guess any scenario where only DataSetMessages of the same layout arrive on the same channel could be valid."
    This sentence was a bit difficult to understand or to clarify. Lets rephrase it to
    "There can be valid use cases where one Reader processes DataSetMessages from multiple writers even when no filter fields are sent" (but those cases are extremely unlikely).
    Correct?

Jim Luth

2024-01-16 16:17

administrator   ~0020634

We agreed that the names in the header can be used for filtering by a subscriber, but there is no way to configure the subscriber to use the names as a filter in the standard configuration interface -- this should be clarified in Part 14.

Issue History

Date Modified Username Field Change
2023-07-28 17:46 Thilo Bellinger New Issue
2024-01-02 16:53 Jim Luth Status new => feedback
2024-01-02 16:53 Jim Luth Note Added: 0020553
2024-01-08 14:29 Thilo Bellinger Note Added: 0020588
2024-01-08 14:29 Thilo Bellinger Status feedback => new
2024-01-16 16:17 Jim Luth Note Added: 0020634
2024-01-16 16:17 Jim Luth Assigned To => Matthias Damm
2024-01-16 16:17 Jim Luth Status new => assigned