View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000575810000-005: Information ModelSpecpublic2020-06-24 08:472020-07-14 16:23
ReporterBjarneBostrom Assigned ToWolfgang Mahnke  
PriorityhighSeverityminorReproducibilityN/A
Status closedResolutionwon't fix 
Summary0005758: 1.04 Amendment 13 RC 1.04.01 Comments
Description

The current proposal has several problems. Per the RC following is an example that could be seen in the address space:

OrderedListType (DataXXX is just a random BrowseName)
<-HasOrderedComponent-> DataX <-HasProperty-> NumberInList 0
<-HasOrderedComponent-> DataA <-HasProperty-> NumberInList 1
<-HasOrderedComponent-> DataK <-HasProperty-> NumberInList 2
<-HasOrderedComponent-> DataE <-HasProperty-> NumberInList 3

This has multiple problems, some of which are sort of explained, but I think it is a bit deeper than that.

  1. Starting with the type name. It has redundant term "Ordered". A List by it's very definition in a programming language means ordering, e.g. https://en.wikipedia.org/wiki/List_(abstract_data_type), thus just bare "ListType" might be a better name, as there is no way (that I'm aware) to have a non-ordered List (A Set would be different, see 1.)

  2. A List in typical programming languages allows you to have the same value/Object more than once inside it. This RC would not allow this due to the NumberInList Property only being capabable of mapping to a single index.

  3. And as explained in the RC, an Object cannot be part of more than one list (unless the same index).

  4. The Property NumberInList, the term "Index" is typically used instead.

  5. The proposal is not exactly "multi-service-call-safe" for client-side AddNodes (or Write) and AddReferences operations, since you need to both add the Reference and change the Property value. However before adding you can set the value and only after that make the AddReferences call. However changing a position is not possible, unless the server will generate the change event purely from the Write to the NumberInList of the 2 elements you wish to e.g. swap. Or the same steps done with additions can be reversed and the element re-added, though the list is in potentially invalid state until the operation is finished. Therefore it is unclear how the interaction between client and server side implementation should go here.

  6. Actually the defined RC proposal is a Map, not a List, since a List typically has an Index, however the RC does not have one, since "Ideally, the numbering should start with a 0 and have no gaps, but that is not required and Clients shall not assume this.". Therefore what is actually defined is a "sorted Map" from a Numeric type to a value (e.g. in java https://docs.oracle.com/javase/8/docs/api/java/util/SortedMap.html). It might be more beneficial to just define the type with name OrderedMapType or SortedMapType to more reflect the actual semantics and possibly allowing to use any DataType as the key. The resulted type would be more general use thus the need to have less types, which is usually always better.

See Additional Information section for some ideas, but note that they are not perfect

Steps To Reproduce

Amendment 13 RC comments, i.e. for opc-10001-13-ua-specification-rc-1.04.01-amendment-13-ordered-list.docx-20200409.zip

Additional Information

Idea 1:
OrderedListType (Instance 1)
<-HasOrderedComponent-> Element (Variable, Value 0) <-Organizes-> DataX
<-HasOrderedComponent-> Element (Variable, Value 1) <-Organizes-> DataA
<-HasOrderedComponent-> Element (Variable, Value 2) <-Organizes-> DataK
<-HasOrderedComponent-> Element (Variable, Value 3) <-Organizes-> DataE
<-HasProperty-> Size (Variable, Value 4)

OrderedListType (Instance 2, different order)
<-HasOrderedComponent-> Element (Variable, Value 0) <-Organizes-> DataE
<-HasOrderedComponent-> Element (Variable, Value 1) <-Organizes-> DataA
<-HasOrderedComponent-> Element (Variable, Value 2) <-Organizes-> DataK
<-HasOrderedComponent-> Element (Variable, Value 3) <-Organizes-> DataX
<-HasProperty-> Size (Variable, Value 4)

  • Would fix 1. as an object could be part of multiple list and more specifically they do not need to have any knowledge that they are part of one i.e. no data to be added to them.
  • However it is not as pretty as the RC as a client would first see the "Element" in a typical TreeView component.
  • Would allow to use potentially any key DataType if needed.

Idea 2:
OrderedListType
<-HasOrderedComponent-> DataX (In position/index: 0)
<-HasOrderedComponent-> DataA (In position/index: 1)
<-HasOrderedComponent-> DataK (In position/index: 2)
<-HasOrderedComponent-> DataE (In position/index: 3)
<-HasComponent-> GetIndex (Method, taking a NodeId as parameter, would return items position, but we need either a "null" value and/or separate boolean flag to indicate cases where the NodeId in question was no longer (or even originally) part of the list.

  • No way to monitor event as-is, though nothing would prevent making a new standard event type for this situation e.g. "ListOrderChangedEvent".
  • However no need for list elements to be knowledge that they are in a list, same as in Idea 1.
  • Need support from the server internals for the method so a pure AddNodes/AddReferences would not work.
  • Would not be suitable for a Map type as is (maybe for keys "set").

Idea 3:
Same as Idea 2, but adding methods AddElement and RemoveElement, which would link an existing node to the list (replacing would be remove+add calls). Would be multi-service-call safe, since the list change is a single Method call. However since the order of method calls within a single Call is not specified, maybe the AddElement should instead return a NodeId which way the previous mapping to the element.

Idea 4:
OrderedListType
<-HasComponent-> Elements (Variable, array of NodeIds defining the order of the elements)

The limit would be Int32 max value and would enforce proper indexing. Also not suitable for a Map as is (though there was the KeyValuePair Structure type). Also this needs data duplication + sync (array + individual values) or smart internals for the server implementation.

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Wolfgang Mahnke

2020-07-14 16:23

developer   ~0012607

Discussed in OPC UA WG Meeting (14th of July 2020)

In the meeting we disussed the different aspects of the issue and decided to close as a "won't fix"

With respect to the name "OrderedList": There was a general agreement that OderedList will be clearly understand by everybody. List / Set / Bag etc. might be not that clear. Especially, the OrderedList implies a semantics order, not just a structural, random order as might be implied by a list.
The "NumberInList" is preferable to "Index" as it is not an index, meaning there could be gaps in it. "Index" might become confusing with the index-handling of OPC UA arrays.

With respect to the first alternative idea: This usage of a proxy object is of course allowed and possible with the current approach. But we do not want to force people that they have to have a proxy object.

With respect to the other ideas: The OderedList is designed to provide information from a server. It does (intentionally) not define how a client would actively change the list. The best approach would be to use Methods (as also used in the alternative ideas). You can already extend methods to the approach, but we have no standardized methods for that. It was not in the requirements and would require some significant work on checking requirements and providing appropriate methods for it. By the way, that is true for many concepts like we have no standardized way for alarm configuration today.
In general, for the navigation / order number we see it easier to use the used concepts then having methods for it.

Issue History

Date Modified Username Field Change
2020-06-24 08:47 BjarneBostrom New Issue
2020-07-07 16:40 Jim Luth Assigned To => Wolfgang Mahnke
2020-07-07 16:40 Jim Luth Status new => assigned
2020-07-14 16:23 Wolfgang Mahnke Status assigned => closed
2020-07-14 16:23 Wolfgang Mahnke Resolution open => won't fix
2020-07-14 16:23 Wolfgang Mahnke Additional Information Updated
2020-07-14 16:23 Wolfgang Mahnke Note Added: 0012607