CEA-2018-2008 Task Model Description (CE TASK 1 0)《任务模型说明(CE TASK 1 0)》.pdf

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

2、acilitating 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 preclude any member or no

3、nmember of CEA 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 those other than CEA members, whether the standard

4、is to be used either domestically or internationally. Standards, Bulletins and other technical publications are adopted by CEA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, CEA does not assume any liability to any patent owner, nor does it assume

5、any obligation whatever to parties adopting the Standard, Bulletin or other technical publication. This CEA Standard is considered to have International Standardization implication, but the International Electrotechnical Commission activity has not progressed to the point where a valid comparison be

6、tween the CEA Standard and the IEC document can be made. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to

7、determine the applicability of regulatory limitations before its use. (Formulated under the cognizance of the CEAs R7 Home Network Committee.) Published by CONSUMER ELECTRONICS ASSOCIATION 2008 Technology Phone 800-854-7179; Fax 303-397-2740; Internet http:/; E-mail DCMI Documents: Dublin Core Meta

8、data 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 Documents can be downloaded electronically and free of charge at http:

9、/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, Reston, VA 20191-5434, USA; Phone 703- 620-8990; Fax 703-620-9071; In

10、ternet 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 Secretariat; 1, rue de Varemb; Case postale 56; CH-1211 Geneva 20; Switze

11、rland; 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 Documents: UPnP Forum; Internet http:/www.upnp.org/ World Wide Web Conso

12、rtium 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 informative. 4.1 Applications DEFINITION 1 A task-based application (“appl

13、ication” 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 application. 4.2 Use of Shall, Should and May Specific keywords

14、 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 with other products conforming to this standard. Should: Indicates

15、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 using RelaxNG 6, with comments added to express restrictions th

16、at 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 Table 9 is normative in this standard. Notice that the order of X

17、ML 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. CEA-2018 5 4.4 Namespaces This standard defines and uses the XM

18、L 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 following: Task model descriptions may adopt this approach, or define a

19、n 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 namespaces properly (as specified in 7). xsd - the namespace htt

20、p:/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/dc.xsd dcterms - the namespace http:/purl.org/dc/terms (DCMI Met

21、adata 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 required to be resolvable 7, i.e., they might not serve a document whe

22、n 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 differ in the values of the instance variables, or slots (as they

23、 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 class itself may have properties (sometimes called class variable

24、s), 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 undefined function is a partial function which is undefined for all a

25、rgument 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 short) is a program that interprets task model descriptions accordi

26、ng 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 a partial function which is undefined for all argument values. C

27、EA-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 weekly rs may be performed by either, depending on the circumstance

28、s (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 precondition, a postcondition, a (possibly empty) ordered set of user

29、 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 actual event. DEFINITION 9 An input slot is a slot of a task cl

30、ass 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 intent concept is a case frame, consisting of a verb and a set of sem

31、antic 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 function property of a task class with arguments corresponding to

32、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 function property of a decomposition class or a script with argum

33、ents 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 slot of a decomposition step or an output slot of a decompositi

34、on 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 classes, platforms and device types and whose properties include an ap

35、plicability 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 task concept is also suggested by synonyms like “activity“, “goal

36、“, “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 over minutes or hours, e.g., watching a recorded TV episode; some

37、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., providing fingerprint identification); others may be performed only b

38、y 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“, i.e., closer to the primitive controls of a particular device

39、. 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 example, watching the Season Two opening episode of The West Wing i

40、s 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 complicated. 6.2 Task Decomposition High-level tasks usually need

41、 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 is required. The two main reasons why user involvement in task

42、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 and recording size. The system can help the user by explaining

43、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 be physically capable of performing certain actions, such as putt

44、ing 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 include who pressed the button, which DVD player was involved,

45、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 or it may be hypothetical. See 8.3 for the ECMAScript representat

46、ion 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. Figure 2 and the definitions in 8 summarize this terminology for tas

47、ks. 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) task class task instance task occurrence “hypothetical” task instan

48、ce 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 pri

49、marily in terms of high-level goals, which the system decomposes into primitive actions that are directly supported by the one or more devices involved. Task-based applications address the problem that many people find new digitally-enhanced consumer electronic products too complex to operate and therefore do not use most of the features of them. Figure 3: Expected Architecture for Using CEA-2018 Figure 3 is a functional, as opposed to physical, architecture. For example, the task-based application component may i