opcua: nsu in nodeId (fixing #1334)

[erossignon]

No description provided.

[sebastiankb]

@erossignon many thanks!

beside of the "ns=..." nodeId, TD needs also to allow "nsu=..." as node ID. Still we need to clearify, if the nodeID can be part of the href or is dedicated ua:nodeId term is needed.

[danielpeintner]

The idea is that we use href instead of the own term opcua:nodeId (we use href in other bindings too).

For example, we now have

{
    "base": "opc.tcp://192.168.120.237:4840/",
    "properties": {
        "foo": {
            "forms": [
                {
                    "opcua:nodeId": "nsu=http://example.org/SpecialNamespace/;s=\"LED\".\"State\""
                }
            ]
        }
    }
}

which would become the following

{
    "base": "opc.tcp://192.168.120.237:4840/",
    "properties": {
        "foo": {
            "forms": [
                {
                    "href": "nsu=http://example.org/SpecialNamespace/;s=\"LED\".\"State\""
                }
            ]
        }
    }
}

The problem I see are href parsers since the absolute URL would become the following

opc.tcp://192.168.120.237:4840/nsu=http://example.org/SpecialNamespace/;s=\"LED\".\"State\"

A more Web style friendly format would be to use query parameters

opc.tcp://192.168.120.237:4840/?nsu=http://example.org/SpecialNamespace/&s=\"LED\".\"State\"

Note1: the difference is the ? after the host part and that arguments get concatenated via & and not ;

Note2: it has the downside that one needs to reconstruct the format string at OPC UA side.

Question: I wonder whether people share the concern that if we purely use the OPC UA format string href parsers will destroy/corrupt the information.

Note3: we also need to be careful with some specific characters like # that get interpreted as fragment identifier. That could be the case in the nsu part. Try to parse the following string
opc.tcp://192.168.120.237/nsu=http://example.org/#foo;s=SpecialVar
on https://www.freeformatter.com/url-parser-query-string-splitter.html

[erossignon]

May be one way is to encode the href portion using encodeUriComponent decodeUriComponent

encodeURIComponent("opc.tcp://192.168.120.237:4840/nsu=http://example.org/SpecialNamespace/;s=\"LED\".\"State\"")


'opc.tcp%3A%2F%2F192.168.120.237%3A4840%2Fnsu%3Dhttp%3A%2F%2Fexample.org%2FSpecialNamespace%2F%3Bs%3D%22LED%22.%22State%22'
)

to prevent any clashes

[egekorkan]

Going with URL encoding was also the preliminary decision taken for MQTT at w3c/wot-binding-templates#292 (comment)

[danielpeintner]

Going with URL encoding was also the preliminary decision taken for MQTT at w3c/wot-binding-templates#292 (comment)

The problem I see with doing so is that for humans, it is not easy to read the "encoded" string.
(Not sure if this is an actual problem)

Anyhow, It seems we need a general decision that can be taken across all/other bindings...

[egekorkan]

We had a chat about this together with @sebastiankb @danielpeintner @wiresio and @Kaz040. Here our points, that need to be discussed with the OPC UA community as well.

• The TDs should be still human-readable: Encoding the entire URI breaks this. This can turn off the ones who are used to OPC UA.
• It should be easy to copy-paste node ids from a tool like UA Expert to TDs
• We have evaluated some aspects:
  • Using single quotes inside the double quotes: It is valid JSON, but the UA server can still have double quotes that need to be converted when copy-pasted. Surrounding a string with single quotes is not valid JSON.
  • Double quote seems to be the most annoying part since even when we do not use href it is a special character for JSON. We are not sure how common it is but in Siemens S7, it is quite common.
  • Escaping the quotes would be tolerable for someone copy-pasting. It can be done by humans easily as opposed to URL-encoding.
  • Best would be to use query parameters if people can get used to it.
  • If we want to do encoding, we can simply encode the part after nsu