View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006224 | UA Specification | Spec | public | 2020-11-09 09:53 | 2020-11-10 21:12 |
| Reporter | Liam Power | Assigned To | Jim Luth | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | duplicate | ||
| Summary | 0006224: Inconsistency in type definitions regarding BaseDataType | ||||
| Description | Part 3: Table 13 correctly states that, "All DataTypes are considered to be scalar, even if they have array-like semantics like ByteString and String." Most DataType definitions in the spec. denote a field that is an array, by stating it clearly in the type definition, for example the arrayDimensions field of Argument is of type UInt32[]. The DataValue definition in Part 4: Table 131 lists the value field as having type BaseDataType. This is surely not the full story as we know that the value field can also contain an array of BaseDataType. Of course we also know from Part 6 that the value attribute of a DataValue maps to a variant but we do not want to speak in terms of variants in Part 4. Part 6 says "Variables with a DataType of BaseDataType are mapped to a Variant, however, the ValueRank and ArrayDimensions Attributes place restrictions on what is allowed in the Variant. For example, if the ValueRank is Scalar then the Variant may only contain scalar values." This is clear but how do we capture in the Part 4 DataValue definition the fact that the rank of this field can vary? I don't think the current definition does that at all and should be revised. Is it implicit that whenever we see a field of BaseDataType in Part 4 the field can also contain an array? If so, are we conflating type and rank in the type system and is that the intention? If it is the intention that BaseDataType means any type and any rank then I think that should be very clearly stated in its definition in Part 3: 8.7. If not, then where that is the case elsewhere in the spec it should be clearly stated. As a further example, the inputArguments field of the Call service request is an array of BaseDataType. I would think it valid for any of these arguments to also be an array. The secureChannelId of a request header is of BaseDataType but surely it makes no sense for this to be an array or does it matter at all? In summary, BaseDataType is a scalar type in the type hierarchy but also conflates rank in certain circumstances and this needs to be more clearly defined for implementers. In my opinion from a type hierarchy perspective, type and rank are two completely different things. | ||||
| Tags | No tags attached. | ||||
| Commit Version | |||||
| Fix Due Date | |||||
| related to | 0004449 | closed | Jeff Harding | 10000-005: Information Model | Are arrays valid in the Value of a KeyValuePair Structure / Handling of arrays in BaseDataType |
| related to | 0004534 | closed | Jeff Harding | 10000-003: Address Space | Are arrays valid in the Value of a KeyValuePair Structure / Handling of arrays in BaseDataType |
|
|
This was already clarified in Part 3 - 8.7 BaseDataType with the following text based on 0004534 Additional text in OPC UA Part 3 - 1.05: |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-11-09 09:53 | Liam Power | New Issue | |
| 2020-11-10 07:16 | Matthias Damm | Relationship added | related to 0004449 |
| 2020-11-10 07:23 | Matthias Damm | Note Added: 0013132 | |
| 2020-11-10 07:23 | Matthias Damm | Relationship added | related to 0004534 |
| 2020-11-10 21:12 | Jim Luth | Assigned To | => Jim Luth |
| 2020-11-10 21:12 | Jim Luth | Status | new => closed |
| 2020-11-10 21:12 | Jim Luth | Resolution | open => duplicate |