TS-0004 Data Representation Proposal Discussion Group: WG3 (PRO) Source: Peter Niblett, IBM, peter_niblett@uk.ibm.com Date: 2014-11-09 Agenda: PRO#14

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 They do not include Representation of Child Resource references The question of Global vs Local element declaration

Announced Resources 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 suggests that the Announced resource type takes the form <xxxxAnnc>, e.g. <ContainerAnnc> No resource-specific XSD (yet) for announced Resource Types Proposal The relevant XSD files will contain Announceable and Announced versions of the resource type We will need new short names for the announced variants The TS-0001 statement about <xxxxAnnc> does not apply The numeric enumeration value for resourceType of <xxxAnnc> will be 1000 more thant the value for the corresponding <xxx>

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 It appears that only 9 resourceTypes (+ the management ones) 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 However the exceptions listed on the previous slide make this tricky…

Options Don’t use inheritance at all. Make every Resource Type declare all its attributes (universal, common, resource - specific) Just use inheritance for the 5 universal attributes, and make the Resources declare the common + resource-specific ones Use inheritance for both universal and common attributes. Options to make this work: Move one or more common attributes into resource-specific section (e.g. stateTag since it is only used by 4 attributes) Sacrifice some of the fidelity of the schemas, e.g. permit a resource schemas to include optional attributes that are not shown as present in TS-0001 Push to get further changes to TS-0001 to remove some of the irregularities Make special cases out of some of the resources, e.g. <CSEBase>, <AE>, <accessControlPolicy>, contentInstance> and <schedule> Construct an XML inheritance scheme to work around the irregular structure of the attributes

“Natural” Inheritance model Resource used by <CSEBase> RegularResource used by <delivery> <eventConfig> <execInstance> <m2mServiceSubscriptionProfile> <mgmtCmd> <pollingChannel> <request> <serviceSubscribedNode> <statsCollect> <statsConfig> <subscription> AnnounceableResource used by <accessControlPolicy> <AE> <container> <contentInstance> <group> <locationPolicy> <mgmtObj> specializations <node> <remoteCSE> <schedule> Assumes stateTag is moved to resource-specific Problem resources shown in black Note: order of attributes won’t be the same as in TS-0001

Problems with previous model <CSEBase> has no parentID Proposal: return xsi:nil <accessControlPolicy>, <contentInstance> and <schedule> have no accessControlPolicyIDs Proposal: special case them with a restriction to have maxOccurs = 0 <AE> has no resourceID Proposal: define a resourceID for it in TS-0001 <contentInstance> has no expirationTime Proposal: change TS-0001 to add it

Alternative Inheritance model Assumes stateTag is moved to resource-specific <accessControlPolicy>, <contentInstance> and <schedule> now use the xxxSubordinateResource types

Problems with alternative model <CSEBase> has no parentID Proposal: return xsi:nil <AE> has no resourceID Proposal: define a resourceID for it in TS-0001 <accessControlPolicy> and <schedule> have expirationTime Proposal: change TS-0001 to add it or special case them with a restriction to have maxOccurs = 0

<mgmtObj> 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 AnnouncebleManagemnt 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 WG2 and WG5.