Basic Walkthrough – Defining a New Service Data Model

5.4 DEFINING SERVICE DATA MODELS

5.4.2 Basic Walkthrough – Defining a New Service Data Model

This section outlines the basic steps involved in writing a Service Data Model from scratch (i.e. an initial version of a Service Data Model, not an update to an existing Service Data Model). Examples include:

VoiceService:1.0 (declared in tr-104-1-0-0.xml) STBService:1.0 (declared in tr-135-1-0-0.xml) FAPService:1.0 (declared in tr-196-1-0-0.xml)

In many ways, writing a Service Data Model is quite similar to writing a Root Data Model. The main differences with a Service Data Model are:

The model element includes the isService attribute, set to true.

There is a top-level multi-instance object, whose name coincides with the name of the service model. This is the top of this service model hierarchy.

There is a top-level number-of-entries parameter that is associated with the top-level multi-instance service object.

There is no Device.Services (or InternetGatewayDevice.Services) object, which is only defined in a Root Data Model.

This walkthrough is an example of writing the VoiceService:1.0 Data Model.

To begin, the XML Data Model file contains one document element (as required for all DM Instance documents). Note that the spec attribute references the specification that defined the Data Model, TR-104 Issue 1 in this case. Also, the DM Schema v1.1 specified by the dm and schemaLocation attributes was the latest version available when the VoiceService:1.0 Data

Model was written7.

<?xml version="1.0" encoding="UTF-8"?> <dm:document xmlns:dm="urn:broadband-forum-org:cwmp:datamodel-1-0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:broadband-forum-org:cwmp:datamodel-1-0 cwmp-datamodel-1-0.xsd" spec="urn:broadband-forum-org:tr-104-1-0-0"> ... </dm:document>

Add a document description and model element. The model element uses the isService attribute to indicate that this is a Service Data Model; the model name is assigned a minor version number of 0 since this is the initial version of the Data Model.

<description>VoiceService:1 Data Model.</description> <model name="VoiceService:1.0" isService="true"> ...

</model>

Import the bibliography XML file (allows bibliography references to be cited from within description elements throughout the document). Also import the data types XML file. Specify the specific data types to be imported (i.e. only need to import those data types that will actually be used within the document). Both of these import elements go below the document and above the model element.

</import>

Putting it all together

<?xml version="1.0" encoding="UTF-8"?>

<dm:document xmlns:dm="urn:broadband-forum-org:cwmp:datamodel-1-0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:broadband-forum-org:cwmp:datamodel-1-0 cwmp-datamodel-1-0.xsd" spec="urn:broadband-forum-org:tr-104-1-0-0">

<description>VoiceService:1 Data Model.</description>

<model name="VoiceService:1.0" isService="true"> ...

</model> </dm:document>

Add the top-level VoiceService table (a multi-instance object) and its associated top-level VoiceServiceNumberOfEntries parameter (i.e. these are at the top/root of the object hierarchy). Note that all Service Data Models have such a top-level table and associated number-of-entries parameter, where the table name coincides with the name of the Service Data Model. Other points of interest include the presence of the numEntriesParameter attribute.

<parameter name="VoiceServiceNumberOfEntries" access="readOnly"> <description>{{numentries}}</description>

</parameter>

numEntriesParameter="VoiceServiceNumberOfEntries"> <description>The top-level object for VoIP CPE.</description> <parameter name="VoiceProfileNumberOfEntries" access="readOnly"> <description>{{numentries}}</description>

Now continue to build up the object hierarchy. Since this is the initial version of the Data Model, all objects and parameters are defined using the name attribute. And each object indicates its relative position within the hierarchy using the path-dot-notation within its name (e.g. an object with name “VoiceServices.{i}.Capabilities.” indicates that this Capabilities object sits within the VoiceService.{i} object).

Note the FarEndIPAddress parameter below; it is defined using a dataType element that references the IPAddress data type. This is possible here because we imported the data types XML file earlier (which is where the IPAddress data type is actually defined).

<description>The overall capabilities of the VoIP CPE.</description> <parameter name="MaxProfileCount" access="readOnly" activeNotify="canDeny">

</object>

</object>

<description>Information on each active ...</description> ...

<parameter name="FarEndIPAddress" access="readOnly" activeNotify="canDeny"> <description>The IP address of far end VoIP device.</description>

</syntax> </parameter> </object>

Add a profile. Note that objects and parameters within a profile element do not define new objects/parameters; rather, they reference existing objects and parameters defined earlier within the Data Model (via the ref attribute). Also note the requirement attribute, which is used to declare additional requirements on these objects and parameters.

... </object>

</object>

</object>

...

... </profile>

<?xml version="1.0" encoding="UTF-8"?>

<dm:document xmlns:dm="urn:broadband-forum-org:cwmp:datamodel-1-0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:broadband-forum-org:cwmp:datamodel-1-0 cwmp-datamodel-1-0.xsd" spec="urn:broadband-forum-org:tr-104-1-0-0">

<description>VoiceService:1 Data Model.</description>

<model name="VoiceService:1.0" isService="true"> ...

<parameter name="VoiceServiceNumberOfEntries" access="readOnly"> <description>{{numentries}}</description>

<description>The top-level object for VoIP CPE.</description> <parameter name="VoiceProfileNumberOfEntries" access="readOnly"> <description>{{numentries}}</description> <syntax> <unsignedInt/> </syntax> </parameter> </object>

<description>Maximum total number of distinct voice profiles supported.</description> <syntax> <unsignedInt/> </syntax> </parameter> ... </object> <object name="VoiceService.{i}.VoiceProfile.{i}." ...> ... </object> <object name="VoiceService.{i}.VoiceProfile.{i}.Line.{i}." ...> ... </object>

<description>Information on each active ...</description> ...

<parameter name="FarEndIPAddress" access="readOnly" activeNotify="canDeny"> <description>The IP address of far end VoIP device.</description>

... </object>

</object>

</object>

In document TR-154 TR-069 Data Model XML User Guide (Page 41-46)