ISO/IEC 29341-4-4:2008

ISO/IEC 29341-4-4
Edition 1.0 2008-11
INTERNATIONAL
STANDARD
Information technology – UPnP Device Architecture –
Part 4-4: Audio Video Device Control Protocol –
Level 2 – Audio Video Data Structures

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about ISO/IEC copyright or have an enquiry about obtaining additional rights to this
publication, please contact the address below or your local IEC member National Committee for further information.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
ISO/IEC 29341-4-4
Edition 1.0 2008-11
INTERNATIONAL
STANDARD
Information technology – UPnP Device Architecture –
Part 4-4: Audio Video Device Control Protocol –
Level 2 – Audio Video Data Structures
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
K
ICS 35.200 ISBN 978-2-88910-851-0

– 2 – 29341-4-4 © ISO/IEC:2008(E)
CONTENTS
FOREWORD .3
ORIGINAL UPNP DOCUMENTS (informative) .5
1 Introduction .7
1.1 Notation .7
1.1.1 Data Types.8
1.1.2 Strings Embedded in Other Strings.8
1.1.3 Extended Backus-Naur Form.8
1.2 Derived Data Types.9
1.2.1 Comma Separated Value (CSV) Lists .9
1.3 Management of XML Namespaces in Standardized DCPs.10
1.3.1 Namespace Prefix Requirements .13
1.3.2 Namespace Names, Namespace Versioning and Schema Versioning.14
1.3.3 Namespace Usage Examples.15
1.4 Vendor-defined Extensions .15
1.5 References .16
2 Overview .19
3 AV Datastructure Template .20
4 AV Datastructure Schema .26

LIST OF TABLES
Table 1-1: EBNF Operators .9
Table 1-2: CSV Examples .10
Table 1-3: Namespace Definitions.12
Table 1-4: Schema-related Information .13
Table 1-5: Default Namespaces for the AV Specifications.14

LIST OF FIGURES
Figure 1: Typical Usage of AVDT .19

29341-4-4 © ISO/IEC:2008(E) – 3 –
INFORMATION TECHNOLOGY –
UPNP DEVICE ARCHITECTURE –
Part 4-4: Audio Video Device Control Protocol – Level 2 –
Audio Video Data Structures
FOREWORD
1) ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) form
the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards. Their preparation is entrusted to technical
committees; any ISO and IEC member body interested in the subject dealt with may participate in this
preparatory work. International governmental and non-governmental organizations liaising with ISO and IEC
also participate in this preparation.
2) In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC
1. Draft International Standards adopted by the joint technical committee are circulated to national bodies for
voting. Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
3) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested IEC and ISO member bodies.
4) IEC, ISO and ISO/IEC publications have the form of recommendations for international use and are accepted
by IEC and ISO member bodies in that sense. While all reasonable efforts are made to ensure that the
technical content of IEC, ISO and ISO/IEC publications is accurate, IEC or ISO cannot be held responsible for
the way in which they are used or for any misinterpretation by any end user.
5) In order to promote international uniformity, IEC and ISO member bodies undertake to apply IEC, ISO and
ISO/IEC publications transparently to the maximum extent possible in their national and regional publications.
Any divergence between any ISO/IEC publication and the corresponding national or regional publication should
be clearly indicated in the latter.
6) ISO and IEC provide no marking procedure to indicate their approval and cannot be rendered responsible for
any equipment declared to be in conformity with an ISO/IEC publication.
7) All users should ensure that they have the latest edition of this publication.
8) No liability shall attach to IEC or ISO or its directors, employees, servants or agents including individual
experts and members of their technical committees and IEC or ISO member bodies for any personal injury,
property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including
legal fees) and expenses arising out of the publication of, use of, or reliance upon, this ISO/IEC publication or
any other IEC, ISO or ISO/IEC publications.
9) Attention is drawn to the normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
IEC and ISO draw attention to the fact that it is claimed that compliance with this document may involve the use of
patents as indicated below.
ISO and IEC take no position concerning the evidence, validity and scope of the putative patent rights. The holders
of the putative patent rights have assured IEC and ISO that they are willing to negotiate free licences or licences
under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect,
the statements of the holders of the putative patent rights are registered with IEC and ISO.
Intel Corporation has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Intel Corporation
Standards Licensing Department
5200 NE Elam Young Parkway
MS: JFS-98
USA – Hillsboro, Oregon 97124
Microsoft Corporation has informed IEC and ISO that it has patent applications or granted patents as listed below:

