C.1 Introduction

Current SDT models are used only in form of <flexContainer>s, and how to design content attribute of <contentInstance> and <timeSeriesInstance> is left to developers. There is no rule for design of content attribute, it means interoperability of content attribute is low. Then SDT can become one of the rules for design of content attribute, and the low interoperability problem will be solved.

The present clause explains how to use SDT as one of the rules for design of content attribute.

There are several benefits of using SDT in content attribute.

First, the resource architecture can be simpler than the one using <flexContainer>s. When using <flexContainer>s, universal attributes are mapped either into attributes of [deviceInfo] under a <node> besides <flexContainer>s, or into custom attributes of [dmDeviceInfo] under a [flexNode] (see Rule 1-8 in clause 6.2.2). Moreover, Action Class and DataPoint Class are the same layer in SDT, but Action Class is mapped to <flexContainer> itself and DataPoint Class is mapped to attributes of <flexContainer> expressing Module class. On the other hand, Using SDT in content attribute means using only one <contentInstance> or <timeSeriesInstance> so the resource architecture is simple.

Relating this benefit, it becomes easy to understand where to write information.

Second, <contentInstance> and <timeSeriesInstance> becomes more interoperable. How to write SDT in content attribute is able to become one of designs of content attribute and the low interoperability of <contentInstance> and <timeSeriesInstance> will be solved.

Third, If useful libraries are prepared, content attribute is able to be expressed in XML/JSON/CBOR with small changes on program.

In addition, tools can generate validator of the data and converter among the supported formats.