ANSI CTA-2018-2008 Task Model Description (CE TASK 1.0) (Formerly ANSI CEA-2018).pdf

1、 CTA Standard Task Model Description (CE TASK 1.0) CTA-2018 R2016 (Formerly ANSI/CEA-2018) March 2008 NOTICE Consumer Technology Association (CTA) Standards, Bulletins and other technical publications are designed to serve the public interest through eliminating misunderstandings between manufacture

2、rs and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for his particular need. Existence of such Standards, Bulletins and other technical publications shall not in any respect precl

3、ude any member or nonmember of the Consumer Technology Association from manufacturing or selling products not conforming to such Standards, Bulletins or other technical publications, nor shall the existence of such Standards, Bulletins and other technical publications preclude their voluntary use by

4、 those other than Consumer Technology Association members, whether the standard is to be used either domestically or internationally. Standards, Bulletins and other technical publications are adopted by the Consumer Technology Association in accordance with the American National Standards Institute

5、(ANSI) patent policy. By such action, the Consumer Technology Association does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard, Bulletin or other technical publication. This document does not purport to address all safety prob

6、lems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this document to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. This document is copyrighted by the Consumer

7、 Technology Association (CTA) and may not be reproduced, in whole or part, without written permission. Federal copyright law prohibits unauthorized reproduction of this document by any means. Organizations may obtain permission to reproduce a limited number of copies by entering into a license agree

8、ment. Requests to reproduce text, data, charts, figures or other material should be made to the Consumer Technology Association (CTA). (Formulated under the cognizance of the CTA R7 Home Networks Committee.) Published by CONSUMER TECHNOLOGY ASSOCIATION 2016 Technology Phone 800-854-7179; Fax 303-397

9、-2740; Internet http:/; E-mail DCMI Documents: Dublin Core Metadata Initiative (DCMI); Internet http:/www.dublincore.org ECMA Documents: ECMA International, Rue du Rhone 114, CH-1204 Geneva; Phone +41 22 849 6000; Fax +41 22 489 6001; Internet http:/www.ecma-international.org/. ECMA Standard Docume

10、nts can be downloaded electronically and free of charge at http:/www.ecma-international.org/publications/standards/Standard.htm CEA-2018 4 IETF Documents: Internet Engineering Task Force (IETF) Secretariat, c/o Corporation for National Research Initiatives, 1895 Preston White Drive, Suite 100, Resto

11、n, VA 20191-5434, USA; Phone 703- 620-8990; Fax 703-620-9071; Internet www.ietf.org, IETF RFCs may be downloaded from www.ietf.org/rfc.html, IETF Internet drafts may be downloaded from www.ietf.org/ID.html ISO/IEC Documents: International Organization for Standardization (ISO); ISO Central Secretari

12、at; 1, rue de Varemb; Case postale 56; CH-1211 Geneva 20; Switzerland; Telephone +41 22 749 01 11; Fax +41 22 733 34 30; Internet http:/www.iso.org/; ISO/IEC Standard Documents can be purchased and downloaded electronically at http:/www.iso.org/iso/en/prods-services/ISOstore/store.html UPnP Document

13、s: UPnP Forum; Internet http:/www.upnp.org/ World Wide Web Consortium Documents: World Wide Web Consortium (W3C); Internet http:/www.w3.org/ 4 TERM USAGE Notwithstanding the placement of a NOTE or EXAMPLE in a normative section, paragraphs marked as “NOTE” or “EXAMPLE” shall be treated as informativ

14、e. 4.1 Applications DEFINITION 1 A task-based application (“application” for short) is a program that interprets task model descriptions according to the semantics defined in this standard. For brevity, in the remainder of this document, a task-based application will be referred to generically as an

15、 application. 4.2 Use of Shall, Should and May Specific keywords are used in this document to differentiate levels of requirements and optionality, as follows: Shall: Indicates a mandatory requirement. Designers are required to implement all such mandatory requirements to assure interoperability wit

16、h other products conforming to this standard. Should: Indicates flexibility of choice with a strongly preferred alternative. Equivalent to the phrase “is recommended.” May: Indicates flexibility of choice with no implied preference. 4.3 Schemas The valid syntax for task model descriptions is defined

