Hi,

(sorry, this is a bit long)

Generally we have been recommending to define the types in the nodesets and instances in code. I would say outside of trivial examples, it would usually be quite pain to model all the instances in the models. Additionally typically you will have some external system which will dictate what the instances should be. That is one of the reasons why we currently generate Ids for type-space only.

Generally I would say due to modelling the types, you should usually have a well known entry point (i.e. you know the NodeId or BrowsePath) to the instances you are interested in. Then you should have instances of some types, and those types TypeDefinition does define the rest of the structure of the nodes. The codegen will create more specific versions of the UaNode interface (+ the impls) which help to access the rest of the node-tree.

For example, if you would know an id is of AnalogItemType, then you could do the following.

But to return to your “below 6 folders and 4 objects” example. Typically in these skenarios, you will have the (Expanded)NodeId for the node stored somewhere (conf files, hardcoded values etc.) and use it directly. Note that this NodeId would not be generated by the codegen, you would need to look that up (or e.g. the user of your software would either use generic clients to find it, or you could have an address-space tree selector built-in).

If possible, I would like to have a more concrete example, if there is a specific use-case where you feel this is not enough, as this answer is getting quite long and in some cases some other approach might be better. For example in some cases the UaClient.getAddressSpace().translateBrowsePathsToNodeIds(…) might be better.

P.S.
We will investigate at some point if an option to generate Ids from instances would be added. There are some not-so-obvious constraints to consider for a generic solution (a lot of low-lvl tech stuff below):

1. A Java classfile can contain maximum of 65535 or so bytes of bytecode or it cannot be compiled. At bare minimum, initialing a static constant will take up 6 bytes of bytecode (invokestatic + putstatic both take op code + 2 bytes). This is without having any parameters for the static method (which would usually be 3 or more bytes). For the standard model, which basically just defines types (+the Server instance node), is a bit over 10000 identifiers. We have somewhat solved this by abusing the fact that java interfaces can be multiple inherited and statics are accessed via inheritance (so we split the ids per NodeClass and for backwards compability the Ids will inherit all of them). Additionally the initialization static methods are created for each id in a separate class (as having a parameter would increate bytecode count). If we were to generate ids for instances as well, we would need to prepare for a larger id count. But an option to turn this on would probably be the best.

2. As far as I’m aware, in type-“space” each BrowsePath must be unique. This means if we generate the ids with name like Type_InstanceDeclaration1_InstanceDeclaration2_LeafInstanceDeclaration we should get all type-related-ids and all of they should have unique name for the code. This restriction does not apply to instance-“space”, multiple nodes can have the same names i.e. a BrowsePath can target multiple nodes in the instance-space. For code-generation this means either the files wont compile due to duplicate fields or we need to leave some out (or come up with some other naming scheme). Also if we start Objects_X_Y_Z_A_B_C_Leaf we could still get conflicts and the names would probably end up absurdly long. The same can somewhat be said for the type-ids naming scheme, but that is at least somewhat consistent.

P.S.2.
I guess I should clarify that instances that would be like the “DeviceSet” folder of the DI spec would not be a problem and would be something we would like to generate, but there is no easy way to recognize them easily from normal instances. But those models usually wont have any “real” instances anyway, so for them at least it shouldn’t be a problem.

P.S.3.
For modelling purposes, it might be best to separate the type-model from the instance model anyway, i.e. they probably should be in separate namespaces. This is because clients can be programmed vs. a model, but unless those instances should be part of every server having that (type) namespace (like the “DeviceSet” is in the DI model), then I recommend putting the instances to a separate model.

I would maybe argue at least a bit that that is not proper information modeling. Technically yes, you can do this, but from the type’s perspective it lacks semantic information if it is just raw folders. This is unless the folders actually represent e.g. a filesystem (the there is the FileDirectoryType) or equivalent real nesting system. Then again I’m not sure if this just the case in this example. I’ll probably follow-up in some post depending how it was. This has implications on the answers I can give, i.e. if they are just raw folders, then codegen wouldn’t help much (except the Ids generation part). If they are actual types describing the node-structure of them, then the codegen would generate the helper methods like seen above in the case of the AnalogItemType.

Additionally, from the example I’m not 100% sure do you actually have an ObjectType, that has an InstanceDeclaration of the FolderType, and below that InstanceDeclaration, you would have additional ObjectType nodes. As I’m not sure if that is allowed, i.e. each XXXType NodeClass nodes must be linked with HasSubType references to form the type hierarchy. Therefore in these kinds of examples I would model them as such:

(ID meaning InstanceDeclaration)

AType
– B (ID, FolderType)
– C (ID, FolderType)
– D (ID, DType)
– E (ID, FolderType) <– This comes from the DType TypeDefinition
– Potential subtypes of AType etc.

DType
– E (ID, FolderType)

But anyway, assuming you know the BrowsePath, which this looks like and assuming there are no duplicates (or you can handle them), I would say in this case the TranslateBrowsePathToNodeId service call would probably be the easiest or at least this fits for it’s use-case. Therefore you could do something like (this assumes a bit from your example, but should be enough to explain it):

    ExpandedNodeId expandedNodeId = ... //For the instance of A
	NamespaceTable namespaceTable = client.getNamespaceTable(); //or some other way
	
	// This or ExpandedNodeId can be used for the UaBrowsePath.from(...)
    UaNodeId startId = UaNodeId.fromLocal(expandedNodeId, namespaceTable);

    // Assumed, and might be different per "hop"
    int namespaceIndex = 2; // need to know the index or uri
    String namespaceUri = namespaceTable.getUri(namespaceIndex);
    UaNamespace ns = UaNamespace.from(namespaceUri);

    // Different ways to construct
    UaQualifiedName hop1 = UaQualifiedName.from(namespaceUri, "A1");
    UaQualifiedName hop2 = UaQualifiedName.from(ns, "A11");
    UaQualifiedName hop3 = UaQualifiedName.from(new QualifiedName(namespaceIndex, "A11A"), namespaceTable);
    UaQualifiedName hop4 = UaQualifiedName.standard("A11A1"); // (if it would be in the 0-namespace)

    UaQualifiedName targetNode = UaQualifiedName.from(namespaceUri, "A11A1A");

    UaBrowsePath uabp = UaBrowsePath.from(startId, hop1, hop2, hop3, hop4, targetNode);

    boolean isInverse = false; // Look only forward direction
    ExpandedNodeId referenceType = ReferenceTypeIds.HierarchicalReferences;
    boolean includeSubTypes = true; // Look additionally all sub-reference types of the above

    BrowsePathResult[] pathsResults = client.getAddressSpace()
        .translateBrowsePathsToNodeIds(uabp.toBrowsePath(namespaceTable, referenceType, isInverse, includeSubTypes));

    // we did pass a single BrowsePath to the service call
    BrowsePathResult pathsResult = pathsResults[0];
	
    for (BrowsePathTarget target : pathsResult.getTargets()) {
      ExpandedNodeId targetId = target.getTargetId(); // <-- should be id for targetNode A11A1A
      // And as mentioned, duplicates are a possibility.
    }