View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003979 | 10000-003: Address Space | Spec | public | 2017-10-06 14:41 | 2021-09-27 17:48 |
Reporter | Jeff Harding | Assigned To | Jeff Harding | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Summary | 0003979: Optional Modeling Rule can cause broken behaviour of TranslateBrowsePathsToNodeId service when duplicated BrowseNames exists | ||||
Description | Two issues have been identified related to Optional modeling rules 1) The behavior of the TranslateBrowsePathsToNodeId server needs to be described for the case when a Type with an optional Node is instantiated and that instance reuses the name of the optional Node for an instance defined Node. In this case if the Optional node is omitted from the instance then the TranslateBrowsePathsToNodeId will return the instance Node's NodeId only. The programming against type concept would normally expect either the NodeId of the type's Node if it is present in the instance or no NodeIds if is not present. In this use case however either 1 or 2 NodeIds will be returned (i.e. optional Node is or isn't present). A client would incorrectly use the NodeId of the Instance defined Node assuming it is the Type defined Node when the optional Node is not present in the instance. A solution would be to return a Null NodeId as a placeholder for Optional, not present, Nodes from the Type. In this way a client implicitly knows if the optional Node is present as it will always be the 1st element of the array returned by the service. 2) Clarification is needed to state that a subtype can not reuse the BrowseName of an Optional Node of any of its parents. | ||||
Tags | No tags attached. | ||||
Commit Version | |||||
Fix Due Date | |||||
related to | 0006999 | assigned | Jeff Harding | Propagation of Optional ModellingRules when creating InstanceDeclarations |
|
After discussion during a weekly call we concluded that while in theory this is a problem developers can avoid this type of problem. For example a client should not simple assume the single returned NodeId in the TranslateBrowsePathsToNodeId response is the optional Node without further investigation of the Node (is it the expected VariableType, etc). It was agreed the second issue "Clarification is needed to state that a subtype can not reuse the BrowseName of an Optional Node of any of its parents" should be incorporated into Part 3. |
|
Agreed to move this issue to Part 4 and clarify how Clients need to protect themselves by checking the type when they call TranslateBrowsePathToNodeIds. |
|
5.8.4 TranslateBrowsePathsToNodeIds Added following clarification: Updated in OPC 10000-4 - UA Specification Part 4 - Services 1.05.0 Draft11.docx |
|
We need to define in Part 3 that it is not allowed to add component to an instance, it can not the same browse name as an optional component defined by the type if the optional component is not there. |
|
Added the following statement to 6.4.4.4.2 Optional: |
|
After a long discussion we concluded that we need to fix the root cause of this issue rather than continue to define specific cases. A general statement that defines "No instance can declare a target of a hierarchical reference that has the same BrowsePath as an InstanceDeclaration of its TypeDefinintion which has an optional or mandatory modelling rule." This should be added to 6.4.2. Need to clone to Part 4 after we agree on the updated text. |
|
Added the general statement about instance defined Components in 6.4.2 Creating an Instance. |
|
Needs 1.04 Errata to close. |
|
Agreed to 1.04 Errata in Telecon. |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-10-06 14:41 | Jeff Harding | New Issue | |
2017-10-06 14:41 | Jeff Harding | Status | new => assigned |
2017-10-06 14:41 | Jeff Harding | Assigned To | => Jeff Harding |
2017-11-07 21:20 | Jeff Harding | Note Added: 0008655 | |
2017-11-21 16:29 | Jim Luth | Assigned To | Jeff Harding => Matthias Damm |
2017-11-21 16:31 | Jim Luth | Note Added: 0008726 | |
2017-11-21 16:31 | Jim Luth | Project | 10000-003: Address Space => 10000-004: Services |
2020-09-16 20:21 | Matthias Damm | Status | assigned => resolved |
2020-09-16 20:22 | Matthias Damm | Resolution | open => fixed |
2020-09-16 20:22 | Matthias Damm | Note Added: 0012888 | |
2020-09-17 15:41 | Matthias Damm | Assigned To | Matthias Damm => Jeff Harding |
2020-09-17 15:41 | Matthias Damm | Status | resolved => feedback |
2020-09-17 15:41 | Matthias Damm | Resolution | fixed => reopened |
2020-09-17 15:41 | Matthias Damm | Note Added: 0012920 | |
2020-09-17 15:42 | Jim Luth | Project | 10000-004: Services => 10000-003: Address Space |
2020-09-17 15:43 | Jim Luth | Status | feedback => assigned |
2021-02-24 20:42 | Jeff Harding | Status | assigned => resolved |
2021-02-24 20:42 | Jeff Harding | Resolution | reopened => fixed |
2021-02-24 20:42 | Jeff Harding | Fixed in Version | => 1.05 |
2021-02-24 20:42 | Jeff Harding | Note Added: 0013809 | |
2021-03-01 16:22 | Jeff Harding | Status | resolved => feedback |
2021-03-01 16:22 | Jeff Harding | Resolution | fixed => reopened |
2021-03-01 16:36 | Jeff Harding | Status | feedback => acknowledged |
2021-03-01 16:36 | Jeff Harding | Note Added: 0013846 | |
2021-03-04 19:33 | Jeff Harding | Status | acknowledged => resolved |
2021-03-04 19:33 | Jeff Harding | Resolution | reopened => fixed |
2021-03-04 19:33 | Jeff Harding | Note Added: 0013979 | |
2021-03-05 14:36 | Jim Luth | Note Added: 0013994 | |
2021-03-09 17:15 | Jim Luth | Status | resolved => closed |
2021-03-09 17:15 | Jim Luth | Note Added: 0014014 | |
2021-09-27 17:48 | Jeff Harding | Relationship added | related to 0006999 |