– 4 – 29341-4-4 © ISO/IEC:2008(E)
6101499 / US; 6687755 / US; 6910068 / US; 7130895 / US; 6725281 / US; 7089307 / US; 7069312 / US;
10/783 524 /US
Information may be obtained from:
Microsoft Corporation
One Microsoft Way
USA – Redmond WA 98052
Philips International B.V. has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Philips International B.V. – IP&S
High Tech campus, building 44 3A21
NL – 5656 Eindhoven
NXP B.V. (NL) has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
NXP B.V. (NL)
High Tech campus 60
NL – 5656 AG Eindhoven
Matsushita Electric Industrial Co. Ltd. has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Matsushita Electric Industrial Co. Ltd.
1-3-7 Shiromi, Chuoh-ku
JP – Osaka 540-6139
Hewlett Packard Company has informed IEC and ISO that it has patent applications or granted patents as listed
below:
5 956 487 / US; 6 170 007 / US; 6 139 177 / US; 6 529 936 / US; 6 470 339 / US; 6 571 388 / US; 6 205
466 / US
Information may be obtained from:
Hewlett Packard Company
1501 Page Mill Road
USA – Palo Alto, CA 94304
Samsung Electronics Co. Ltd. has informed IEC and ISO that it has patent applications or granted patents.
Information may be obtained from:
Digital Media Business, Samsung Electronics Co. Ltd.
416 Maetan-3 Dong, Yeongtang-Gu,
KR – Suwon City 443-742
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights
other than those identified above. IEC and ISO shall not be held responsible for identifying any or all such patent
rights.
ISO/IEC 29341-4-4 was prepared by UPnP Implementers Corporation and adopted, under the PAS procedure, by
joint technical committee ISO/IEC JTC 1, Information technology, in parallel with its approval by national bodies of
ISO and IEC.
The list of all currently available parts of the ISO/IEC 29341 series, under the general title Universal plug and play
(UPnP) architecture, can be found on the IEC web site.
This International Standard has been approved by vote of the member bodies, and the voting results may be
obtained from the address given on the second title page.

