1. Discussion on XSD implementation conventions (document number PRO-2014-0480R01) Group Name: PRO Source: Wolfgang Granzow, wgranzow,@qti.qualcomm.com Meeting Date: 2014-09-23 Agenda Item: TBD

2. PRO-2014-0480R01 Objective This contribution addresses some open issues about XSD representations: 1)Use of anonymous data types for resource attributes 2)Definition of mgmtLink attribute 2

3. 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

4. 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 resources need to be clearly defined to enable correct mapping from and to the types required in the external DM technology 4

5. 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 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

6. PRO-2014-0480R01 Proposed change of the guidelines 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 may either be added to clause 6.3.2 or defined inside the XSD file for the resource, but if so in the latter case 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 may be used by more than one attribute (either in the same resource or in two different resources) it must should 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. 6

7. PRO-2014-0480R01 XSD for mgmtLink attribute The mgmtLink attribute is used in some specializations of the 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

8. PRO-2014-0480R01 Example: mgmtLink for cmdhPolicy 8

9. PRO-2014-0480R01 XSD for mgmtLink attribute 9 … where data type should be defined as follows in common_types_v1_0_0: This yields to the following representation in a XML instance file of … //x/y/node1/cmdhPolicy1 //x/y/node1/cmdhPolicy1 //x/y/node1/cmdhPolicy1 //x/y/node1/cmdhPolicy1

10. 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