ANSI/CEA-2018

From Model-based User Interfaces Incubator Group Wiki
Revision as of 12:10, 19 August 2009 by Jguerrer (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

ANSI/CEA-2018 Task Model Description standard

ANSI/CEA-2018 defines an XML-based language for task model descriptions. The standard was published by CEA in Nov. 2007 [CEA 2007], and by ANSI in March 2008 [ANSI 2008].

Scope and Purpose

A task model is defined as a "formal description of the activities involved in completing a task, including both activities carried out by humans and those performed by machines." The standard defines the semantics and an XML notation for task models relevant to consumer electronics devices, but nothing prevents anybody from using it in a broader domain. (The standard does not depend on any specific home networking technology or infrastructure.)

The main purpose of ANSI/CEA-2018 is to use task models at run-time to guide users of consumer electronics devices. However, parts of ANSI/CEA-2018 could also be used for building task models reflecting user-system interaction for the analysis or design of interactive systems.

The standard does NOT define or restrict the actual appearance of a user interface or its detailed operation, and thus will not interfere with the preservation of brand identity via corporate logos or other means.

Task Description

A task in ANSI/CEA-2018 is represented as an XML element <task>.

Input and Output Slots

It has input and output slots, representing the data to be communicated with other tasks.

EXAMPLE: The following specifies a task class in which the datatype of the slot named "count" is number and the datatype of the slot named "result" is string.

<task id="slots">
	<input name="count" type="number"/>
	<output name="result" type="string"/>
</task>

The following slot names are predefined:

  • "device": The value of a task’s "device" slot may be set in order to cause a task to be executed with a particular device as the target.
  • "external": The value of a task’s "external" slot may be set or tested to restrict the use of the decomposition to system tasks (no user involvement).
  • "when": The predefined output slot named "when" of type Date records the moment in time when a task instance should or (for task occurrences) did occur.
  • "success": The predefined output slot named "success" of type boolean records whether a task instance should or (for task occurrences) did succeed (value true) or fail (value false), if known; otherwise the slot is undefined.

User Intent Concept

A user intent concept is a case frame, consisting of a verb and a set of semantic roles of specified types.

EXAMPLE: The following is an example of the URI form of the <concept> element. The URI shown suggests that an OWL ontology is being used to define the user intent concept for myTask.  

<task id="myTask">
	<concept> http://example.com/concepts.owl#myTask 
	</concept>
</task>

The following semantic roles are predefined:

  • agent: Agents are entities that bring about a state of affairs.
  • theme: The theme is whatever is acted upon or most affected or undergoes motion of some sort, including motion in a metaphorical sense.
  • instrument: The instrument is whatever is being used to perform the action.
  • location: Locations are places; they can also serve as the endpoints of paths.


Precondition

A precondition is a partial boolean function property of a task class with arguments corresponding to the input slots of the task class.

EXAMPLE: The following specifies a task for loading a DVD, with the precondition that the drawer is open. Notice the $this.device expression returns the value of the "device" input slot of the given task instance.

<task id="loadDVD">
	<input name="device" type="string"/>
	<precondition> isDrawerOpen($this.device) 
	</precondition>
</task>

Postcondition

A postcondition is a partial boolean function property of a task class with arguments corresponding to the input and output slots of the task class.

EXAMPLE: The task class for opening a (e.g., DVD) drawer below has a sufficient postcondition. We assume here that the global ECMAScript function "isDrawerOpen" is defined elsewhere, e.g., via an initialization script (see 10.1).

<task id="openDrawer">
	<input name="device" type="string"/>
	<postcondition sufficient="true"> isDrawerOpen($this.device) </postcondition>
</task>


Task Decomposition

A task can be decomposed into subtasks which are described as steps for executing the task.

EXAMPLE: The following is a valid, but minimal, decomposition specification. Notice that the step classes of the slots below use a namespace prefix to refer to task classes specified in the example task model in 7.4.  

<taskModel 
		about="http://example.com" 
		xmlns="http://ce.org/cea-2018"
		xmlns:my="http://example.com/myproject">
	<subtasks id="YZ" goal="my:X">
		<step name="step1" task="my:Y"/>
		<step name="step2" task="my:Z"/>
	</subtasks>
</taskModel>

Steps are sequential by default, in the order as defined in the XML structure. However, other step orders can be specified via the 'ordered' attribute.

EXAMPLE: The following specifies a partial order in which step3 must occur after step1 and step2, but step1 and step2 may occur in any order.  

<subtasks id="DEF" goal="my:X" ordered="false">
	<step name="step1" task="D"/>
	<step name="step2" task="E"/>
	<step name="step3" task="F" requires="step1 step2"/>
</subtasks>

Applicability Condition

A task decomposition may have an applicability condition. An applicability condition is a partial boolean function property of a decomposition class or a script with arguments corresponding to the input slots of the goal or script task class.

Binding

A task decomposition specifies the data flow between the input and output slots of a task and its subtasks, and those between the subtasks. This is called a binding. In ANSI/CEA-2018, a binding is an equality between an input 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.

Grounding

Grounding is the binding of primitive tasks (those that do not have subtasks) to a script (written in ECMAScript). In ANSI/CEA-2018, a script is an ECMAScript program which may be associated with one or more tasks classes, platforms and device types and whose properties include an applicability condition.


Target Architecture and Applications

ANSI/CEA-2018 assumes the following target architecture for a task model description:

Target architecture for ANSI/CEA-2018

Within this architecture, a task-based application is interacting with a user, based on a task model description. It accesses and controls one or multiple devices through a grounding implementation. Additionally, the user can perform manual operations on the device; changes on the device's state will be propagated to the task-based application via the grounding implementation.

There is a wide variety of ways that applications can use task model descriptions as a guide for user interaction. Some examples of task-based applications are:

  • Network Command Menu
  • Natural Language Access to EPG
  • Intelligent Help Agent
  • Task Personalization
  • Intelligent Home Network Troubleshooting


Example Task Model

The following figure depicts a small sample task model for playing music on an entertainment system consisting of a media server and a media player.

Sample task model for playing music

Task Model Description for this example (elipses indicating parts that are out of scope for the standard):

<taskModel 
      about="http://ce.org/cea-2018/AnnexB"
      xmlns="http://ce.org/cea-2018" 
      xmlns:dc="http://purl.org/dc/elements/1.1"
      xmlns:dcterms="http://purl.org/dc/terms">

   <dc:title xml:lang="en">Playing Music</dc:title>
   <dc:description xml:lang="en">CEA-2018 conformant sample task model description for 
      playing music with UPnP AV devices and URC grounding.</dc:description>
   <dc:creator>Gottfried Zimmermann</dc:creator>
   <dc:contributor>Charles Rich</dc:contributor>
   <dcterms:issued>2007-08-25</dcterms:issued>
   <dcterms:modified>2007-09-10</dcterms:modified>

   <task id="playMusic">
      <subtasks id="playMusicSteps" ordered="false">
         <step name="select" task="selectMusic"/>
         <step name="configure" task="configureRenderer"/>
         <step name="connect" task="connect" requires="select configure"/>
         <step name="play" task="play" requires="connect"/>
         <binding slot="$connect.preferredConnectionProtocol" value="'*'"/>
      </subtasks>
   </task>
   <task id="selectMusic">
      <subtasks id="selectMusicSteps">
         <step name="server" task="selectServer"/>
         <step name="browse" task="browse"/>
         <step name="node" task="selectNode"/>
         <binding slot="$browse.browseFilter" value="'*'"/>
         <binding slot="$browse.browseSortCriteria" value="'+dc:title'"/>
         <binding slot="$play.connectionId" value="$connect.newConnectionId"/>
      </subtasks>
   </task>
   <task id="configureRenderer">
      <subtasks id="configureRendererSteps">
         <step name="select" task="selectRenderer"/>
         <step name="preset" task="selectPreset" minOccurs="0" maxOccurs="1"/>
      </subtasks>
   </task>

   <script platform="URC">
      // ...
   </script>

   <script platform="URC" init="true">
      // ...
   </script>
 
   <task id="selectServer">
      <input name="selectedMediaServer" type="string"/>
   </task>
   <task id="browse">
      <input name="browseFilter" type="string"/>
      <input name="browseSortCriteria" type="string"/>
   </task>
   <task id="selectNode">
      <input name="selectedNodeId" type="string"/>
   </task>
   <task id="selectRenderer">
      <input name="selectedMediaRenderer" type="string"/>
   </task>
   <task id="selectPreset">
      <input name="presetName" type="string"/>
   </task>
   <task id="connect">
      <input name="preferredConnectionProtocol" type="string"/>
      <output name="newConnectionId" type="string"/>
      <output name="error" type="ErrorDescription"/>
   </task>
   <task id="play">
      <input name="connectionId" type="string"/>
      <input name="playCurrentPlayMode" type="PlayMode"/>
      <input name="playTransportPlaySpeed" type="PlaySpeed"/>
   </task>

   <!-- external events -->

   <task id="transportStatusError">
      <output name="error" type="ErrorDescription"/>
   </task>
   <task id="conNotifyContentFormatMismatch">
      <output name="error" type="ErrorDescription"/>
   </task>
   <task id="conNotifyInsufficientNetworkResources">
      <output name="error" type="ErrorDescription"/>
   </task>
   <task id="conNotifyUnreliableChannel">
      <output name="error" type="ErrorDescription"/>
   </task>
   <task id="conNotifyUnknownConnectionError">
      <output name="error" type="ErrorDescription"/>
   </task>
</taskModel>


References and Literature

[CEA 2007] CEA-2018 (ANSI). Task Model Description (CE TASK 1.0). CEA. http://www.ce.org/Standards/browseByCommittee_4467.asp

[ANSI 2008] ANSI Standards Store. http://webstore.ansi.org/

[Rich 2009] Rich, C (2009). Building Task-Based User Interfaces With ANSI/CEA-2018. IEEE Computer, Vol. 42, No. 9, August 2009.