29341-4-4 © ISO/IEC:2008(E) – 5 –
ORIGINAL UPNP DOCUMENTS
(informative)
Reference may be made in this document to original UPnP documents. These references are retained in order to
maintain consistency between the specifications as published by ISO/IEC and by UPnP Implementers Corporation.
The following table indicates the original UPnP document titles and the corresponding part of ISO/IEC 29341:
UPnP Document Title ISO/IEC 29341 Part
UPnP Device Architecture 1.0 ISO/IEC 29341-1
UPnP Basic:1 Device ISO/IEC 29341-2
UPnP AV Architecture:1 ISO/IEC 29341-3-1
UPnP MediaRenderer:1 Device ISO/IEC 29341-3-2
UPnP MediaServer:1 Device ISO/IEC 29341-3-3
UPnP AVTransport:1 Service ISO/IEC 29341-3-10
UPnP ConnectionManager:1 Service ISO/IEC 29341-3-11
UPnP ContentDirectory:1 Service ISO/IEC 29341-3-12
UPnP RenderingControl:1 Service ISO/IEC 29341-3-13
UPnP MediaRenderer:2 Device ISO/IEC 29341-4-2
UPnP MediaServer:2 Device ISO/IEC 29341-4-3
UPnP AV Datastructure Template:1 ISO/IEC 29341-4-4
UPnP AVTransport:2 Service ISO/IEC 29341-4-10
UPnP ConnectionManager:2 Service ISO/IEC 29341-4-11
UPnP ContentDirectory:2 Service ISO/IEC 29341-4-12
UPnP RenderingControl:2 Service ISO/IEC 29341-4-13
UPnP ScheduledRecording:1 ISO/IEC 29341-4-14
UPnP DigitalSecurityCamera:1 Device ISO/IEC 29341-5-1
UPnP DigitalSecurityCameraMotionImage:1 Service ISO/IEC 29341-5-10
UPnP DigitalSecurityCameraSettings:1 Service ISO/IEC 29341-5-11
UPnP DigitalSecurityCameraStillImage:1 Service ISO/IEC 29341-5-12
UPnP HVAC_System:1 Device ISO/IEC 29341-6-1
UPnP HVAC_ZoneThermostat:1 Device ISO/IEC 29341-6-2
UPnP ControlValve:1 Service ISO/IEC 29341-6-10
UPnP HVAC_FanOperatingMode:1 Service ISO/IEC 29341-6-11
UPnP FanSpeed:1 Service ISO/IEC 29341-6-12
UPnP HouseStatus:1 Service ISO/IEC 29341-6-13
UPnP HVAC_SetpointSchedule:1 Service ISO/IEC 29341-6-14
UPnP TemperatureSensor:1 Service ISO/IEC 29341-6-15
UPnP TemperatureSetpoint:1 Service ISO/IEC 29341-6-16
UPnP HVAC_UserOperatingMode:1 Service ISO/IEC 29341-6-17
UPnP BinaryLight:1 Device ISO/IEC 29341-7-1
UPnP DimmableLight:1 Device ISO/IEC 29341-7-2
UPnP Dimming:1 Service ISO/IEC 29341-7-10
UPnP SwitchPower:1 Service ISO/IEC 29341-7-11
UPnP InternetGatewayDevice:1 Device ISO/IEC 29341-8-1
UPnP LANDevice:1 Device ISO/IEC 29341-8-2
UPnP WANDevice:1 Device ISO/IEC 29341-8-3
UPnP WANConnectionDevice:1 Device ISO/IEC 29341-8-4
UPnP WLANAccessPointDevice:1 Device ISO/IEC 29341-8-5
UPnP LANHostConfigManagement:1 Service ISO/IEC 29341-8-10
UPnP Layer3Forwarding:1 Service ISO/IEC 29341-8-11
UPnP LinkAuthentication:1 Service ISO/IEC 29341-8-12
UPnP RadiusClient:1 Service ISO/IEC 29341-8-13
UPnP WANCableLinkConfig:1 Service ISO/IEC 29341-8-14
UPnP WANCommonInterfaceConfig:1 Service ISO/IEC 29341-8-15
UPnP WANDSLLinkConfig:1 Service ISO/IEC 29341-8-16
UPnP WANEthernetLinkConfig:1 Service ISO/IEC 29341-8-17
UPnP WANIPConnection:1 Service ISO/IEC 29341-8-18
UPnP WANPOTSLinkConfig:1 Service ISO/IEC 29341-8-19
UPnP WANPPPConnection:1 Service ISO/IEC 29341-8-20
UPnP WLANConfiguration:1 Service ISO/IEC 29341-8-21
UPnP Printer:1 Device ISO/IEC 29341-9-1
UPnP Scanner:1.0 Device ISO/IEC 29341-9-2
UPnP ExternalActivity:1 Service ISO/IEC 29341-9-10
UPnP Feeder:1.0 Service ISO/IEC 29341-9-11
UPnP PrintBasic:1 Service ISO/IEC 29341-9-12
UPnP Scan:1 Service ISO/IEC 29341-9-13
UPnP QoS Architecture:1.0 ISO/IEC 29341-10-1
UPnP QosDevice:1 Service ISO/IEC 29341-10-10
UPnP QosManager:1 Service ISO/IEC 29341-10-11
UPnP QosPolicyHolder:1 Service ISO/IEC 29341-10-12
UPnP QoS Architecture:2 ISO/IEC 29341-11-1
UPnP QOS v2 Schema Files ISO/IEC 29341-11-2

– 6 – 29341-4-4 © ISO/IEC:2008(E)
UPnP Document Title ISO/IEC 29341 Part
UPnP QosDevice:2 Service ISO/IEC 29341-11-10
UPnP QosManager:2 Service ISO/IEC 29341-11-11
UPnP QosPolicyHolder:2 Service ISO/IEC 29341-11-12
UPnP RemoteUIClientDevice:1 Device ISO/IEC 29341-12-1
UPnP RemoteUIServerDevice:1 Device ISO/IEC 29341-12-2
UPnP RemoteUIClient:1 Service ISO/IEC 29341-12-10
UPnP RemoteUIServer:1 Service ISO/IEC 29341-12-11
UPnP DeviceSecurity:1 Service ISO/IEC 29341-13-10
UPnP SecurityConsole:1 Service ISO/IEC 29341-13-11

