Group: WG3 (PRO)Source: Peter Niblett, IBM, peter_niblett@uk.ibm.comDate: 2014-11-09Agenda: PRO#14

TS-0004 Data Representation Proposal Discussion

Introduction

• These slides discuss approaches to resolve the issues raised in PRO-536 and PRO-537– Announced Resources– Inheritance of “Universal” and “Common attributes”– Management Resources

• There are some other issues under consideration, not included here: – Representation of Child Resource references– The question of Global vs Local element

declaration

1. Announced Resources

© 2014 oneM2M Partners 3

• Announced Resource Types not treated properly in current XML– Need discrete enumeration for announced Resource Types (i.e., unique values in

resourceType attribute)• TS-0001 states that the Announced resource type takes the form <xxxxAnnc>, e.g.

<ContainerAnnc>

– No resource-specific XSD (yet) for announced Resource Types

• Resolution• The enumeration for resourceType will be extended to include the

Announced Types as described In contribution PRO-2014-520.• The value for <xxxAnnc> will be 10000 more than the value for the

corresponding <xxx>, • The relevant XSD files will contain Announceable and Announced versions

of each resource type• We will need new short names for the announced variants

• The TS-0001 statement about <xxxxAnnc> does not apply

2. Attribute issues

• Current inheritance scheme using RegularResource, SubordinateResource and Announceable resources needs revision– Doesn’t match the current version of TS-0001– Doesn’t cope with Announced vs Announceable

Universal/Common Attributes• Following revisions to TS-0001 we now have

– Five “Universal attributes”• resourceType, parentID, creationTime, lastModifiedTime, labels

– Three “Common attributes” relating to Announcement• announceTo, announcedAttribute, link• Only 9 resourceTypes (+ the management specializations) are announceable

– Four other “Common attributes”• resourceID, accessControlPolicyIDs, expirationTime, stateTag

– Exceptions• stateTag is only defined for <container>, <contentInstance>, <delivery> and

<request>• parentID is defined for everything except <CSEBase>• resourceID is defined for everything except <AE> and <CSEBase>• accessControlPolicyIDs is defined for everything except

<accessControlPolicy>, <contentInstance> and <schedule>• expirationTime is defined for everything except <CSEBase> and

<contentInstance>

Inheritance Model• XML Schema allows one complex type to extend

another. The extension type inherits all the XML elements / attributes of its parent.

• Advantages of using this mechanism to represent the universal / common attributes– Avoids having to retype the definitions into each resource– Illustrates the underlying relationship of the type definitions– When you use a tool to generate classes for an OO language

(e.g. xjc to generate Java classes from an XSD) the generated classes can reflect the XML inheritance

Agreements with WG2

• It is ok for the <CSEBase> schema to contain a parentID. – Its value will point to itself

• TS-0001 will be updated to give a resourceID to <AE> and <CSEBase> – In effect this makes resourceID into a Universal

attribute• Confirmed that <contentInstance> does not

have an ExpirationTime

Proposal• Treat resourceID as a universal attribute• Treate stateTag as a resource-specific attribute• Use XML Schema inheritance mechanism to

include universal and the remaining common attributes– Use Schema restriction to exclude expirationTime

from the <contentInstance> resource

Inheritance model

Each resource type extends one of the types listed above as shown in the following tables..

Resource type inheritance - 1Resource Extends

<CSEBase> Resource

<delivery> RegularResource

<eventConfig> RegularResource

<execInstance> RegularResource

<m2mServiceSubscriptionProfile> RegularResource

<mgmtCommand> RegularResource

<pollingChannel> RegularResource

<request> RegularResource

<serviceSubscribedNode> RegularResource

<statsCollect> RegularResource

<statsConfig> RegularResource

<subscription> RegularResource

Resource type inheritance - 2

Resource Extends

<accessControlPolicy> AnnounceableSubordinateResource / AnnouncedSubordinateResource

<AE> AnnounceableResource / AnnouncedResource

<container> AnnounceableResource / AnnouncedResource

<contentInstance> AnnounceableSubordinateResource / AnnouncedSubordinateResource

<group> AnnounceableResource / AnnouncedResource

<locationPolicy> AnnounceableResource / AnnouncedResource

<mgmtObj> specializations AnnounceableResource / AnnouncedResource

<node> AnnounceableResource / AnnouncedResource

<remoteCSE> AnnounceableResource / AnnouncedResource

<schedule> AnnounceableSubordinateResource / AnnouncedSubordinateResource

3 <mgmtObj>

© 2014 oneM2M Partners 12

• Current schema design does not serialize attributes and child resources properly for [specializations] of <mgmtObj>– Common attributes are followed by <mgmtObj> attributes and child

resources, and then specialization-specific attributes (or so-called [objectAttribute])

– This could be fixed by introducing AnnouncebleManagement and AnnouncedManagement types

• [specializations] do not have resourceType=mgmtObj in XSD– Each [specialization] is treated as a resource-specific type declaration

and has a discrete element name (which is currently equivalent to resourceType)

– Need resolution of this issue with WG5.

<mgmtObj> in TS-0001<mgmtObj>

1mgmtDefinition

0..1 (L)mgmtLink

0..1 (L)[objectAttribute]

0..1description

<subscription>0..n

0..1 (L)objectIDs

0..1 (L)objectPaths

Has resourceType of <mgmtObj> regardless of the specialization

Specifies the type of <mgmtObj> resource e.g. software, firmware, memory.

This is where the attributes specific to this specialization go.

Used by cmdh resources to point to other cmdh resources.

No other child types are permitted.

XML Schema Representation

• Option 1– Define a MgmtResource complex type containing mgmtDefinition,

objectIds, objectPaths, mgmtLink and description– Each specialization XSD file declares an element / complex type for

that specialization, inheriting from MgmtResource and adding the specialization-specific attributes

– The resource root element will show the specialization, although we could still show mgmtObj (13) as its resourceType

• Option 2– Declare a single <mgmtObj> element / complex type containing

mgmtDefinition, objectIds, objectPaths, mgmtLink and description– This <mgmtObj> also contains a loosely typed XSD substitution group

head element called [objectAttribute] with unbounded maxOccurs– Each specialization XSD file includes a substitution group to replace

the [objectAttribute]

Option 1

New types for use by Management specializations

Child Resources

• Recent changes to TS-0001 mean that we now have to be able to return in-lined child resources as well as URIs to child resources

• We need to allow the in-lining of both <xxx> and <xxxAnnc> children, since TS-0001 allows users to add children to an Announced Resource that are not children of the original resource.