• a longer email chain that may be of use when discussing this issue

Randy,

I think the apps idea also causes end users to struggle since a generic client will not understand something and they will not be able to deal with it, So they can not just buy or use any client they will have to look for client and verify that the client supports decimal before being able to use it. And the next time something needs to be added then another newer version of an SDK is needed - what if the next updated is support by some, but different SDK's so then you can quickly get into a case where what is required is not available from any SDK. SDK's are not dictated by the specification and they can not be. If decimalis are not supported in the stack, then it need not be supported by an SDK, since it could just as well be support by custom applications, but then again one of the big benifits about OPC UA is that a client can browse the type system and based on what it finds, it can correctly interpret the data that it recieves. if a base type requires custom code than this important aspect of OPC UA is broken.

Even worse, updating a single application could cause an entire system to fail, even a system built with the latest version of deliverables by the OPC Foundation. The OPC Foundation does not control SDK vendors. and application developed by a particular SDK does not advertise the SDK that was used. This makes it nearly impossible for an end user to determine if something is supported. We can add profiles to track what is supported, but again this is going to place a fair burden on the enduser.

In general I think neither solution is good, so we need to come up with something that is better. Maybe the first step is to list requirements

1) Be able to support extension to the base types (generic?)
2) Support decimal type as a numeric (efficient transport?)
3) Provide alternate manner of transporting (to support backward compatibility) for any new encoding/type.
4) Always have newer version be required to be able to handle communicating with an older version (i.e. so older version does not break). This will require some manner of identifying that a version is a newer version.
5) Make it easy to distinguish if a feature is supported (maybe via profiles?) But do not require that an end user understand all profiles to allow compatibility in the system.

Here are some ideas I had:

If decimal is not a base type then it needs to be something, some possible alternatives:

1) Encode as an extension object (can be an actual decimal on the wire). Negative - is not a number, large structure on the wire - only supported by those that support the encode able object, would not be readable by a generic client Positive - would be part of a variant so SDK will be able to handle, but would require application code to do anything useful with it.
It will cause issues with ISA95 model as currently defined.

2) Encode as a sub type of string - needs to be supported as an option in any manner. Negative - not a number, application support would be needed in all cases to process it or perform anything useful with it. Can be very large on the wire, even for small decimals. Positive - Client could display something even if they do not know what it is. Readable in wire shark. It would be part of a variant so SDK will be able to handle.
If this is the only encoding then it will cause issues with the ISA95 model as currently defined.

3) Encode as a sub type of ByteString - Negative - not a number, application support would be needed in all cases to process it, client would not be able to display without code (even to understand what it is). would not be able to be interrupted by wire shark as anything but a blob Positive - smaller on the wire. It would be part of a variant so SDK will be able to handle.
It will cause issues with ISA95 model as currently defined.

4) Encode as a subtype of structure - Negative - not a number, but individual items are numbers, it would require code to understand it. Positive - smaller on wire than string (at least in many cases), client would be able to display structure (maybe not very useful) could be viewed by wire shark. It would be part of a variant so SDK will be able to handle.
It will cause issues with the ISA95 model as currently defined.

5) Encode as a subtype of Int64array (2), int32array(4) or IntArray16 (8) - Negative/Positive - would be a number, but not convertible between other numbers without code, small on the wire, client could display, but not in a useful manner, could be viewed by wire shark It would be part of a variant so SDK will be able to handle.
It not sure if it would cause issues with the ISA95 model as defined.

A larger issue with stacks does exist: currently there is no manner to exchange information between stacks about version of encoding supported by a protocol. (even protocol version is limited - Hopefully HTTPS will include something?) Providing version information would allow stacks to ensure backward compatibility.

Other options:
Could generate new encoding OPCUABInary2 and XML2 to extend supported encodings, an application that has a new encoding would also expose old encodings and send data using one of the above encoding(1-5) for a decimal (or other new Base types that are not supported by older end points). I would also hope that we don't need to come up with addition encoding endpoints in the future - the new encoding end point should include some manner of indicating encoding version supported. Newer version have to understand what is available in older versions and anything new that is added must always have a fall back (secondary encoding) that can be used with an older version.

