Yes, precisely so. Since both the Item ID and the browse path are strings, we could not distinguish them in the API just by their type. And, because Item IDs are much more common, they are the ones that either have special overloads, or strings are implicitly converted to them.

As you correctly figured out, you need to construct the DAItemDescriptor and fill in the browse path there, if you want to use browse paths with the procedural model.

Also note that in the DAItemDescriptor, either Item ID, or browse path, or both can be filled in (if they are both filled in, it is your responsibility that they both refer to the same item). The component will internally use whatever is more efficient at the time (which is usually the Item ID). If only the browse path is filled in, and an Item ID is needed, it will first try to convert it (which is quite inefficient); the results of the conversions are cached, however, so next time the same browse path will be transformed to an Item ID much quicker.

Best regards

This is very important question - and it is very important to understand it right. Please refer to the "Concepts" document for discussion of Item IDs and browse paths. I will copy a part of the document below, for convenience. It is rather lengthy subject, and possibly confusing to newcomers to OPC. Besides the description from the doc, I'll try to give a short answer in just two statements:

1. ItemID syntax, including the delimeters (if any are used at all!) is not standardized, it depends totally on the target OPC server, and may not even correspond to the hierarchical structure of browsing in the address space.

2. Browse paths are sequences of "short" browse names of nodes in OPC address space, starting from the root, and we have defined a syntax for them which uses '/' as a delimiter between the parts.

Kepware uses dots in ItemIDs, but if you are/were writing a software that should work with any server, your code MUST NOT rely on this, NOR should it assume on the fact that ItemID of a child is somehow composed from ItemID of its parent and something else - it does not have to.

From the Concepts document:

Nodes and items in OPC address space can be specified using their node Id (or item Id), or using so-called browse paths.

The item Id (or node Id) is a string that uniquely addresses an item (or a node) in OPC address space. Its syntax is determined by the OPC server. It usually consists of the names of nodes used to reach that node from the root of the OPC address space, together with some decorating characters and separators. This is not a requirement, however, and the OPC server may even use item Ids that do not resemble the node names at all. Unless you have detailed knowledge of the particular OPC server you are connecting to, you should not attempt to create item Id strings yourself, from various parts – they should always come from the server. Item Ids (node Ids) are specified by the ItemID property of the DANodeDescriptor or DAItemDescriptor object. Strings convert implicitly to DANodeDescriptor or DAItemDescriptor containing the input string as the value of ItemID property, and you can therefore simply use the string item Ids in place of node and item descriptors.

Browse Paths

An alternative way (to using a node ID) of specifying a node in OPC address space is using a browse path. The browse path is a sequence of node names, starting from a known location (e.g. the root of the OPC address space). The browse path can also be expressed as a string, where the individual node names are separated by delimiters (e.g. “/”, a slash).

Browse paths can be absolute (starting from a specified node), or relative.

The advantage of the browse paths is that you can construct them yourself, with just knowledge of the node names, without knowing the full node IDs. In the end, each item must be addressed by its node ID, and QuickOPC will resolve the browse path to a node ID as necessary.

Browse Paths for OPC Classic

In OPC Classic, absolute browse paths always start at the root of the OPC address space, because the root is the only “pre-defined” or well-known node.

An absolute browse path for OPC Classic is contained in a BrowsePath object. Browse paths are commonly specified by the BrowsePath property of the DANodeDescriptor or DAItemDescriptor object.
If a non-null ItemID is specified in the descriptor, QuickOPC will use this item Id and ignore the browse path. If ItemID is null, QuickOPC will attempt to resolve the browse path contained in the BrowsePath property of the descriptor. Either item id, or browse path (or both) must be specified.

Besides the ability to get around usage of full node IDs, the other reason to use browse paths is for OPC browsing with OPC Servers that only support OPC Data Access 1.0 specification. Such OPC servers cannot start the browsing at a node in the address given just by its Item ID; the node must always be reached by browsing from the root level. If the ID of such node it already known, QuickOPC takes care of supplying the proper browse path automatically, but this cannot be always done. If, however, a browse path is given (which can be done by using the DANodeElement that is the output of the browsing to construct the DANodeDescriptor that is the input of further browsing), the browsing can proceed normally.

OPC Classic Browse Path Format

In OPC Classic, the slash at the beginning of the browse path denotes an absolute path that starts from the root of the OPC address space. The string form of a browse path is a concept on the client side (QuickOPC), and does not appear in OPC specifications.

A browse path can be represented by a string; in such case, it can express either a relative or absolute browse path (the BrowsePath object cannot hold relative browse paths).
As mentioned above, the format of the browse path string is such that the individual node names are separated by slashes (“/”). The slash at the beginning of the browse path denotes an absolute path that starts from the root of the OPC address space. In addition, ‘.’ denotes a current level, and ‘..’ denotes a parent level, similarly to the conventions used in Windows file system.

Because the node names can contain any characters, we need to consider situations in which the node name itself contains a slash (‘/’) or a dot (‘.’). In such case, in the string format of browse paths, these characters are escaped by preceding them with an ampersand (‘&’). An ampersand itself needs to be escaped, too.