Type dictionary (legacy)

How the dictionary is published

Under the TypesFolder the server exposes type system folders for OPC Binary and XML Schema. Each holds DataTypeDictionary Variables whose value is the entire schema document as a ByteString, plus DataTypeDescription Variables naming individual structures within it. A DataType's encoding node points at its description with a HasDescription reference, so the decode path is: encoding node, HasDescription to the description, description's value gives the name to look up inside the dictionary blob.

Why it was replaced

The dictionary is a document, not a model. A client has to download it - often hundreds of kilobytes on a rich server - parse a second schema language, and match names by string. It cannot express the 1.04 structure features, and it puts a parser for an obsolete format into every client. DataTypeDefinition moves the same information into node attributes the client is reading anyway, which is why the UA-Nodeset repository now marks the .Types.bsd files obsolete while still shipping them.

The interoperability failure

The two mechanisms are independent, and a server may publish either, both or neither. A modern client that only reads DataTypeDefinition, pointed at an older server that only publishes a dictionary, gets no definition and returns opaque ExtensionObjects with a Good status - the read succeeds and the data is unusable. The mirror case is just as common: an older client or a compiled-stub stack against a lean 1.05 server that publishes no dictionary at all. This migration is still live in the field; the umati dashboard client documents custom DataTypes via type dictionary as only partially working and the DataTypeDefinition path as still coming.

What to do about it

Test both paths explicitly when you qualify a client-server pair. Browse the type system folders: if they are absent or empty, the server has gone definition-only. Read the DataTypeDefinition attribute on one custom DataType: if it comes back empty, the server is dictionary-only. Where you control the server, publishing both is the pragmatic answer for a mixed estate; where you control the client, implement the definition path first and keep the dictionary path as fallback.

Example

The two decode paths from the same DataType node

DataType  ns=1;i=3002  RecipeStep
 |
 |-- Modern path (1.04+)
 |     Read attribute DataTypeDefinition
 |       -> StructureDefinition { DefaultEncodingId, StructureType, Fields[] }
 |     Decode directly. No document download.
 |
 +-- Legacy path (pre-1.04)
       --HasEncoding--> ns=1;i=5002  "Default Binary"
           --HasDescription--> ns=1;i=6002  DataTypeDescription
               Value: "RecipeStep"          <- name inside the dictionary
               --ComponentOf--> ns=1;i=7001 DataTypeDictionary
                   Value: ByteString, the whole .bsd document
                   e.g. <opc:StructuredType Name="RecipeStep"> ...

Browse to tell which a server supports:
  Types
   +- OPC Binary        <- present and non-empty  => dictionary available
   +- XML Schema        <- often present but unused
  (both folders absent or empty => definition-only server)

Defined in: Part 3 - Address Space Model for DataTypeDefinition; Part 5 - Information Model for the DataTypeDictionary and DataTypeDescription node types; the OPC Binary schema files ship as .Types.bsd in the UA-Nodeset repository and are marked obsolete there.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.