Hello,
as of Spec 1.04 Part 4 Page 72 it says:
HistoryReadValueId: „… … . This structure is defined in-line with the following indented items.”
So a HistoryReadValueId should contain the Types NodeId, NumericRange, QualifiedName, ContinuationPoint.
As of Spec 1.03 Part 4 Page 68 it is defined as containing the Types NodeId, NumericRange, QualifiedName, ByteString.
ð
ContinuationPoint will not be added before Milo 2.0.
As of HistoryReadValueId.java it contains the Types NodeId, String, QualifiedName, ByteString
ð
Question 1: Shouldn’t be the String a NumericRange by this day?
Instead the String indexRange is passed, until somebody calls the static NumericRange.parse(indexRange)-method.
For instance in SubscriptionManager.java Line 479 – 481 it says:
479 - // Validate the requested index range by parsing it.
480 - String indexRange = request.getItemToMonitor().getIndexRange();
481 -
if (indexRange !=
null)
NumericRange.parse(indexRange);
But the result of the parse-method is never saved and the indexRange is never used again. So we actually check, if the indexRange has the right syntax and we would
get a UaException(StatusCodes.Bad_IndexRangeInvalid) if not okay.
Question 2: But we never use the indexRange?
Question 3: Why is NumericRange stored in
org.eclipse.milo.opcua.sdk.core rather than putting it in
org.eclipse.milo.opcua.stack.core.types.builtin ?
Question 4: Why do we check the syntax of the indexRange so late? Why don’t we check it on creation?
I tried to “fix” HistoryReadValueId by typing NumericRange instead of String, but HistoryReadValueId can’t find the import.
Thanks - Michael