It was removed from the final release 1.05.03 specification.

Unfortunately, it remained an orphan in the official NodeSet until UA-1.05.06.

Given that error, it can be added back in with a deprecated tag and the same NodeId.

You can manually cut and paste into the NodeSet you use if you need an immediate fix.

Please submit a mantis issue against Part 8:

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

  <UAObjectType NodeId="i=32502" BrowseName="QuantitiesFolderType">
    <DisplayName>QuantitiesFolderType</DisplayName>
    <References>
      <Reference ReferenceType="Organizes">i=32503</Reference>
      <Reference ReferenceType="HasSubtype" IsForward="false">i=61</Reference>
    </References>
  </UAObjectType>

This leads to problems when our existing customer systems based on UA Standard version 1.05.03 are updating to our latest version
based on UA Standard version 1.05.06. Some customers have instances of the QuantitiesFolderType object type and the updates fail
since the QuantitiesFolderType object type has been removed.

How are update scenarios supposed to be handled when object types are removed from the UA Standard?

the test scripts for client are mainly helper scripts and the behavior must be validated manually.

So for this specific test case - if the server returns a NodeId from an external server -, the expectation is:

Client identifies the Node is different because it is stored on a remote Server. The Client may display or limit the options available on the node or hide the node etc (per Client documentation).

If the client meets this expectation, then it's fine.

I'm just curious, is your client currently throwing an error because the NodeId is invalid?

Nevertheless, your analysis, that the test script also have to add the NamespaceUri when modifying the BrowseResponse, is correct. The NamespaceUri shall be used if a node from a remote server is returned in the BrowseResponse.
On the other hand, the CTT would also have to modify the ServerArray to provide information about the remote server because clients may read that array to access the description of the remote server.

Bugs in the CTT or in the test scripts should be reported here.

However, Namespaces can only be added only while a Server has at least one Client connected. A Server that no Clients connected can update the Namespaces used but it also does not generated ModelChangeEvents.

The specification is explicit here:
https://reference.opcfoundatio.....docs/6.3.1

It is recommended that Servers not change the indexes of the namespace table but only add entries, because the client may cache NodeIds using the indexes. Nevertheless, it might not always be possible for Servers to avoid changing indexes in the namespace table. Clients that cache NamespaceIndexes of NodeIds should always check when starting a session to verify that the cached NamespaceIndexes have not changed.

Does OPC UA specification allow adding or deleting of Namespaces after the server has already started and Running? The specification Part3 9.32 is a bit ambiguous to me. 

"ModelChangeEvents are generated to indicate a change of the AddressSpace structure. The change may consist of adding or deleting a Node or Reference. Although the relationship of a Variable or VariableType to its DataType is not modelled using References, changes to the DataType Attribute of a Variable or VariableType are also considered as model changes and therefore a ModelChangeEvent is generated if the DataType Attribute changes." - https://reference.opcfoundatio...../docs/9.32

"indicate a change of the AddressSpace structure." sounds like incuding Namespace changes, but later "he change may consist of adding or deleting a Node or Reference." talked about only Node and References. 

If you create an instance of a FileType then all of the components will use the BrowseName from the FileType.

The NodeId of the component is whatever you want because the Node is owned by you even if the BrowseName comes from the FileTYpe.

This all explained in Part 3:
https://reference.opcfoundatio.....5/docs/6.4

We are in a discussion with the support of a manufacturer of NC-controllers, providing a integrated OPC UA server, about the namespaces of the BrowseNames of the standard FileType methods Open/Close,...

I am not able to find a clear statement about this in the OPC UA specification, presumable because OPC UA is a quite new topic for me.

The implementation in the OPC UA server defines the BrowseName of the methods in the same namespace as the instance of the file itself. As example:

• NodeId of file: ns=2;s=FileSystem/Part Program/TEST123.MPF
• BrowseName of file: 2:TEST123.MPF
• NodeId of method: ns=2;s=FileSystem/Part Program/TEST123.MPF.Open
• BrowseName of method Open: 2:Open

Should the BrowseName of the method part of namespace 0 because it is inherit from the type definition FileType? Do you can give me a hint to the OPC UA specification, which clearify this?

I would assume, the NodeId and BrowseName of the methods as follows:

• NodeId of method: ns=2;s=FileSystem/Part Program/TEST123.MPF.Open
• BrowseName of method Open: 0:Open

Thank your for your ansers in advance

nico

=> Is this model structure with itemA3 using B as abstract type valid or not?

Declaring an abstract subtype of a concrete type is allowed.

=> is this an invalid definition (I assume this based on your comment)?

It is not valid.

Randy Armstrong said

If a structure defines a mix of mandatory/optional elements (concrete types, e.g. string or Annotation) and has also an element from a abstract type with allowSubtype = false (vgl. to ResultContent), is this valid?

Structures can allowsubtypes or have optional fields. Not both.
If you have a structure with optional fields and you need to allowsubtypes you have to used BaseDataType or Structure as the field DataType.
  

ok, to be more precise: 

=> Is this model structure with itemA3 using B as abstract type valid or not?

Randy Armstrong said

IsOptional and AllowSubtype are mutually exclusive (so fare so good): If I define a structure with all fields manadtory, use one field with a concrete type (isAbstract = false) combined with allowSubtype = true, do the restrictions also apply to the concrete subtype?

Once a type defines a rule all subtypes must follow it. See BaseDataType or Structure work around above.
  

an here again - to be more precise: