View Issue Details

IDProjectCategoryView StatusLast Update
000021310000-003: Address Spacepublic2007-10-26 03:52
ReporterWolfgang Mahnke Assigned ToWolfgang Mahnke  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Summary0000213: Change ArraySize to ValueRank
Description

These changes are necessary to add support for multi-dimensional arrays to the information model.

Attribute ValueRank (Int32): specifies whether the Value is an array and how many dimensions that it has.

It may have the following values:

n>1: the Value is an array with the specified number of dimensions.
OneDimension (1): The value is an array with one dimension.
OneOrMoreDimensions (0): The value is an array with one or more dimensions.
Scalar (-1): The value is not an array.
Any (-2): The value can be a scalar or an array with any number of dimensions.
ScalarOrOneDimension (-3): The value can be a scalar or a one dimensional array.

ArrayDimensions (Int32[]): specifies the length of each dimension for an array value.

ArrayDimensions attribute is optional.

The number of elements must be equal to the value of the ArrayRank attribute. Must be null if ArrayRank <= 0.

A value of 0 for an individual dimension indicates that the dimension has a variable length.

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0000215 closedWolfgang Mahnke 10000-005: Information Model Change ArraySize to ValueRank 

Activities

Wolfgang Mahnke

2007-10-04 15:12

developer   ~0000366

fixed in version 1.01.06

Wolfgang Mahnke

2007-10-09 17:51

developer   ~0000379

Should ArrayDimensions be an Array or Property?

Is there a reason to make it a property?

How much code do you have to change?

For telco 2007-10-09 an attribute seems suitable.

Randy Armstrong

2007-10-13 22:13

administrator   ~0000381

From an information model perspective there is no difference between Attributes and Properties: both define a Facet that describes a node. However, UA introduced the concept of Attributes because it was felt that application developers would benefit if some Facets had a more efficient access mechanism. The Attributes that exist today fall into three groups:

1) Facets which are intrinsic to the definition of the NodeClass (i.e. the NodeClass would not make sense if these Facets did not exist). NodeId, NodeClass, BrowseName, DisplayName and Value are examples of intrinsic Facets.

2) Facets which are accessed frequently by almost every application and would benefit from an optimized access mechanism. AccessLevel, DataType and EventNotifier are examples of frequently used Facets.

3) Facets which are absolutely required to describe Property Nodes since Properties cannot have Properties (a restriction which allows developers to better optimize their implementations of Properties). MinimumSamplingInterval and Historizing are examples of Property qualifying facets.

In other words, Attributes are a mechanism to facilitate optimization. For this reason, the set of Attributes must be small and not extensible. Developers are expected to take advantage of this fact when they write their applications. This also means that the overhead associated with supporting new attributes will likely be much larger because developers may hardcode support for the known Attributes into their applications instead of relying on dynamic lists which provide flexibility at the cost of performance.

For this reason, we must consider whether the Attribute meets the criteria above when we look at a proposed attribute such as ArrayDimensions.

In this case, the ArrayDimensions attribute is not intrinsic to the node nor is it used frequently by many applications because many servers will not be able to provide a value for it. The ArrayDimensions is also not required for Properties since it is optional and a server can always use a DataVariable instead of a Property. In fact we have already decided that servers must use DataVariables when exposing information such as EURange, EUInformation or EnumStrings even though we know those values will be used much more frequently than the ArrayDimensions value. For that reason, I feel that ArrayDimensions should be a Property instead of an Attribute.

That said, ArrayDimensions could be a legimate attribute if there are additional use cases that demonstrate why this value is important enough to justify the additional overhead that will need to be written into applications to support the attribute.

user2

2007-10-26 03:52

  ~0000415

Agreed to leave ArrayDimensions as an attribute in today's telecon.

Issue History

Date Modified Username Field Change
2007-10-04 14:31 Wolfgang Mahnke New Issue
2007-10-04 14:33 Wolfgang Mahnke Status new => assigned
2007-10-04 14:33 Wolfgang Mahnke Assigned To => Wolfgang Mahnke
2007-10-04 15:12 Wolfgang Mahnke Relationship added related to 0000215
2007-10-04 15:12 Wolfgang Mahnke Status assigned => resolved
2007-10-04 15:12 Wolfgang Mahnke Resolution open => fixed
2007-10-04 15:12 Wolfgang Mahnke Note Added: 0000366
2007-10-09 17:51 Wolfgang Mahnke Assigned To Wolfgang Mahnke => Randy Armstrong
2007-10-09 17:51 Wolfgang Mahnke Status resolved => feedback
2007-10-09 17:51 Wolfgang Mahnke Resolution fixed => reopened
2007-10-09 17:51 Wolfgang Mahnke Note Added: 0000379
2007-10-13 22:13 Randy Armstrong Note Added: 0000381
2007-10-13 22:13 Randy Armstrong Status feedback => assigned
2007-10-13 22:13 Randy Armstrong Assigned To Randy Armstrong => Wolfgang Mahnke
2007-10-26 03:52 user2 Status assigned => closed
2007-10-26 03:52 user2 Note Added: 0000415
2007-10-26 03:52 user2 Resolution reopened => fixed