But the Value cannot be Variant.Empty for mandatory properties.

However, the "" rule does not apply if the description of the property makes it clear that "" is not a valid value:

SourceName provides a description of the source of the Event. This could be the string-part of the DisplayName of the Event source using the default locale of the server, if the Event is specific to a Node, or some server-specific notation.

(i.e. "" is not a description)

Clients should be designed defensively to deal with misbehaving Servers but that does not make the server right.

Is it allowed, according to the specifications, to set the value on a mandatory property, in an event, to null. 

For example:

Assuming an event of EventType BaseEventType.

Is it allowed for an OPC UA server to set, for example, property SourceName to null in the event?

If it is, is it the same for any mandatory property in any EventType? 

Should an OPC UA client be able to take that into account?

Thanks

https://mantis.opcfoundation.o.....default=no

https://mantis.opcfoundation.o.....default=no

Section 9.1 General of OPC 10000-3; OPC Unified Architecture Part 3 :Address Space Model; Release 1.05.06; 2025-10-22 starts with "The remainder of 8.61 defines EventTypes." Section 8.61 is about CurrentyUnitType.

See also section 4.1, first paragraph, last sentence: "Standard ReferenceTypes, DataTypes and EventTypes are defined in Clauses 7 to 8.61."

As well section 4.7.2 EventTypes, last paragraph, first sentence: "Standard EventTypes are described in Clause 8.61."

There seem to be a typo, an incorrect or undefined reference.

Thanks and regards

I'm working through the spec, currently OPC 10000-3; OPC Unified Architecture Part 3 :Address Space Model; Release 1.05.06; 2025-10-22.

Annex B, section B 3.4 Object and ObjectType is short with the follwoing text: "Objects and ObjectTypes are shown in Figure B.8."

The description of the figure is given, but the figure itself is missing.

At least the necessary information is shown in figure B.7. Figure B.7 is a bit cluttered and makes it hard to make out specific details.

Best regards

Second, use the KeepAliveInterval to keep your Publish requests fresh.

i.e. use 10 mins TimeoutHint but a 5 min PublishingInterval and KeepAliveCount = 1.

This ensures a PublishRequest is consumed long before it times out.

You would only get actually data in a response when the SamplingInterval expires (10,000 ms, 15,000 ms or 86, 400, 000 ms)

Given that PublishRequests are using for multiple subscriptions, say you have the following 3 subscriptions:

10,000 ms  Publishing Interval

15,000 ms Publishing Interval

86, 400, 000 ms (24 Hour) Publishing Interval

What would be the recommended Timeout Hint to use for Publishing Intervals given that if I use something greater than 24 Hours it will take 24+ hours for the requests to timeout for the faster publishing intervals?

This would cause excessive delays to users in knowing that the requests for faster publishing intervals have timed out.

However, some limits may be enforced by the stack.

For example, a Variable may have MaxStringLength of 2GB but the server configuration limits array lengths to 1MB so a request with a 2GB string would be blocked before its gets out of the stack.

You can assume SDKs enforce communication level limits but the Server application will likely need to enforce limits on individual values.

Does the stack/sdk check this ranges or does each application have to do it on its own? For example if a client calls a method with a structure as parameter and MaxStringLength exceeds the defined limit in the NodeSet. Where does this check happens

- the client application before calling the method

- the client SDK

- the server SDK

- the server application after receiving the data and loaded it into the RAM, but before processing it

I'd be surprised if the SDKs didn't check this, because the information is standardized in the NodeSets and can serve as the first line of defense against resource constraints or DOM attacks.