In order to understand this attribute does, please first have a look at the discussion about Item IDs and browse paths (
www.opclabs.com/forum/general-issues/1543-string-for-itemid#2776 ).
The live mapping needs to identify the nodes (items). It uses the underlying mechanism of QuickOPC, which allows to identify the nodes (using DANodeDescriptor class) with by an Item ID, or by a browse path, or both. Most commonly, the items are identified using Item IDs, because it is very effective, and Item IDs are returned from hierarchical address space browsing, therefore clients can store them and reuse them as needed.
The problem is, as explained in the references article, there is no general/standardized relation between Item IDs in the address space tree. They can be just arbitrary strings. But with the mapping, when e.g. a branch is mapped, one wants to be able to map its sub-nodes as well, and for it, it needs to identify these OPC nodes somehow. Can we use Item IDs? Yes - but you would have to a) explicitly specify the ItemId for EACH item you map, and what's worse, b) you will NOT be able to do that if you wanted the instances of the same class be reused for mapping to different branches - because there would be just ONE, concrete, Item ID associated with the member you map.
That's why browse paths are much better for the mapping. Here, one can construct a browse path for a child by appending a short name of the child node to the browse path of the parent. This approach works well. It only has two disadvantages, both are, I think, minor, but should be mentioned: A) Browse paths are less effective (one needs to obtain all sub-nodes under a parent in order to find a sub-node with the given name), and B ) With some old servers (OPC-DA 1.0), in general case, it is not possible to "root" the mapping by an Item ID in the middle of the tree and then continue with browse paths from there (ignore this if you don't understand - it's quite involved and complicated).
The DAItemIdTemplateAttribute is intended to provide a "middle ground" between the use of Item IDs and browse paths. Unless you have some problems with the usage of browse paths (such as performance), do not use it, because it is less general. With [DAItemIdTemplate], you CAN tell the live mapping system how the Item IDs are composed - but that depends on the specific server you are using. You can, for example, specify the template for nodes in Kepware server (except for those that are right under the root) as follows: "$(ParentItemID).$(BrowseName)". So you specify that the first part of an Item ID of a child is its parent's Item ID, then there is a "dot" delimiter, and then there is a short browse name of the child node. The live mapping can then infer the Item IDs of any child nodes using the template. Really the only benefit I can think of now that you can get from this is a slight performance improvement.
