The object element (II.7) is used to indicate support for an object that is defined in the associated DM Data Model. In addition, it can indicate how this object is supported differently (usually a “narrowing” in scope) from its DM definition.
All supported objects will be specified within some DT Instance. If an object defined in a DM Data Model is omitted from the DT model(s), then this means that the device type does not support this object.
As in the DM Data Model, objects are logically organized into an object hierarchy. The DT object hierarchy will follow the same layout as its associated DM Data Model (minus the unsupported objects).
7.4.1 Supporting Single-Instance Objects
Support for a single-instance object is specified within a model using the object element (II.7). Its object/@ref attribute specifies the path name of the corresponding DM object to be supported.
The object specification will include the following required attributes: ref, access, minEntries, and maxEntries. For single-instance objects the access (from the ACS point of view) will always be readOnly, minEntries can be 0 or 1, and maxEntries will always be 1. Basically, these attributes will have the same value in the DT object as they do in the corresponding DM object definition (i.e. none of these attributes can be supported differently). The following example illustrates support for the Device object. Note that its path name corresponds exactly to an existing object in the DM Data Model.
<dt:document xmlns:dt="urn:broadband-forum-org:cwmp:devicetype-1-1" ... deviceType="urn:your-company-com:some-device-type-id"> ...
<model ref="Device:2.2"> ...
<object ref="Device." access="readOnly" minEntries="1" maxEntries="1"> ...
</object> ... </model> </dt:document>
Note – An object will also contain parameter elements; this is not shown in the above example. See Section 7.5 for further details.
7.4.2 Supporting Multi-Instance Objects
Support for a multi-instance object (table) is specified within a model using the object element (II.7). Its object/@ref attribute specifies the path name of the corresponding DM object to be supported.
The object specification will include the path name, plus an indication of whether the object is read-only or read-write (from the ACS point of view), and the number of instances of that object that can exist within the CPE. This corresponds to the following required attributes: ref, access, minEntries, and maxEntries.
The object/@access attribute indicates whether the table will have read-only or read-write access. Valid values include one of: readOnly, create, delete, createDelete. When object/@access is “readOnly” the ACS can only retrieve object instances from the CPE. When object/@access is “create” the ACS can retrieve and create, but not delete object instances. When object/@access is “delete” the ACS can retrieve and delete, but not create object instances. When object/@access is “createDelete” the ACS can retrieve, create, and delete object instances.
For a multi-instance object, the following restrictions apply:
If the associated DM object has readWrite access, then the DT object can have any of the aforementioned access values. However, if the associated DM object is readOnly, then the DT object must also be readOnly. This means that read-only DM objects must remain read-only in the DT, but that writable DM objects can be restricted via the DT in how they are accessed by the ACS.
The object/@minEntries and object/@maxEntries attributes must be specified such that their integer values fall within the min-maxEntries range specified by the DM object (i.e. restricting the range of min-maxEntries in the DT object, not expanding it). So the DT minEntries will be greater or equal to the DM minEntries, and the DT maxEntries will be less or equal to the DM maxEntries (with the proviso that minEntries must be less than maxEntries, and that all values are regarded as being less than an “unbounded” maxEntries).
The following example illustrates support for various tables in the InternetGatewayDevice:1.2 Data Model. Each object references a path name that corresponds to an existing object in the DM Data Model. <dt:document xmlns:dt="urn:broadband-forum-org:cwmp:devicetype-1-1" ... deviceType="urn:your-company-com:some-device-type-id"> ... <model ref="InternetGatewayDevice:1.2"> ... <object ref="InternetGatewayDevice.DeviceInfo.VendorConfigFile.{i}." access="readOnly" minEntries="1" maxEntries="unbounded"> ...
</object>
<object ref="InternetGatewayDevice.Layer3Forwarding.Forwarding.{i}." access="delete" minEntries="0" maxEntries="unbounded"> ...
</object>
<object ref="InternetGatewayDevice.LANDevice.{i}.WLANConfiguration.{i}.WEPKey.{i}." access="readOnly" minEntries="4" maxEntries="4">
... </object ... </model> </dt:document>
In the above example, we see support specified for the following tables:
VendorConfigFile.{i} – In the DM this is defined as a read-only, variable-sized table that can have 0 or more entries (min entries is 0, max entries is unbounded). However, in the DT this object is supported with min entries of 1; i.e. a CPE of this device type will always have at least one vendor config file.
Forwarding.{i} – In the DM this is defined as a writable (access is readWrite), variable- sized table that can have 0 or more entries. However, in the DT this object’s access is delete; i.e. a CPE of this device type allows the ACS to retrieve and delete, but not create these object instances.
WEPKey.{i} – In the DM this is a read-only, fixed-sized table (min entries equals max entries, which is 4). In the DT this object is specified the same as its corresponding DM object definition, meaning that it is supported as is without change.
Note – An object will also contain parameter elements; this is not shown in the above example. See Section 7.5 for further details.