29341-4-4 © ISO/IEC:2008(E) – 7 –
1 Introduction
This document defines the layout of the AV Datastructure Template (AVDT) XML document. An AVDT
document describes the format requirements and restrictions of various data structures used within the UPnP AV
specifications. Although these data structures are defined very precisely in the appropriate service specification,
in most cases, each data structure definition allows for a certain degree of variation in order to accommodate
differences between individual devices.
The purpose of an AVDT document is to enable each device to describe (at run-time) its particular variation of
these AV data structures. AVDT documents allow users of AV data structures (e.g. UPnP control points) to
reduce the number of instances of those data structures that comply with the service specification but are not
compatible with the device’s particular capabilities. The ultimate goal of an AVDT document is to reduce those
error conditions that are caused by control points creating instances of a data structure that exceed the static
(known) capabilities of the device. Unfortunately, the AVDT mechanism will never eliminate all preventable
error conditions, but it will help to reduce them by giving the client more information about the device’s
particular capabilities.
As described above, an AVDT document is a machine readable, implementation-specific variant of an AV data
structure defined by one of the UPnP AV specifications. For a given device, each instance of that data structure
must conform to both the specification definition AND the device’s AVDT definition of that data structure.
Ironically, an AVDT document is both a more-restrictive and more-permissive variant of the specification
definition. AVDT documents are more restrictive because they limit certain aspects of the data structure (e.g.
such as the allowed values for each field) that are otherwise permitted by the specification definition. However,
due to limitations of the AVDT constructs, it is simply not possible to express some of the more intricate
requirements defined by the specification (e.g. subtle interdependencies between data structure fields).
Consequently, instances of a data structure that comply with a given AVDT description may not fully comply
with all of the requirements defined in the specification.
The types of data structures that can be described by an AVDT document represent a (non-hierarchitical) set of
named property values. The set of allowed property names and their allowed values for a given data structure are
defined by one of the UPnP AV specifications. Individual instances of these data structures are manifested via an
XML document whose elements and attributes correspond to the set of named properties. In other words, within
the XML document that corresponds to a given instance of a certain data structure, each XML element and
attribute contains the value of a specific named property.
An AVDT document is conceptually similar to an XML schema in that both entities identify the XML elements
and attributes that appear in any given document instance. Additionally, both AVDT documents and XML
schemas identify the allowed values that are permitted for each element and/or attribute which corresponds to a
specific property. However, unlike an XML schema, an AVDT document can also identify certain dependencies
between two or more properties. For example, the set of allowed values of one property may depend on the actual
value of another property. This type of interrelationship is difficult to represent using an XML schema. Hence,
the AVDTdocument structure is needed.
1.1 Notation
• In this document, features are described as Required, Recommended, or Optional as follows:
The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,”
“SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this specification are to be
interpreted as described in [RFC 2119].
In addition, the following keywords are used in this specification:
PROHIBITED – The definition or behavior is an absolute prohibition of this specification. Opposite of
REQUIRED.
CONDITIONALLY REQUIRED – The definition or behavior depends on a condition. If the specified
condition is met, then the definition or behavior is REQUIRED, otherwise it is PROHIBITED.
CONDITIONALLY OPTIONAL – The definition or behavior depends on a condition. If the specified
condition is met, then the definition or behavior is OPTIONAL, otherwise it is PROHIBITED.

– 8 – 29341-4-4 © ISO/IEC:2008(E)
These keywords are thus capitalized when used to unambiguously specify requirements over protocol
and application features and behavior that affect the interoperability and security of implementations.
When these words are not capitalized, they are meant in their natural-language sense.
• Strings that are to be taken literally are enclosed in “double quotes”.
• Words that are emphasized are printed in italic.
• Keywords that are defined by the UPnP AV Working Committee are printed using the forum character
style.
• Keywords that are defined by the UPnP Device Architecture are printed using the arch character style.
• A double colon delimiter, “::”, signifies a hierarchical parent-child (parent::child) relationship between
the two objects separated by the double colon. This delimiter is used in multiple contexts, for example:
Service::Action(), Action()::Argument, parentProperty::childProperty.
1.1.1 Data Types
This specification uses data type definitions from two different sources. The UPnP Device Architecture defined
data types are used to define state variable and action argument data types [DEVICE]. The XML Schema
namespace is used to define property data types [XML SCHEMA-2].
For UPnP Device Architecture defined Boolean data types, it is strongly RECOMMENDED to use the value “0”
for false, and the value “1” for true. However, when used as input arguments, the values “false”, “no”, “true”,
“yes” may also be encountered and MUST be accepted. Nevertheless, it is strongly RECOMMENDED that all
” and “1”.
state variables and output arguments be represented as “0
For XML Schema defined Boolean data types, it is strongly RECOMMENDED to use the value “0” for false,
and the value “1” for true. However, when used as input properties, the values “false”, “true” may also be
encountered and MUST be accepted. Nevertheless, it is strongly RECOMMENDED that all properties be
represented as “0” and “1”.
1.1.2 Strings Embedded in Other Strings
Some string variables and arguments described in this document contain substrings that MUST be independently
identifiable and extractable for other processing. This requires the definition of appropriate substring delimiters
and an escaping mechanism so that these delimiters can also appear as ordinary characters in the string and/or its
independent substrings. This document uses embedded strings in two contexts – Comma Separated Value (CSV)
lists (see Section 1.2.1, “Comma Separated Value (CSV) Lists”) and property values in search criteria strings.
Escaping conventions use the backslash character, “\” (character code U+005C), as follows:
a. Backslash (“\”) is represented as “\\” in both contexts.
b. Comma (“,”) is
1. represented as “\,” in individual substring entries in CSV lists
2. not escaped in search strings
c. Double quote (“””) is
1. not escaped in CSV lists
2. not escaped in search strings when it appears as the start or end delimiter of a property value
3. represented as “\”” in search strings when it appears as a character that is part of the property value
1.1.3 Extended Backus-Naur Form
Extended Backus-Naur Form is used in this document for a formal syntax description of certain constructs. The
usage here is according to the reference [EBNF].
1.1.3.1 Typographic conventions for EBNF
Non-terminal symbols are unquoted sequences of characters from the set of English upper and lower case
letters, the digits “0” through “9”, and the hyphen (“-”). Character sequences between 'single quotes' are
terminal strings and MUST appear literally in valid strings. Character sequences between (*comment
delimiters*) are English language definitions or supplementary explanations of their associated symbols.

