We have a question about the encoding of fields that are of type QualifiedName, for instance the BrowseName of a node. We understand that there are several encodings :
When the BrowseName is XML encoded, it has the following structure, as per specification 1.03 Part 4 §188.8.131.52 :
<xs:element name=”NamespaceIndex” type=”xs:int” minOccurs=”0″ />
<xs:element name=”Name” type=”xs:string” minOccurs=”0″ />
which is coherent with what is found in Opc.Ua.Types.bsd.xml
<opc:Documentation>A string qualified with a namespace index.</opc:Documentation>
<opc:Field Name=”NamespaceIndex” TypeName=”opc:Int32″ />
<opc:Field Name=”Name” TypeName=”opc:CharArray” />
When the BrowseName is described in the node sets xml (e.g. Opc.Ua.NodeSet2.xml), the BrowseName is a simple string, as described by the UANodeSet.xsd : <xs:simpleType name=”QualifiedName”> <xs:restriction base=”xs:string”></xs:restriction> </xs:simpleType> which is understandable, as the BrowseName is an attribute. However, in specification 1.03 Part 6 Annex F.3, it is said that “[the BrowseName is] a QualifiedName serialized as a String with the form: <namespace index>:<name> Where the NamespaceIndex refers to the NamespaceUris table.”. This form tends to make the colon mandatory. The colon is not present in Opc.Ua.NodeSet2.xml.
The questions are:
Did we correctly identified how a QualifiedName is encoded?
Why are there two encoded forms for QualifiedNames?
Is there some specification that defines QualifiedNames with optional colon?
Thanks, Best regards,
I am sure others will have more qualified replies here to help you out, but AFAIK, you have it right. The “encoding” is really just the first form; the other (nodeset) does not appear in OPC UA “runtime” anywhere. And the reasons might be historical or simply an overlook.
Thinking about it, however, some more observations came to my mind:
– I am not aware of any limitation to the name part of the QualifiedName other than it should not exceed 512 characters. If so, even the name itself can start with a number and a colon. That would bring ambiguity in the syntax used in the nodeset, if the index and colon are treated as optional. Because “1:MyName” could then either denote a NamespaceIndex=1 and Name=”MyName”, or NamespaceIndex=0 and Name=”1:MyName”.
– I do not see the spec saying that the name part shall not be empty, which would be a reasonable restriction.
The UANodeSet is a specialized import/export format which is not used in any over the wire communication between applications.
The UA XML encoding are rules used by UA apps to communicate using XML messages.
The BrowseName text is “Unicode character string that should exclude control characters that are not whitespaces.”.
The UANodeSet format presumes that the OPC-F (i.e. namespace 0) would never define a BrowseName starting with a number and a colon. Other information models can do this because the index prefix must always be there so 1:1:X would be the BrowseName “1:X” in Namespace 1.
A blank BrowseName in NS0 is defined to be a NULL BrowseName.
Other namespaces could blank BrowseNames them but it does not make sense.
Thanks for your responses.
Could you point us toward the spec section that contains “Unicode character string that should exclude control characters that are not whitespaces.” ?
Are the “control characters” defined somewhere ?
When you say:
The UANodeSet format presumes that the OPC-F (i.e. namespace 0) would never define a BrowseName starting with a number and a colon.
Is this taken from the spec ?
Most Users Ever Online: 87
Rod Stein: 25
Martin Lang: 22
Randy Armstrong (Sparhawk): 20
Guest Posters: 1
Administrators: email@example.com, firstname.lastname@example.org, Randy Armstrong
Moderators: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Jim.Luth@Schneider-Electric.com, Karl-Heinz Deiretsbacher, firstname.lastname@example.org, email@example.com