How to re-define param type of a method from the AutoID spec|OPC UA Companion Standards|Forum|OPC Foundation

Hello!

We are using OPC UA for embedded devices based on AutoID Companion specification. This specification defines several standard methods to access various types of storage media, e.g. in case of RFID technology it would be ReadTag method to read out data from  RFID tags.

The method ReadTag has a list of parameters, that should be given upon the method calling.
The first parameter is of type ScanData, which is a union that defines the format of the data scanned by the device. The type definition of ScanData is also part of the AutoID spec.  The union refers to several data members, which are called ByteString, String and Custom to be able to represent various data formats. It can easily be deduced that there are corresponding standard types behind ByteString and String defined by the basic OPCUA specification, while Custom is intended to be defined and enhanced by the device manufacturer.

In the AutoID CS the  Custom member has the abstract data type BaseDataType that can’t be used directly.
In order to create an usable Custom member with valid data type I want to re-define its definition  and assign one of the standard data types, e.g. String to it.  

My question is, is there a standard way to achieve this?

Right now I can only think of one possible solution:

1. Define a new union type based on ScanData with Custom member defined as a String instead of BaseDataType and give it a new type name in the device specific namespace, e.g. MyDeviceScanData.
2. Remove the existing definition of ReadTag method from the NodeSet and define a new one with the same name and param list except the first parameter – it will reference the new MyDeviceScanData instead of ScanData now.

This approach raises several questions:

• Should the “overloaded” method ReadTag be placed in the same device specific namespace as MyDeviceScanData other than AutoID namespace?
• Or new ReadTag method definition can be left in the original AutoID namespace and reference the MyDeviceData in the another namespace?
• Does this approach conform to the general concept at all or is there a different one?

Thanks in advance!