Discussion on XSD implementation conventions

(document number PRO-2014-0480R01)

Group Name: PROSource: Wolfgang Granzow, wgranzow,@qti.qualcomm.comMeeting Date: 2014-09-23Agenda Item: TBD

PRO-2014-0480R01

Objective

• This contribution addresses some open issues about XSD representations:1) Use of anonymous data types for resource

attributes2) Definition of mgmtLink attribute

2

PRO-2014-0480R01

Current guidelines for declaration of resource attribute data types

6) Each resource attribute shall be declared to use one of the following data types:a. A data type listed in clause 6.3.1 or 6.3.2. b. A list of one of the data types listed in clause 6.3.1 or 6.3.2. If the list type is not already

included in 6.3.2 it may be defined inside the XSD file for the resource, but if so it must be defined as an anonymous type in the attribute declaration itself.

c. A data type derived by restriction from one of the types listed in clause 6.3.1 or 6.3.2. This may be defined inside the XSD file for the resource, but if so it must be defined as an anonymous type in the attribute declaration itself.

d. An anonymous complex type defined as part of the attribute declaration (inside the XSD file for the resource). The complex type should only be composed out of the types listed in clause 6.3.1 or 6.3.2.

7) If a data type is used by more than one attribute (either in the same resource or in two different resources) it must be included in 6.3.2, and referenced by each attribute that uses it. Options 6b, 6c, 6d should only be used in cases where the type is only used by one attribute.

3

PRO-2014-0480R01

Use of anonymous types• There is no obvious reason why some resource attributes

should be assigned an explicit data type name (in the xs: or m2m: name space) while others would be assigned an anonymous data type

• Assignment of explicit data type names to all resource attributes keep the tables in clause 7.3 consistent and make it more easy to identify the data type in the XSD files– Especially the data types used in attributes of <mgmtObj>

resources need to be clearly defined to enable correct mapping from and to the types required in the external DM technology

4

PRO-2014-0480R01

Issue with itemType attribute• 6d): data types required in the definition of an anonymous

complex type of a resource attribute cannot always be defined as an anonymous data type itself– Example: privileges attribute in an <accessControlPolicy> resource

requires a data type representing a list of IP addresses• In a xs:list declaration, the data type referred to by the itemType attribute

cannot be defined as anonymous type:

5

<simpleType> <xs:list itemType='ipv4'/></simpleType>

PRO-2014-0480R01

Proposed change of the guidelines

6

PRO-2014-0480R01

XSD for mgmtLink attribute

• The mgmtLink attribute is used in some specializations of the <mgmtObj> resource– currently only in resources related to CMDH policy

• It is most appropriate to represent the mgmtLink attribute in the same way as other child resources as follows of data type m2m:mgmtLinkRef

7

PRO-2014-0480R01

Example: mgmtLink for cmdhPolicy

8

<xs:element name="cmdhPolicy" > <xs:complexType> <xs:complexContent> <!-- Inherit Common Attributes from regularResourceType --> <xs:extension base="m2m:regularResourceType"> <xs:sequence> <!-- Resource Specific Attributes --> <xs:element name="mgmtDefinition" type="m2m:mgmtDefinition" fixed="cmdhPolicy" /> <xs:element name="objectID" type="xs:string" minOccurs="0" maxOccurs="1" /> <xs:element name="objectPath" type="xs:string" minOccurs="0" maxOccurs="1" /> <xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="1" /> <xs:element name="name" type="xs:string" minOccurs="1" maxOccurs="1" /> <!-- 1 mgmtLink to resource of type cmdhDefaults, at least 1 mgmtLink to cmdhLimits, at least 1 mgmtLink to cmdhNetworkAccessRules, at least 1 mgmtLink to cmdhBuffer required--> <xs:element name="mgmtLink" type="m2m:mgmtLinkRef" minOccurs="4" maxOccurs="unbounded" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element>

PRO-2014-0480R01

XSD for mgmtLink attribute

9

… where data type should be defined as follows in common_types_v1_0_0:<xs:complexType name="mgmtLinkRef"> <xs:simpleContent> <xs:extension base="xs:anyURI"> <xs:attribute name="name" type="xs:string" use='required'/> <xs:attribute name="type" type="m2m:mgmtDefinition" use='required'/> </xs:extension> </xs:simpleContent> </xs:complexType>

This yields to the following representation in a XML instance file of </m2m:cmdhPolicy> … <mgmtLink name="cmdhDefaults1" type="cmdhDefaults">//x/y/node1/cmdhPolicy1</mgmtLink> <mgmtLink name="cmdhLimit10" type="cmdhLimits">//x/y/node1/cmdhPolicy1</mgmtLink> <mgmtLink name="cmdhNwAccRules1“ type="cmdhNwAccRules">//x/y/node1/cmdhPolicy1</mgmtLink> <mgmtLink name="cmdhBuffer2" type="cmdhBuffer">//x/y/node1/cmdhPolicy1</mgmtLink> </m2m:cmdhPolicy>

PRO-2014-0480R01

XSD for mgmtLink attribute

• It should be noted however that the correct multiplicity (cardinality) of the various mgmtLink types in a XML resource instance cannot be validated

• This issue also exists for ordinary child resources

• Proposal: include text into TS-0004 that mgmtLink is handled the same way as the childResource attribute

10