1、 Copyright 2008 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved March 3, 2008 Table of Contents Page Foreword . 2 Introduction . 2 1 Scope 3 2 Conformance Notation 3 3 Normative References 3 4 DCML Namespace 4 5 Basic Da
2、ta Types 4 5.1 UUID Type . 4 5.2 User Text Type. 5 5.3 Rational Type. 5 5.4 Units of Measure 5 5.5 Temperature Type 7 5.6 Voltage Type 7 5.7 Current Type 7 5.8 Duration Type. 7 5.9 Rate Type. 8 5.10 Device Identifier Types 8 5.11 Device Type Identifier Type . 10 5.12 Named Parameters and Parameter L
3、ists 11 5.13 Version Information Types . 13 6 Composite Types 14 6.1 Device Description Type 14 7 XML Schema (Informative) 16 Annex A Camel Case Usage (Informative) 17 Annex B Bibliography (Informative) 18 B.1 Language Identifiers 18 B.2 Character Coding. 18 Page 1 of 18 pages SMPTE 433-2008SMPTE ST
4、ANDARD D-Cinema XML Data Types SMPTE 433-2008 Page 2 of 18 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 co
5、untries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other
6、standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its Administrative Practices. SMPTE Standard 433 was prepared by Technology Committee DC28. Introduction In the development of XML Schema for a n
7、umber of D-Cinema artifacts, it was observed that a number of common data types were defined and redefined multiple times in application schemas. This document combines the definition of the most commonly duplicated data types in a single namespace, along with additional types that are most commonly
8、 defined in large XML projects, and which have general applicability to the field of Digital Cinema Systems. The intention is that this namespace can be included in other schema to easily use these types as needed. These data types are defined using W3C XML Schema Definition Language (XSDL) as defin
9、ed in XML-SCH-1. SMPTE 433-2008 Page 3 of 18 pages 1 Scope The purpose of this document is to define and describe common data types used in D-Cinema metadata structures for applications using XML as a data description language. In addition, this document includes normative references for types and i
10、dentifiers, defined elsewhere, which are necessary to use XML in standards documents. The structure and composition of the types defined in this document are simple yet general in order to promote reusability in other standards. 2 Conformance Notation Normative text is text that describes elements o
11、f the design that are indispensable or contains the conformance language keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative t
12、ext does not contain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be fol
13、lowed in order to conform to the document and from which no deviation is permitted. The keywords, “should“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred
14、 but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is n
15、ot defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provi
16、sions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. 3 Normative References The following standards contain provisions which, through reference in
17、this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards
18、 indicated below. XML-SCH-1 XML Schema Part 1: Structures http:/www.w3.org/TR/xmlschema-1-20041028/ XML-SCH-2 XML Schema Part 2: Datatypes http:/www.w3.org/TR/xmlschema-2-20041028/ ISO-639-2 International Standards Organization (ISO) ISO-639-2 Codes for the representation of names of languages- Part
19、 2: alpha-3 code. Normative Text: http:/www.loc.gov/standards/iso639-2/normtext.html Registration Authority: US Library of Congress: http:/www.loc.gov/standards/iso639-2/ SMPTE 433-2008 Page 4 of 18 pages ISO-3166-1 International Standards Organization (ISO) ISO 3166-1:1997 Codes for the representat
20、ion of names of countries and their subdivisions - Part 1: Country codes Official List: http:/www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html Decoding Table: http:/www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html RFC-4122
21、 Internet Engineering Task Force (IETF) RFC 4122 “A Universally Unique Identifier (UUID) URN Namespace“ http:/www.ietf.org/rfc/rfc4122.txt RFC-3066 Internet Engineering Task Force (IETF) RFC 3066 “Tags for Identification of Languages“ (January 2001) http:/www.ietf.org/rfc/rfc3066.txt RFC-3629 Intern
22、et Engineering Task Force (IETF) RFC 3629: “UTF-8, a transformation format of ISO 10646“ http:/www.ietf.org/rfc/rfc3629.txt D-Cert SMPTE 430-2-2006, D-Cinema Operations Digital Certificate 4 DCML Namespace This document uses many of the basic datatypes specified in XML-SCH-2 to define a number of de
23、rived types for D-Cinema applications. This collection of types shall be referred to as Digital Cinema Mark-up Language (DCML). The types defined in this document shall be included in an XML namespace, whose Namespace Name (URI) shall be: http:/www.smpte-ra.org/schemas/433/2008/dcmlTypes/ When publi
24、shed, the version number of the informative XML Schema representation of the namespace shall be set to “1.0“, where “1“ is the major part of the version number, and “0“ is the minor part. If the namespace is subsequently revised to add new types not defined in this standard, but not to modify any of
25、 the existing types in a way that breaks reverse compatibility, the minor part of the version number shall be incremented by one. If the namespace is subsequently modified with result of changing any of the types defined in this document in a way that breaks reverse compatibility, the major part of
26、the version number shall be incremented by one. The version number shall be specified by the version attribute the xs:schema element of the XML schema that this namespace represents. 5 Basic Data Types This section describes a set of fundamental data types that are intended for use in the constructi
27、on of more complex types in application schemas. 5.1 UUID Type UUIDs are used as object identifiers in many places in schema for D-Cinema. The structure of a UUID is normatively defined in RFC-4122. In schemas, UUIDs shall be represented by the following data type: SMPTE 433-2008 Page 5 of 18 pages
28、5.2 User Text Type In various places in schemas, user text data is specified. In order to provide for language specification and a default language, the following User Text type is extended from a simple string type. Schemas shall use this type to represent stored text intended for viewing by users.
29、 Note that the language identifier attribute is optional, but defaults to English in the absence of the attribute. The language identifiers are defined in RFC-3066. In XSDL, the User Text Type shall be defined as follows: 5.3 Rational Type Many relationships in media are described in terms of ratios
30、 of integers. Image aspect ratios and edit rates are common examples of this. In order to provide a consistent representation of these ratios, the Rational data type is defined as an ordered list of two long integers. The first long integer in the list is the numerator, and the second is the denomin
31、ator. In XSDL, the Rational Type shall be defined as follows: 5.4 Units of Measure The basic datatypes defined in XML-SCH-2 do not address units of measure. In Digital Cinema systems, many specifications are expressed in units of measurement, and many quantities must be measured. While the units of
32、measurement may be implicit in some cases, in other cases explicit units are required to clarify the meaning of the measurement. This section defines XML data types for common units of measure that are useful for digital cinema applications, such as system set-up and monitoring. 5.4.1 Units of Tempe
33、rature Temperatures are normally expressed on one of three scales. This type defines a set of tokens, which provide for the expression of temperature scale units. The set of temperature unit tokens shall be defined as follows: SMPTE 433-2008 Page 6 of 18 pages 5.4.2 Units of Voltage Units of voltage
34、 are well understood, but are usually scaled in chunks of three orders of magnitude when expressed as measurements. This type defines tokens for the common scaling orders used in common electronic systems. The set of voltage unit tokens shall be defined as follows: 5.4.3 Units of Current Units of cu
35、rrent are expressed in amperes, and are usually scaled in chunks of three orders of magnitude when expressed as measurements. This type defines tokens for the common scaling orders used in common electronic systems. The set of current unit tokens shall be defined as follows: Current is commonly unde
36、rstood to be measured in two modes: either alternating current (AC) or direct current (DC). The current mode shall be expressed with a token defined in the following type: 5.4.4 Units of Duration (Time) Duration is defined in units of seconds, where sixty seconds is one minute, sixty minutes are one
37、 hour, twenty-four hours are one day, seven days are one week, and 365 days are one year. Standard engineering practice provides the three orders of magnitude decimal offsets for subdivisions of seconds. Durations of time shall be expressed using the following tokens to convey the unit period of tim
38、e expressed. Note: Durations expressed in years do not account for leap year corrections that work is left to the application. SMPTE 433-2008 Page 7 of 18 pages 5.5 Temperature Type Quantities of temperature shall be expressed with the following data type: 5.6 Voltage Type Quantities of voltage shal
39、l be expressed with the following data type: 5.7 Current Type Quantities of current shall be expressed with the following data type: 5.8 Duration Type Durations (quantities of time) shall be expressed with the following data type: SMPTE 433-2008 Page 8 of 18 pages 5.9 Rate Type Many interesting meas
40、urements are expressed as rates, or the number of instances of an event that occur in a given period of time. Definition of a Rate Type requires specification of the type of event being counted and the period of time of counting. The previously defined rational type is extended to define a Rate Type
41、, which shall be defined as follows: The optional eventscope attribute in the definition above shall have a default value of “http:/www.smpte-ra.org/schemas/433/2008/dcmlTypes#rate-scope-tokens“ which refers to the list of possible values for the event token. This default value for the eventscope at
42、tribute URI shall refer to the values listed in the following table. If an online resource directory is implemented for this schema, a list of allowable tokens shall be provided at the resource page that the attribute value resolves to when treated as a URL. Token Description Cycle a cycle of repeat
43、ing function Revolution a complete revolution of a rotating device Frame a frame of content, as defined for that content Sample a sample of essence, as defined for that essence Byte eight bits Unit a generic unit 5.9.1 Rate Type Examples (Informative) 1200 1 50 1 3 1 48000 1 24000 1001 5.10 Device I
44、dentifier Types A fundamental requirement for building systems of multiple devices is to identify the devices in the system. This section defines the data types that shall be used to identify devices in a digital cinema system. Depending on the role of a particular physical or logical device, a devi
45、ce may be identified either by a UUID, or by a security certificate thumbprint, or both. By definition, a device, which functions as a security device, must contain a security certificate. Because a single device may have multiple roles, a device may have both kinds of identifiers associated with it
46、. SMPTE 433-2008 Page 9 of 18 pages 5.10.1 Basic Identifiers 5.10.1.1 Device UUID If a device is to be identified by a UUID, that UUID shall be represented using the dcml:UUIDType. 5.10.1.2 Certificate Thumbprint If the subject device is to be identified by a security certificate, the device identif
47、ier shall be its Public Key Thumbprint,as defined in D-Cert Section 5.4 “Certificate and Public Key Thumbprint”. The Public Key Thumbprint shall be stored in XML using the ds:DigestValueType. 5.10.2 Device Identifier List Type This data type shall be used to identify a specific device within a log r
48、ecord, an approved device list, a site device inventory report, a trusted device list (TDL), or anyplace else that a device in a theater system must be specifically identified. The DeviceIdentifierList shall contain at least one of the following two elements, and may contain both. Either type (Devic
49、e UUID or Certificate Thumbprint) may be used in either the Primary ID or the Secondary ID element. Either of the two elements may be used to refer to the identified device, as both identifiers are unique to the device. This type may also be used to map from one identifier to the other when necessary. 5.10.2.1 Primary ID The PrimaryID element shall contain the primary identifier of the device. This may be either the Device UUID or the device Certificate Thumbprint. 5.10.2.2