29341-4-4 © ISO/IEC:2008(E) – 9 –
White space in the EBNF is used to separate elements of the EBNF, not to represent white space in valid strings.
White space usage in valid strings is described explicitly in the EBNF. Finally, the EBNF uses the following
operators:
Table 1-1: EBNF Operators
Operator Semantics
::=
definition – the non-terminal symbol on the left is defined by one or more alternative
sequences of terminals and/or non-terminals to its right.
|
alternative separator – separates sequences on the right that are independently allowed
definitions for the non-terminal on the left.
*
null repetition – means the expression to its left MAY occur zero or more times.
+
non-null repetition – means the expression to its left MUST occur at least once and MAY
occur more times.
[ ]
optional – the expression between the brackets is optional.
( )
grouping – groups the expressions between the parentheses.
-
character range – represents all characters between the left and right character operands
inclusively.
1.2 Derived Data Types
This section defines a derived data type that is represented as a string data type with special syntax. This
specification uses string data type definitions that originate from two different sources. The UPnP Device
Architecture defined string data type is used to define state variable and action argument string data types. The
XML Schema namespace is used to define property xsd:string data types. The following definition applies to
both string data types.
1.2.1 Comma Separated Value (CSV) Lists
The UPnP AV services use state variables, action arguments and properties that represent lists – or one-
dimensional arrays – of values. The UPnP Device Architecture, Version 1.0 [DEVICE], does not provide for
either an array type or a list type, so a list type is defined here. Lists MAY either be homogeneous (all values are
the same type) or heterogeneous (values of different types are allowed). Lists MAY also consist of repeated
occurrences of homogeneous or heterogeneous subsequences, all of which have the same syntax and semantics
(same number of values, same value types and in the same order). The data type of a homogeneous list is string
or xsd:string and denoted by CSV (x), where x is the type of the individual values. The data type of a
heterogeneous list is also string or xsd:string and denoted by CSV (x, y, z), where x, y and z are the types of the
individual values. If the number of values in the heterogeneous list is too large to show each type individually,
that variable type is represented as CSV (heterogeneous), and the variable description includes additional
information as to the expected sequence of values appearing in the list and their corresponding types. The data
type of a repeated subsequence list is string or xsd:string and denoted by CSV ({x, y, z}), where x, y and z are the
types of the individual values in the subsequence and the subsequence MAY be repeated zero or more times.
• A list is represented as a string type (for state variables and action arguments) or xsd:string type (for
properties).
• Commas separate values within a list.
• Integer values are represented in CSVs with the same syntax as the integer data type specified in
[DEVICE] (that is: optional leading sign, optional leading zeroes, numeric ASCII)
• Boolean values are represented in state variable and action argument CSVs as either “0” for false or “1”
for true. These values are a subset of the defined Boolean data type values specified in [DEVICE]: 0,
false, no, 1, true, yes.
• Boolean values are represented in property CSVs as either “0” for false or “1” for true. These values are
a subset of the defined Boolean data type values specified in [XML SCHEMA-2]: 0, false, 1, true.
• Escaping conventions for the comma and backslash characters are defined in Section 1.1.2, “Strings
Embedded in Other Strings”.
– 10 – 29341-4-4 © ISO/IEC:2008(E)
• White space before, after, or interior to any numeric data type is not allowed.
• White space before, after, or interior to any other data type is part of the value.
Table 1-2: CSV Examples
Type refinement Value Comments
of string
CSV (string) or “+artist,-date” List of 2 property sort
CSV (xsd:string) criteria.
CSV (int) or “1,-5,006,0,+7” List of 5 integers.
CSV (xsd:integer)
CSV (boolean) or “0,1,1,0” List of 4 booleans
CSV (xsd:Boolean)
CSV (string) or “Smith\, Fred,Jones\, Davey” List of 2 names,
CSV (xsd:string) “Smith, Fred” and
“Jones, Davey”
CSV (i4,string,ui2) “-29837,  string with leading blanks,0” Note that the second value
or CSV (xsd:int, is “  string with leading
xsd:string, blanks”
xsd:unsignedShort)
CSV (i4) or “3, 4” Illegal CSV. White space
CSV (xsd:int) is not allowed as part of
an integer value.
CSV (string) or “,,” List of 3 empty string
CSV (xsd:string) values
CSV (heterogeneous) “Alice,Marketing,5,Sue,R&D,21,Dave,Finance,7” List of unspecified
number of people and
associated attributes. Each
person is described by 3
elements: a name string, a
department string and
years-of-service ui2 or a
name xsd:string, a
department xsd:string and
years-of-service
xsd:unsignedShort.
1.3 Management of XML Namespaces in Standardized DCPs
UPnP specifications make extensive use of XML namespaces. This allows separate DCPs, and even separate
components of an individual DCP, to be designed independently and still avoid name collisions when they share
XML documents. Every name in an XML document belongs to exactly one namespace. In documents, XML
names appear in one of two forms: qualified or unqualified. An unqualified name (or no-colon-name) contains no
colon ( “:”) characters. An unqualified name belongs to the document’s default namespace. A qualified name is
two no-colon-names separated by one colon character. The no-colon-name before the colon is the qualified
name’s namespace prefix, the no-colon-name after the colon is the qualified name’s “local” name (meaning local
to the namespace identified by the namespace prefix). Similarly, the unqualified name is a local name in the
default namespace.
The formal name of a namespace is a URI. The namespace prefix used in an XML document is not the name of
the namespace. The namespace name is, or should be, globally unique. It has a single definition that is accessible
to anyone who uses the namespace. It has the same meaning anywhere that it is used, both inside and outside
XML documents. The namespace prefix, however, in formal XML usage, is defined only in an XML document.
It must be locally unique to the document. Any valid XML no-colon-name may be used. And, in formal XML
usage, no two XML documents are ever required to use the same namespace prefix to refer to the same
namespace. The creation and use of the namespace prefix was standardized by the W3C XML Committee in