These are just thoughts and I think they maybe worth discussing at some point, Maybe someone else has a good idea.

Paul

On Sat, Jun 9, 2012 at 12:33 AM, Randy Armstong <randy@ravensjade.com> wrote:
Paul,

You present two options:

1) A lesser application developer experience for some developers because not all SDKs will support the new types;
2) A lesser end user experience for all end users as end users struggle with incompatible applications due to a different wire protocol;

IMO – 1) is the only reasonable choice. The end user experience is more important especially since the change affects all end users but the SDK issue only affects developers who care about the decimal types.

There is no issue with exchange of XML NodeSets because NodeSets include the UA DataType which will correctly identify the string as decimal.
So we can support import/export of decimals with no changes and no worries of IOP problems.
This would not be true if we updated the NodeSet to support new types in the Variant.

No matter how much we would wish it there is no way to change the wire encoding without creating IOP difficulties in the field.
The protocol version was not intended for this purpose.
It was for dealing with critical security exploits which is why it was not included in protocols where the security is being handled by a layer out of our control.

At this point in time the priority for the UA WG should be on how to make the UA end user experience better because that is critical to UA adoption at this point.
The subset of application developers that care about decimals will learn that they need to choose SDKs that support their preferred types.

Regards,

Randy

From: Paul Hunkar [mailto:Paul.Hunkar@Dsinteroperability.com]
Sent: Friday, June 08, 2012 8:59 PM
To: Randy Armstong
Subject: Re: decimal

Randy,

The problem is that there are 3 stacks and an unknown number of SDK's and there is no way for a client to determine if a server is built by a SDK that would support the update or vice a verse. Also a user of a server or client would not be able to tell, since neither advertises what SDK they were built by. Loading an information model (XML Model exchange) into a server would cause failures, in the server since it does not support a base type and you would not be able to tell.

I guess if it is in an SDK then we can add profiles that would allow clients and servers to determine if they support decimal, but even in that case it will be a mess. One would have to connect first to determine if decimal is supported.

A new encoding would make much more sense since it would be easy to determine what is supported, without even connecting. Any server that supports OPC UA Binary2 would also expose OPC UA Binary, by definition.

Ideally what ever we do, we need a way to be able to extend encoding in the future - I can see int128 or other items in the future, so whatever the solution it would need to be able to include something that indicates a new version. The protocol version was the right idea, we just did not implement it in the correct manner. It should have allow encoding versions also. Maybe we will need to think how an encoding version can be shipped, so that a client and server can both gracefully fall back to an encoding that they both support.

The import/export code also has to be able to support the new types so it is even more extensive.

I'm still thinking about possible solutions, but nothing makes a lot of sense as of yet.

Paul

On Fri, Jun 8, 2012 at 7:42 PM, Randy Armstong <randy@ravensjade.com> wrote:
Two versions of UA Binary would be a nightmare.

The XML encoding can tolerate adding a decimal in theory but the XML decoder code has a switch statement that checks for the known types in a Variant.

If an unknown type is encountered it throws an exception.

In short – an application cannot send decimals in an XML variant unless it knows the receiver can understand them.
Sending unknown types will result in the entire message being rejected.

Changing at the wire protocol level (even in V2) is too risky and will harm UA more than it helps.

We should solve this at the SDK API layer. The users of the data do not care where it is solved as long as it works.

From: Paul Hunkar [mailto:Paul.Hunkar@Dsinteroperability.com]
Sent: Friday, June 08, 2012 5:05 PM
To: Randy Armstong
Subject: decimal

Randy,

Does the XML encoding support decimal?

If it does then we can add decimal via a new encoding OPC UA Binary2. Decimal built in type in OPC UA Binary would be a string only? What do you think?

Paul

Discussed in F2F in Dallas. Current approach is to define a decimal as a numeric data type in the specification and include it the base system. Since the stacks can not add a new base data type - it would be encoded as a structure on the wire. An old stack would see a structure that they do not understand, but that is ok since they will not do anything with it. New stack would translate it back to the actual type.

Added to Part3 and referenced in Part 5

Part3 defined table updated to include Decimal data type

Agreed to changes in Raleigh meeting.