OPCBinarySchema Incomplete? about ua-nodeset HOT 10 CLOSED

The SourceType and BaseType are artifacts that used to be used to re-construct the type hierarchy from the BDS. This create a potential source for conflicts because the type hierarchy in the BSD could be different from the type hierarchy in the UANodeSet.

This was resolved when the DataTypeDefinition was added to the UANodeSet which meant the UANodeSet would be the only source of information on the type hierarchy.

For clients that consume the BDS in order to process unrecognized structures the BSD should provide. sufficient information without the SourceType and BaseType. Smarter clients that wish to make use of the type hierarchy can Browse the type hierarchy directly.

I will put in a mantis issue to remove them from the official BSD until you have a specific reason to keep them.

from ua-nodeset.

It's unfortunate that they can differ because it's nice to be able to generate the structures without also needing to have the entire UANodeSet parsed and available...

edit: I guess I mean generate the structures with sub-type information, but maybe it doesn't even really matter if you generate the structures with correct with sub-typing in place.

from ua-nodeset.

I don't want to break code that already exists. We could add them as optional features and continue to include them in the official BSDs. However, I suspect optional would not help you. Is that the case?

from ua-nodeset.

Right now I'm only using these attributes in the code generator that generates the structures used in the stack.

There is no generic code generator being used in production nor one that is used to generate dynamic encoders/decoders at this time.

I think it would be best if I eventually modified the code generator to optionally use available hierarchical information from a UANodeSet, and to just generate the structures without that information if it's not present.

Since the sub-classes define all the fields from the parent in the binary definition the only thing I lose is generated code where e.g. VariableAttributes actually extends NodeAttributes.

from ua-nodeset.

The UANodeSet DataTypeDefinition has all of the information you need to build a code generator now. The BSDs are optional at this point and are primarily present to allow the dynamic parsing of structures.

from ua-nodeset.

You've mentioned DataTypeDefinition twice - do you mean DataTypeDescription?

from ua-nodeset.

1.03 Part 6 Annex F Section F.11

A DataTypeDefinition defines an abstract representation of a UADataType that can be used by design tools to automatically create serialization code. The fields in the DataTypeDefinition type are defined in Table F.11.

from ua-nodeset.

Okay, so if I understand all of this...

DataTypeDefinition is something that exists only in a UANodeSet file. It's not exposed via the address space in any way. Just part of the UANodeSet schema.

If you're trying to build definitions from node instances in a working address space, you instead would use the DataTypeDictionary, which is a ByteString containing what would be the entire BSD file, or if alternatively if all the types are modeled, there will be DataTypeNodes with DataTypeDescriptions that contain just the appropriate fragment from whole type dictionary.

Something like that?

from ua-nodeset.

Yes. UANodeSets are now a complete description of all types defined by a specification.

BSDs are only used to publish the structure or type for clients that support dynamic parsing.

from ua-nodeset.

OPC UA... so simple...

Thanks for your time and clarification.

from ua-nodeset.