View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009234 | 10000-004: Services | Spec | public | 2023-11-03 16:43 | 2023-12-05 17:10 |
Reporter | David Levine | Assigned To | Matthias Damm | ||
Priority | normal | Severity | text | Reproducibility | sometimes |
Status | closed | Resolution | fixed | ||
Product Version | 1.05 | ||||
Target Version | 1.05.04 RC1 | Fixed in Version | 1.05.04 RC1 | ||
Summary | 0009234: RelativePath referenceTypeId needs clarification | ||||
Description | For the parameter referenceTypeId, the spec says in part: There are two issues and 1 question: We ran into a use case where the referenceTypeId on the wire was null (0), and the Server returned error "BadNoMatch" even though there was a Node at the specified BrowsePath. A NULL NodeId cannot be used in a server's address space, so using that as an argument to mean unspecified is counter intuitive. related: what happens if a NodeId is used that is not null or a referenceTypeId? Does this count as unspecified, or if this is an error, Is there an error code for this? The spec also says: "A text format for the RelativePath can be found in Clause A.2. This format is used in examples that explain the Services that make use of the RelativePath structure.". The BNF includes a mechanism for using a BrowseName for the reference type, so a client could specify "References", which is the root of all ReferenceTypes, both hierarchical and non-hierarchical, so why use "unspecified" at all? Is there a behavior difference between using "References" versus "unspecified" There are many kinds of subtypes - data, objects, variables, etc., and not all are located below the "Objects" folder. Regards | ||||
Tags | No tags attached. | ||||
Commit Version | 1.05.04 RC | ||||
Fix Due Date | 2024-01-15 | ||||
|
Not specified is logically null but to be more precise I replaced "not specified" with "the referenceTypeId is null" It is right that null is not part of the BNF. But there is a simple 'all hirarchical' |
|
Agreed to changes edited in virtual F2F. |
Date Modified | Username | Field | Change |
---|---|---|---|
2023-11-03 16:43 | David Levine | New Issue | |
2023-11-03 20:23 | David Levine | Description Updated | |
2023-11-03 20:25 | David Levine | Description Updated | |
2023-11-03 20:26 | David Levine | Description Updated | |
2023-11-03 20:36 | David Levine | Description Updated | |
2023-12-05 15:33 | Matthias Damm | Assigned To | => Matthias Damm |
2023-12-05 15:33 | Matthias Damm | Status | new => resolved |
2023-12-05 15:33 | Matthias Damm | Resolution | open => fixed |
2023-12-05 15:33 | Matthias Damm | Note Added: 0020487 | |
2023-12-05 17:02 | Jim Luth | Commit Version | => 1.05.04 RC |
2023-12-05 17:02 | Jim Luth | Fix Due Date | => 2024-01-15 |
2023-12-05 17:10 | Jim Luth | Status | resolved => closed |
2023-12-05 17:10 | Jim Luth | Fixed in Version | => 1.05.04 RC1 |
2023-12-05 17:10 | Jim Luth | Note Added: 0020492 |