17、 using RelaxNG 6, with comments added to express restrictions that are not expressible in this schema language. These schemas are presented in Table 1 through Table 7 and are normative in this standard. The syntax for the about document (see 10.2.3) is also defined using RelaxNG. The corresponding T

18、able 9 is normative in this standard. Notice that the order of XML sibling elements is fixed throughout the syntax schemas (attributes may be provided in any order). The motivation for this approach is to make it easier for humans to read task model descriptions and for applications to process them.

19、 CEA-2018 5 4.4 Namespaces This standard defines and uses the XML namespaces “http:/ce.org/cea-2018“ for task model descriptions. Examples in this standard assume that this namespace is declared as the default namespace on the root element of a task model description document, such as in the followi

20、ng: Task model descriptions may adopt this approach, or define an explicit namespace prefix. For other namespaces, the following three prefixes are used in the examples throughout this standard. Task model descriptions are not required to use these same prefixes as long as they declare the relevant

21、namespaces properly (as specified in 7). xsd - the namespace http:/www.w3.org/2001/XMLSchema (XML Schema Definition) dc - the namespace http:/purl.org/dc/elements/1.1 (DCMI Element Set). A schema definition file for this namespace is available at http:/www.dublincore.org/schemas/xmls/qdc/2006/01/06/

22、dc.xsd dcterms - the namespace http:/purl.org/dc/terms (DCMI Metadata Terms). A schema definition file for this namespace is available at http:/www.dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd Namespace URIs, such as those above, are primarily for identification purposes and are not requir

23、ed to be resolvable 7, i.e., they might not serve a document when used as an internet address. 4.5 Classes and Instances The standard terminology of object-oriented programming and design is used in this document without formal definition. In particular, a class typically has many instances, which d

24、iffer in the values of the instance variables, or slots (as they are called in this document). DEFINITION 2 A slot is a named, typed instance variable. A class determines the names of the slots and the type of values each slot may hold; the slot values are determined by each instance. Finally, the c

25、lass itself may have properties (sometimes called class variables), which are “inherited” by all instances, i.e., all instances have the same value for these properties. 4.6 Functions DEFINITION 3 A partial function is a function which may be undefined for some argument values. DEFINITION 4 An undef

26、ined function is a partial function which is undefined for all argument values. 5 DEFINITIONS For the purposes of this document, the following terms and definitions apply. (This section lists the definitions of this standard in one place.) DEFINITION 1 A task-based application (“application” for sho

27、rt) is a program that interprets task model descriptions according to the semantics defined in this standard. DEFINITION 2 A slot is a named, typed instance variable. DEFINITION 3 A partial function is a function which may be undefined for some argument values. DEFINITION 4 An undefined function is

28、a partial function which is undefined for all argument values. CEA-2018 6 DEF a script which is not associated with any task class and is intended to be executed exactly once. 6 INTRODUCTION (Informative) The task is: .g., turning off the room lights; and some have unbounded time extent, e.g., a wee

29、kly rs may be performed by either, depending on the circumstances (e.g., opening the DVD drawer). DEFINITION 5 A task model is an ordered set of task classes, decomposition classes and scripts. The empty set is a valid task model. DEFINITION 6 A task class is a class whose properties include a preco

30、ndition, a postcondition, a (possibly empty) ordered set of user intent concepts and a (possibly empty) set of scripts. DEFINITION 7 A task occurrence is a task instance which corresponds to an actual event. DEFINITION 8 A hypothetical task instance is a task instance which does not correspond to an

31、 actual event. DEFINITION 9 An input slot is a slot of a task class which is expected to have a value before execution of a task instance. DEFINITION 10 An output slot is a slot of a task class which is not expected to have a value until after execution of a task instance. DEFINITION 11 A user inten

32、t concept is a case frame, consisting of a verb and a set of semantic roles of specified types. DEFINITION 12 A precondition is a partial boolean function property of a task class with arguments corresponding to the input slots of the task class. DEFINITION 13 A postcondition is a partial boolean fu