29341-4-4 © ISO/IEC:2008(E) – 11 –
[XML-NMSP] strictly as a convenient local shorthand replacement for the full URI name of a namespace in
individual documents.
All AV object properties are represented in XML by element and attribute names, therefore, all property names
belong to an XML namespace.
For the same reason that namespace prefixes are convenient in XML documents, it is convenient in specification
text to refer to namespaces using a namespace prefix. Therefore, this specification declares a “standard” prefix
for all XML namespaces used herein. In addition, this specification expands the scope where these prefixes have
meaning, beyond a single XML document, to all of its text, XML examples, and certain string-valued properties.
This expansion of scope does not supercede XML rules for usage in documents, it only augments and
complements them in important contexts that are out-of-scope for the XML specifications.
All of the namespaces used in this specification are listed in the Tables “Namespace Definitions” and “Schema-
related Information”. For each such namespace, Table 1-3, “Namespace Definitions” gives a brief description of
it, its name (a URI) and its defined “standard” prefix name. Some namespaces included in these tables are not
directly used or referenced in this document. They are included for completeness to accommodate those
situations where this specification is used in conjunction with other UPnP specifications to construct a complete
system of devices and services. The individual specifications in such collections all use the same standard prefix.
The standard prefixes are also used in Table 1-4, “Schema-related Information”, to cross-reference additional
namespace information. This second table includes each namespace’s valid XML document root elements (if
any), its schema file name, versioning information (to be discussed in more detail below), and links to the entries
in the Reference section for its associated schema.
The normative definitions for these namespaces are the documents referenced in Table 1-3. The schemas are
designed to support these definitions for both human understanding and as test tools. However, limitations of the
XML Schema language itself make it difficult for the UPnP-defined schemas to accurately represent all details of
the namespace definitions. As a result, the schemas will validate many XML documents that are not valid
according to the specifications.
The Working Committee expects to continue refining these schemas after specification release to reduce the
number of documents that are validated by the schemas while violating the specifications, but the schemas will
still be informative, supporting documents. Some schemas might become normative in future versions of the
specifications.
– 12 – 29341-4-4 © ISO/IEC:2008(E)
Table 1-3: Namespace Definitions
Standard
Name- Normative Definition
space Document
Prefix Namespace Name Namespace Description Reference
AV Working Committee defined namespaces
av: urn:schemas-upnp-org:av:av Common data types for use in AV [AV-XSD]
schemas
avs: urn:schemas-upnp-org:av:avs Common structures for use in AV [AVS-XSD]
schemas
avdt: urn:schemas-upnp-org:av:avdt Datastructure Template [AVDT]
avt-event: urn:schemas-upnp-org:metadata-1-0/AVT/ Evented LastChange state variable for [AVT]
AVTransport
didl-lite: urn:schemas-upnp-org:metadata-1-0/DIDL- Structure and metadata for [CDS]
Lite/ ContentDirectory
rcs-event: urn:schemas-upnp-org:metadata-1-0/RCS/ Evented LastChange state variable for [RCS]
RenderingControl
srs: urn:schemas-upnp-org:av:srs Metadata and structure for [SRS]
ScheduledRecording
srs-event: urn:schemas-upnp-org:av:srs-event Evented LastChange state variable for [SRS]
ScheduledRecording
upnp: urn:schemas-upnp-org:metadata-1-0/upnp/ Metadata for ContentDirectory [CDS]
Externally defined namespaces
dc: http://purl.org/dc/elements/1.1/ Dublin Core [DC-TERMS]
xsd: http://www.w3.org/2001/XMLSchema XML Schema Language 1.0 [XML SCHEMA-1]
[XML SCHEMA-2]
xsi: http://www.w3.org/2001/XMLSchema- XML Schema Instance Document schema Sections 2.6 & 3.2.7 of
instance [XML SCHEMA-1]
xml: http://www.w3.org/XML/1998/namespace The “xml:” Namespace [XML-NS]

