Mapping spec #54
Mapping spec #54
Conversation
Kantiran91
requested review from
karstenroethig,
ccvca,
GoetzGoerisch,
wlkrm and
mdornaus
GoetzGoerisch
force-pushed
the
develop
branch
2 times, most recently
from
976edd5 to
5d64fd8
Compare
Spec.md
Outdated
|
|
||
| A field can also contain properties but no other variables, even though the address space can contain more hierarchies. Properties of objects also cannot be mapped to the properties of a field. Therefore, a uniform mapping is used for objects and variables so that access is always consistent. | ||
|
|
||
| ## Mapping of References |
There was a problem hiding this comment.
I think including the TypeDefintion of the Objects and maybe even the nested VariableTypes (e.g. FiniteStateVariableType for CurrentState) the is also needed, as the Frontend has some conditional rendering logic based on TypeDefinitions. I suggest adding Fields with TypeDefintion for the ObjectNode of the DataSet. E.g.:
"Fields": [
{
"Name": "TypeDefinition",
"Description": {
"Locale": "",
"Text": ""
},
"FieldFlags": 0,
"BuiltInType": 0,
"DataType": {
"Id": 0
},
"ValueRank": 1926237584,
"ArrayDimensions": [],
"MaxStringLength": 0,
"DataSetFieldId": "57B13D4E-3F71-2A07-5AE5-1E9107E09EF9",
"Properties": []
},There was a problem hiding this comment.
I´m not sure. The TypeDeifnition is given in the MetaData. If it is part of the DataSet a lot of value which do not change will send in every message.
There was a problem hiding this comment.
I don't think it matters much, except that using the description may not be semantically straightforward.
Wouldn't we use Delta Frames if we were interested in low bandwidth anyway?
There was a problem hiding this comment.
Key and Delta Frames, should be followed.
There was a problem hiding this comment.
You're right, both solutions are not elegant as they misuse some concepts of the specification. I understand your point about mapping as a field, keeping the information in the same place, but with Delta Frames, this information is also missing, and a client would need a mapping logic.
The solution with the JSON description has the advantage of being extendable, and we also need to encode references somewhere.
There was a problem hiding this comment.
Where do you think using the field is violating the Spec?
We add MetaData (the TypeDefinition) to the DataSet
E.g, how to serialize the TypeDefintion (FiniteStateVariableType) of the CurrentState if it is part of the State's DataSet.
The CurrentState has a own Topic that describes the Type.
There was a problem hiding this comment.
Yes, but nothing in the spec forbids this, I guess, as arbitrary fields can be added.
Ah ok, then this should be updated:
The image shows a part of an address space. Each object is mapped to a DataSet:
Production
ActiveProgram
State
If CurrentState gets its own message, we break the semantics, that each ObjectNode (object?) gets its own DataSet?
What would be the semantics? There is always an own DataSet for nodes, if they are object nodes or if they are VariableTypes with properties? It they are VariableTypes with properties they get their own Topic, otherwise they are added to the parent?
I find the simpler mapping of ObjectType -> Own topic, VariableType -> no own topic more straightforward.
There was a problem hiding this comment.
The semantic idea was that a topic contains the childs. So the value of a Variable is in the DataSet of the Object an the childs are in the new Topic.
The question in a straightforward mapping is, how to handle that variable also can have childs and grandchilds?
There was a problem hiding this comment.
Yes, but nothing in the spec forbids this, I guess, as arbitrary fields can be added.
Yes also nothing forbids to use the description. Both solution are ugly in my point of view. The description solution try to map metadata to metadata and data to data.
There was a problem hiding this comment.
@wlkrm I try to describe both variants. Can you please check if I describe the Field solution correct?
If it is okay for you I would suggest to send this doc with both variants to the OPC Foundation and get their opinion.
|
How to derive the Topic-Path for specifictions like CNC, where Nodes have multiple BrowsePaths? |
|
@Kantiran91 could you please rebase onto of the latest develop? |
For multiple BrowsePath I add a field in the description. An other solution (also with some problems) to send the same message to different topics. Topic of Nodes without a BrowsePath are currently not described. For Event a solution to use the BrowsePath of the SourceNode as Topic. |
|
Additional Questions from @ccvca and me:
|
Than you have a lots of topic without a semantic and this make debugging an mapping more complex
With the TypeDefinition
Currently we also have not add this information. We can add a Field for that. |
Yes, our concern is, that using non-unique BorwsePaths isn't a good semantic as well. Is this problem solved by the current mapping?
See below. How to know, which level of inheritance is the one to include in the TypeDefinition?
Not sure if a field is enough, how would one know, which level in the hierarchy is the correct "Spec"-TypeDefinition. We had some issues with that in the past, because essentially you cannot know, which is the correct level in the hierarchy. Ideally we would expose the AddressSpace part of the Types as well to be prepared... |
The last solution is that we use the HierachicalReference to create an subtopic (I will change the spec tomorrow) and the BrowseName as TopicName with an Itteration if more as one fit. The unique identification should be done in the MetaData (Including NodeId and BrowsePath).
Yes I think we should give the complete inheritance tree in this field as Array. And as second field also the Implemented Interfaces. |
GoetzGoerisch
force-pushed
the
mapping_spec
branch
from
03741db to
bd40911
Compare
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
GoetzGoerisch
force-pushed
the
mapping_spec
branch
from
bd40911 to
c8cf689
Compare
|
@Kantiran91 how are the next steps here? |
GoetzGoerisch
force-pushed
the
develop
branch
5 times, most recently
from
3de6a7d to
f64289e
Compare
GoetzGoerisch
force-pushed
the
develop
branch
2 times, most recently
from
4f72173 to
3bb453d
Compare
Add the Spec for the umati Dashboard PubSub