33、nction property of a task class with arguments corresponding to the input and output slots of the task class. DEFINITION 14 A decomposition class is a class whose properties include a step order, applicability condition and binding set. DEFINITION 15 An applicability condition is a partial boolean f

34、unction property of a decomposition class or a script with arguments corresponding to the input slots of the goal or script task class. DEFINITION 16 A binding set is a (possibly empty) set property of a decomposition class containing bindings. DEFINITION 17 A binding is an equality between an input

35、 slot of a decomposition step or an output slot of a decomposition goal, and the value of a function with arguments corresponding either to the output slots of steps or the input slot of the goal. DEFINITION 18 A script is an ECMAScript 5 program which may be associated with one or more tasks classe

36、s, platforms and device types and whose properties include an applicability condition. INITION 19 An initialization script is 6.1 Tasks concept of task is at the heart of this standard. A dictionary 10 definition of “a usually assigned piece of work often to be finished within a certain time.” The t

37、ask concept is also suggested by synonyms like “activity“, “goal“, “job“, or “action“. Examples of tasks in the domain of consumer electronics include copying a videotape to a DVD, watching a recorded TV episode, and turning off room lights. Tasks vary widely in their time extent: some take place ov

38、er minutes or hours, e.g., watching a recorded TV episode; some are effectively instantaneous, eteleconference. Tasks typically involve both human participants (e.g., as requesters, beneficiaries, or performers) and electronic devices. Some tasks may be performable only by a human being (e.g., provi

39、ding fingerprint identification); others may be performed only by an electronic device (e.g., displaying a video); yet otheCEA-2018 7 Tasks also vary along an abstraction spectrum from what might be called “high-level“, i.e., closer to the users intent and natural way of communicating, to “low-level

40、“, i.e., closer to the primitive controls of a particular device. Watching a recorded TV episode is an example of a fairly high-level task. Pressing the power button on a DVD player is an example of a very low-level task. Tasks are also more or less abstract by virtue of being parameterized. For exa

41、mple, watching the Season Two opening episode of The West Wing is a more specific version of the generic task of watching a recorded TV episode (in which the episode to be watched has been bound). Specification of regularly scheduled tasks is out of the scope of this standard, since it can be very c

42、omplicated. 6.2 Task Decomposition High-level tasks usually need to be (repeatedly) decomposed into increasingly lower-level tasks (called subtasks) in order to accomplish them. This decomposition can sometimes be achieved entirely by the system; sometimes a collaboration between the system and user

43、 is required. The two main reasons why user involvement in task decomposition is sometimes required are: There are preferences involved which the user may need/want to provide. For example, when making a digital recording, a choice needs to be made in the fundamental tradeoff between picture quality

44、 and recording size. The system can help the user by explaining the options and their implications, and suggesting defaults. Similarly, the user may help in identifying which device should be used for the execution of a task, if multiple devices are available that can be used. The hardware may not b

45、e physically capable of performing certain actions, such as putting a blank DVD into the recorder. 6.3 Task Classes and Instances A task model, as we will see below, contains task classes. For example, pressing the power button on a DVD player is an example of a task class. Slots of this class might

46、 include who pressed the button, which DVD player was involved, and when the action took place. Thus David Smith pressing the power button on the DVD player in his living room at 3:15pm on January 1, 2006 is an example of an instance of this class. A task instance may correspond to an actual event o

47、r it may be hypothetical. See 8.3 for the ECMAScript representation of task instances used in this standard. Applications typically manipulate both task classes and instances. This standard does not, however, specify a representation for task instances that is up to application implementations. Figu

48、re 2 and the definitions in 8 summarize this terminology for tasks. For brevity, this standard sometimes simply uses the term task below where the context makes it clear whether a task class or a task instance is meant, or the remark applies to both classes and instances. “task” (ambiguous term) tas

49、k class task instance task occurrence “hypothetical” task instance Figure 2: Task Terminology CEA-2018 8 6.4 Task-Based Applications The motivation for defining this standard is to facilitate the development of task-based applications. Figure 3 shows the system architecture that this standard assumes. In a task-based application, the user and system interact primarily in terms of high-level goals, which the system decomposes into primitive actions that are directly supported by the one or more devices involved. T