29341-4-4 © ISO/IEC:2008(E) – 13 –
Table 1-4: Schema-related Information
Standard Relative URI and File
Name
Name-
● Form 1
space
Prefix ● Form 2 Valid Root Element(s) Schema Reference
AV Working Committee Defined Namespaces
av: n/a [AV-XSD]
• av-vn-yyyymmdd.xsd
• av-vn.xsd

avs: [AVS-XSD]
• avs-vn-yyyymmdd.xsd

• avs-vn.xsd

avdt: • avdt-vn-yyyymmdd.xsd [AVDT]
• avdt-vn.xsd

avt-event: [AVT-EVENT-XSD]
• avt-event-vn-yyyymmdd.xsd
• avt-event-vn.xsd

didl-lite: [DIDL-LITE-XSD]
• didl-lite-vn-yyyymmdd.xsd
• didl-lite-vn.xsd

rcs-event: • rcs-event-vn-yyyymmdd.xsd [RCS-EVENT-XSD]
• rcs-event-vn.xsd

srs: [SRS-XSD]
• srs-vn-yyyymmdd.xsd
• srs-vn.xsd

srs-event: • srs-event-vn-yyyymmdd.xsd [SRS-EVENT-XSD]
• srs-event-vn.xsd
upnp: n/a [UPNP-XSD]
• upnp-vn-yyyymmdd.xsd
• upnp-vn.xsd
Externally Defined Namespaces
dc: Absolute URL: http://dublincore.org/schemas/xmls/simpledc20021212.xsd [DC-XSD]


xsd: n/a [XMLSCHEMA-XSD]
xsi: n/a n/a
xml: n/a [XML-XSD]
1.3.1 Namespace Prefix Requirements
There are many occurrences in this specification of string data types that contain XML names (property names).
These XML names in strings will not be processed under namespace-aware conditions. Therefore, all
occurrences in instance documents of XML names in strings MUST use the standard namespace prefixes as
declared in Table 1-3. In order to properly process the XML documents described herein, control points and
devices MUST use namespace-aware XML processors [XML-NMSP] for both reading and writing. As allowed
by [XML-NMSP], the namespace prefixes used in an instance document are at the sole discretion of the
document creator. Therefore, the declared prefix for a namespace in a document MAY be different from the
standard prefix. All devices MUST be able to correctly process any valid XML instance document, even when it
uses a non-standard prefix for ordinary XML names. It is strongly RECOMMENDED that all devices use these
standard prefixes for all instance documents to avoid confusion on the part of both human and machine readers.
These standard prefixes are used in all descriptive text and all XML examples in this and related UPnP
specifications. Also, each individual specification may assume a default namespace for its descriptive text. In that
case, names from that namespace may appear with no prefix.
The assumed default namespace, if any, for each UPnP AV specification is given in Table 1-5, “Default
Namespaces for the AV Specifications”.
Note: all UPnP AV schemas declare attributes to be “unqualified”, so namespace prefixes are never used with
AV Working Committee defined attribute names.

– 14 – 29341-4-4 © ISO/IEC:2008(E)
Table 1-5: Default Namespaces for the AV Specifications
AV Specification Name Default Namespace Prefix
AVTransport:2 avt-event:
ConnectionManager:2 n/a
ContentDirectory:2 didl-lite:
MediaRenderer:2 n/a
MediaServer:2 n/a
RenderingControl:2 rcs-event:
ScheduledRecording:1 srs:
1.3.2 Namespace Names, Namespace Versioning and Schema Versioning
Each namespace that is defined by the AV Working Committee is named by a URN.
In order to enable both forward and backward compatibility, the UPnP TC has established the general policy that
namespace names will not change with new versions of specifications, even when the specification changes the
definition of a namespace. But, namespaces still have version numbers that reflect definitional changes. Each
time the definition of a namespace is changed, the namespace’s version number is incremented by one.
Therefore, namespace version information must be provided with each XML instance document so that the
document’s receiver can properly understand its meaning. This is achieved by the following rules:
• Every release of a schema is identified by a version number and date of the form “n-yyyymmdd”, where
n corresponds to the namespace definition version number and yyyymmdd is the year, month and day in
the Gregorian calendar that the schema is released.
For example, the new version numbers of the pre-existing “DIDL-Lite” and “upnp” schemas are “2”.
Versions for new schemas, such as “srs” are “1”.
For each schema, the version-date will appear in two places:
1. In the schema file name, according to the naming structure shown in Table 1-4, “Schema-related
Information”.
2. As the value of the version attribute of each schema’s schema root element.
Namespaces are referenced in both schema and XML instance documents by namespace name. The namespace
name appears as the value of an xmlns attribute. The xmlns attribute also declares a namespace prefix that will
be used to qualify names from each namespace. Schemas are referenced in both schema and XML instance
documents by URI in the schemaLocation attribute. See section 1.3.3, “Namespace Usage Examples” . Two
diff
erent forms of URI are available, each with a different meaning. All UPnP AV-defined schema URIs share a
common base path of “http://www.upnp.org/schemas/av/”. Each schema URI has two unique relative forms (see
Table 1-4, “Schema-related Information”), according to which version of a namespace and its representative
schema is of interest. The allowed relative URI forms are:
1. schema-root-name “-v” version-date
where version-date is a full version-date of the form n-yyyymmdd. This form references the schema
whose “root” name (typically the standardized prefix name used for the namespace that the schema
represents) and version-date match schema-root-name and version-date, respectively.
2. schema-root-name “-v” version
where version is an integer representing the namespace’s version number. This form references the most
recent version of the schema whose root name and namespace version number match schema-root-name
and the version, respectively.
Usage rules for schema location URIs are as follows:
• All instance documents, whether generated by a service or a control point, MUST use Form 1.
• All UPnP AV published schemas that reference other UPnP AV schemas will also use Form 1.
• Validation of XML instance documents in UPnP AV systems potentially serves two purposes. The first
is based on standard XML and XML Schema semantics: the document’s creator asserts that the

29341-4-4 © ISO/IEC:2008(E) – 15 –
document is syntactically correct with respect to the referenced schema. The receiving processor can
confirm this with a validating parser that uses the referenced schema(s). The second is based on UPnP
AV namespace semantics. The receiving processor knows that the XML instance document is supposed
to conform to one or more specific UPnP AV specifications. Since the second context is actually the
more important context for instance document processing, the receiving processor MAY validate the
instance document against any version of a schema that satisfies its needs in assessing the acceptability
of the received instance document.
1.3.3 Namespace Usage Examples
The schemaLocation attribute for XML instance documents comes from the XML Schema instance
namespace “http:://www.w3.org/2002/XMLSchema-instance”. A single occurrence of the attribute can declare
the location of one or more schemas. The schemaLocation attribute value consists of a whitespace separated
list of values: namespace name followed by its schema location URL. This pair-sequence is repeated as necessary
for the schemas that need to be located for this instance document.
Example 1:
Sample DIDL-Lite XML Document. This document assumes version-date 2-20060531 of the “didl-lite:”
namespace/schema combination and (a possible later) version 2-20061231 of “upnp:”. The lines with the gray
background show how to express this versioning information in the instance document.

xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/"
xmlns:upnp="urn:schemas-upnp-org:metadata
...