discontinued / server · Files

index.html 169 KB
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482 2483 2484 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779 2780 2781 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3006 3007 3008 3009 3010 3011 3012 3013 3014 3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3049 3050 3051 3052 3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3167 3168 3169 3170 3171 3172 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 3996 3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4213 4214 4215 4216 4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289 4290 4291 4292 4293 4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309 4310 4311 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<title>Multimodal Architecture and Interfaces</title>
<style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}

table {
        width:80%;
        border:1px solid #000;
        border-collapse:collapse;
        font-size:90%;
    }

td,th{
        border:1px solid #000;
        border-collapse:collapse;
        padding:5px;
    }   


caption{
        background:#ccc;
        font-size:140%;
        border:1px solid #000;
        border-bottom:none;
        padding:5px;
        text-align:center;
    }

img.center {
  display: block;
  margin-left: auto;
  margin-right: auto;
}
p.caption {
  text-align: center
}


.RFC2119 {
  text-transform: lowercase;
  font-style: italic;
}
</style>

<link rel="stylesheet" type="text/css"
href="http://www.w3.org/StyleSheets/TR/W3C-CR.css" />
</head>
<body>
<div class="head">
<p><a href="http://www.w3.org/"><img
src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48"
width="72" /></a></p>

<h1><a name="title" id="title" />Multimodal Architecture and
Interfaces</h1>

<h2><a name="w3c-doctype" id="w3c-doctype" />W3C Candidate
Recommendation <i>12</i> <i>January</i> <i>2012</i></h2>

<dl>
<dt>This version:</dt>

<dd><a
href="http://www.w3.org/TR/2012/CR-mmi-arch-20120112/">http://www.w3.org/TR/2012/CR-mmi-arch-20120112/</a></dd>

<dt>Latest version:</dt>

<dd><a
href="http://www.w3.org/TR/mmi-arch/">http://www.w3.org/TR/mmi-arch/</a></dd>

<dt>Previous version:</dt>

<dd><a
href="http://www.w3.org/TR/2011/WD-mmi-arch-20110906/">http://www.w3.org/TR/2011/WD-mmi-arch-20110906/</a></dd>

<dt>Editor:</dt>

<dd>Jim Barnett, Genesys Telecommunications Laboratories</dd>

<dt>Authors:</dt>

<dd>Michael Bodell, Microsoft</dd>

<dd>Deborah Dahl, Invited Expert</dd>

<dd>Ingmar Kliche, Deutsche Telekom AG</dd>

<dd>Jim Larson, Invited Expert</dd>

<dd>Raj Tumuluri, Openstream</dd>

<dd>Moshe Yudkowsky, Invited Expert</dd>

<dd>Muthuselvam Selvaraj, (until 2009, while at HP)</dd>

<dd>Brad Porter (until 2005, while at Tellme)</dd>

<dd>Dave Raggett (until 2007, while at W3C/Volantis)</dd>

<dd>T.V. Raman (until 2005, while at IBM)</dd>

<dd>Andrew Wahbe (until 2006, while at VoiceGenie)</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
© 2012 <a href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
href="http://www.csail.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.eu/"><acronym
title="European Research Consortium for Informatics and Mathematics">
ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>),
All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">
liability</a>, <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">
trademark</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>

<hr />
<div>
<h2><a name="abstract" id="abstract" />Abstract</h2>

<p>This document describes a loosely coupled architecture for
multimodal user interfaces, which allows for co-resident and
distributed implementations, and focuses on the role of markup and
scripting, and the use of well defined interfaces between its
constituents.</p>
</div>

<div>
<h2><a name="status" id="status" />Status of this Document</h2>

<p>This section describes the status of this document at the time
of its publication. Other documents may supersede this document. A
list of current W3C publications and the latest revision of this
technical report can be found in the <a
href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</p>

<p>This is the 12 January 2012 W3C Candidate Recommendation of
"Multimodal Architecture and Interfaces". W3C publishes a technical
report as a Candidate Recommendation to indicate that the document
is believed to be stable, and to encourage implementation by the
developer community.</p>

<p>This document has been produced as part of the W3C <a
href="http://www.w3.org/2002/mmi/Activity.html">Multimodal
Interaction Activity</a>, following the procedures set out for the
<a href="http://www.w3.org/Consortium/Process/">W3C Process</a>.
The authors of this document are members of the <a
href="http://www.w3.org/2002/mmi/">Multimodal Interaction Working
Group</a>.</p>

<p>This document was produced by a group operating under the <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
February 2004 W3C Patent Policy</a>. W3C maintains a <a
href="http://www.w3.org/2004/01/pp-impl/34607/status"
rel="disclosure">public list of any patent disclosures</a> made in
connection with the deliverables of the group; that page also
includes instructions for disclosing a patent. An individual who
has actual knowledge of a patent which the individual believes
contains <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
Essential Claim(s)</a> must disclose the information in accordance
with <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
section 6 of the W3C Patent Policy</a>.</p>

<p>Publication as a Candidate Recommendation does not imply
endorsement by the W3C Membership. This is a draft document and may
be updated, replaced or obsoleted by other documents at any time.
It is inappropriate to cite this document as other than work in
progress.</p>

<p>There is no normative change since the <a
href="http://www.w3.org/TR/2011/WD-mmi-arch-20110906/">second Last
Call Working Draft</a> in September 2011, though several
clarifications had been added to the <a
href="http://www.w3.org/TR/2011/WD-mmi-arch-20110906/">second Last
Call Working Draft</a> in order to address detailed feedback from
the Multimodal public list. Please check the <a
href="mmi-arch-disp.html">Disposition of Comments</a> received
during the first Last Call period. A <a
href="diff.html">diff-marked version</a> of this document is also
available for comparison purposes.</p>

<p>The entrance criteria to the Proposed Recommendation phase
require at least two independently developed interoperable
implementations of each feature. Detailed implementation
requirements and the invitation for participation in the
Implementation Report are provided in the <a
href="http://www.w3.org/2002/mmi/2012/mmi-arch-irp/Overview.html">Implementation
Report Plan</a>. We expect to meet all requirements of that report
within the Candidate Recommendation period closing <em>29 February
2012</em>. The Multimodal Interaction Working Group will advance
Multimodal Architecture and Interfaces to Proposed Recommendation
no sooner than <em>29 February 2012.</em></p>

<p>The following features in the current draft specification are
considered to be at risk of removal due to potential lack of
implementations:</p>

<ul>
<li>The Confidential field in all life-cycle events.</li>

<li>The RequestAutomaticUpdate field of the StatusRequest
message.</li>

<li>The AutomaticUpdate field of the StatusResponse message.</li>
</ul>

<p>Comments for this specification are welcomed until 29 February
2012 and should have a subject starting with the prefix '[ARCH]'.
Please send them to &lt;<a
href="mailto:www-multimodal@w3.org">www-multimodal@w3.org</a>&gt;,
the public email list for issues related to Multimodal. This list
is <a
href="http://lists.w3.org/Archives/Public/www-multimodal/">archived</a>
and acceptance of this archiving policy is requested automatically
upon first post. To subscribe to this list send an email to &lt;<a
href="mailto:www-multimodal-request@w3.org">www-multimodal-request@w3.org</a>&gt;
with the word subscribe in the subject line.</p>

<p>For more information about the Multimodal Interaction Activity,
please see the <a
href="http://www.w3.org/2002/mmi/Activity">Multimodal Interaction
Activity statement</a>.</p>
</div>

<div class="toc">
<h2><a name="contents" id="contents" />Table of Contents</h2>

<p class="toc">1 <a href="#terminology">Conformance
Requirements</a><br />
2 <a href="#d3e274">Summary</a><br />
3 <a href="#overview">Overview</a><br />
4 <a href="#Design">Design versus Run-Time considerations</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.1 <a href="#d3e327">Markup and The
Design-Time View</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.2 <a href="#Runtime">Software
Constituents and The Run-Time View</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;4.3 <a
href="#Relationship_to_EMMA">Relationship to EMMA</a><br />
5 <a href="#OverviewConstituents">Overview of
Architecture</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#ArchDiagram">Run-Time
Architecture Diagram</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="#Constitents">The
Constituents</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.1 <a
href="#d3e395">The Interaction Manager</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.2 <a
href="#d3e423">The Data Component</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.3 <a
href="#ModalityComponents">The Modality Components</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.4 <a
href="#d3e443">The Runtime Framework</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.4.1
<a href="#d3e448">The Event Transport Layer</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.4.1.1
<a href="#security">Event and Information Security</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.5 <a
href="#d3e502">System and OS Security</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.6 <a
href="#d3e509">Media stream handling</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5.2.7 <a
href="#ConstituentExamples">Examples</a><br />
6 <a href="#Interfaces">Interface between the Interaction Manager
and the Modality Components</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href="#ComponentInterface">Common
Event Fields</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.1 <a
href="#ContextField">Context</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.2 <a
href="#SourceField">Source</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.3 <a
href="#TargetField">Target</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.4 <a
href="#RequestIDField">RequestID</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.5 <a
href="#StatusField">Status</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.6 <a
href="#StatusInfoField">StatusInfo</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.7 <a
href="#DataField">Data</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.1.8 <a
href="#ConfidentialField">Confidential</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;6.2 <a href="#LifeCycleEvents">Standard
Life Cycle Events</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.1 <a
href="#d3e666">NewContextRequest/NewContextResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.1.1
<a href="#d3e683">NewContextRequest Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.1.2
<a href="#d3e717">NewContextResponse Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.2 <a
href="#d3e781">PrepareRequest/PrepareResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.2.1
<a href="#d3e806">PrepareRequest Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.2.2
<a href="#d3e880">PrepareResponse Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.3 <a
href="#StartRequest">StartRequest/StartResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.3.1
<a href="#d3e960">StartRequest Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.3.2
<a href="#d3e1031">StartResponse Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.4 <a
href="#d3e1089">DoneNotification</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.4.1
<a href="#d3e1097">DoneNotification Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.5 <a
href="#d3e1157">CancelRequest/CancelResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.5.1
<a href="#d3e1171">CancelRequest Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.5.2
<a href="#d3e1214">CancelResponse Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.6 <a
href="#d3e1272">PauseRequest/PauseResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.6.1
<a href="#d3e1283">PauseRequest Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.6.2
<a href="#d3e1326">PauseResponse Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.7 <a
href="#d3e1384">ResumeRequest/ResumeResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.7.1
<a href="#d3e1407">ResumeRequest Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.7.2
<a href="#d3e1450">ResumeResponse Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.8 <a
href="#d3e1508">ExtensionNotification</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.8.1
<a href="#d3e1519">ExtensionNotification Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.9 <a
href="#d3e1566">ClearContextRequest/ClearContextResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.9.1
<a href="#d3e1580">ClearContextRequest Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.9.2
<a href="#d3e1623">ClearContextResponse Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.10 <a
href="#d3e1681">StatusRequest/StatusResponse</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.10.1
<a href="#d3e1692">Status Request Properties</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;6.2.10.2
<a href="#d3e1748">StatusResponse Properties</a><br />
</p>

<h3><a name="appendices" id="appendices" />Appendices</h3>

<p class="toc">A <a href="#d3e1824">Modality Component
States</a><br />
B <a href="#EventExamples">Examples of Life-Cycle Events</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#d3e1945">NewContextRequest
(from MC to IM)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#d3e1950">NewContextResponse
(from IM to MC)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.3 <a href="#d3e1955">PrepareRequest (from
IM to MC, with external markup)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.4 <a href="#d3e1960">PrepareRequest (from
IM to MC, inline VoiceXML markup)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.5 <a href="#d3e1965">PrepareResponse
(from MC to IM, Success)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.6 <a href="#d3e1970">PrepareResponse
(from MC to IM, Failure)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.7 <a href="#d3e1975">StartRequest (from
IM to MC)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.8 <a href="#d3e1980">StartResponse (from
MC to IM)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.9 <a href="#d3e1985">DoneNotification
(from MC to IM, with EMMA result)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.10 <a href="#d3e1992">DoneNotification
(from MC to IM, with EMMA "no-input" result)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.11 <a href="#d3e1997">CancelRequest (from
IM to MC)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.12 <a href="#d3e2002">CancelResponse
(from MC to IM)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.13 <a href="#d3e2007">PauseRequest (from
IM to MC)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.14 <a href="#d3e2012">PauseResponse (from
MC to IM)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.15 <a href="#d3e2017">ResumeRequest (from
IM to MC)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.16 <a href="#d3e2022">ResumeResponse
(from MC to IM)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.17 <a
href="#d3e2027">ExtensionNotification (formerly the data event,
sent in both directions)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.18 <a href="#d3e2032">ClearContextRequest
(from the IM to MC)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.19 <a
href="#d3e2037">ClearContextResponse (from the MC to IM)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.20 <a href="#d3e2042">StatusRequest (from
the IM to the MC)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;B.21 <a href="#d3e2047">StatusResponse
(from the MC to the IM)</a><br />
C <a href="#Schema">Event Schemas</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.1 <a href="#d3e2057">mmi.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.2 <a
href="#d3e2062">mmi-datatypes.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.3 <a
href="#d3e2067">mmi-attribs.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.4 <a
href="#d3e2072">mmi-elements.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.5 <a
href="#d3e2077">NewContextRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.6 <a
href="#d3e2082">NewContextResponse.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.7 <a
href="#d3e2087">PrepareRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.8 <a
href="#d3e2092">PrepareResponse.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.9 <a
href="#d3e2097">StartRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.10 <a
href="#d3e2102">StartResponse.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.11 <a
href="#d3e2107">DoneNotification.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.12 <a
href="#d3e2112">CancelRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.13 <a
href="#d3e2117">CancelResponse.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.14 <a
href="#d3e2122">PauseRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.15 <a
href="#d3e2127">PauseResponse.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.16 <a
href="#d3e2132">ResumeRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.17 <a
href="#d3e2137">ResumeResponse.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.18 <a
href="#d3e2142">ExtensionNotification.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.19 <a
href="#d3e2147">ClearContextRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.20 <a
href="#d3e2152">ClearContextResponse.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.21 <a
href="#d3e2157">StatusRequest.xsd</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;C.22 <a
href="#d3e2162">StatusResponse.xsd</a><br />
D <a href="#LadderDiagrams">Ladder Diagrams for the MMI
Architecture with a Web Browser and VXML Interpreter</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;D.1 <a href="#d3e2171">Creating a
Session</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;D.2 <a href="#d3e2187">Processing User
Input</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;D.3 <a href="#d3e2195">Ending a
Session</a><br />
E <a href="#LocalizationCustomization">Localization and
Customization</a><br />
F <a href="#HTTPTransport">HTTP transport of MMI lifecycle
events</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;F.1 <a href="#d3e2240">Lifecycle event
transport from modality components to Interaction Manager</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;F.2 <a href="#d3e2332">Lifecycle event
transport from IM to modality components (HTTP clients
only)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;F.3 <a href="#d3e2419">Lifecycle event
transport from Interaction Manager to modality components (HTTP
servers)</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;F.4 <a href="#d3e2435">Error
handling</a><br />
G <a href="#glossary">Glossary</a><br />
H <a href="#creating_MC">Types of Modality Components</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;H.1 <a
href="#Simple_modality_components">Simple modality
components</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;H.2 <a
href="#Complex_modality_components">Complex modality
components</a><br />
&nbsp;&nbsp;&nbsp;&nbsp;H.3 <a
href="#Nested_modality_components">Nested modality
components</a><br />
I <a href="#references">Normative References</a><br />
J <a href="#d3e2590">Informative References</a><br />
</p>
</div>

<hr />
<div class="body">
<div class="div1">
<h2><a name="terminology" id="terminology" />1 Conformance
Requirements</h2>

<p>An implementation is conformant with the MMI Architecture if it
consists of one or more software constituents that are conformant
with the MMI Life-Cycle Event specification.</p>

<p>A constituent is conformant with the MMI Life-Cycle Event
specification if it supports the Life-Cycle Event interface between
the Interaction Manager and the Modality Component defined in <a
href="#Interfaces"><b>6 Interface between the Interaction Manager
and the Modality Components</b></a>. To support the Life-Cycle
Event interface, a constituent must be able to handle all
Life-Cycle events defined in <a href="#LifeCycleEvents"><b>6.2
Standard Life Cycle Events</b></a> either as an Interaction Manager
or as a Modality Component or as both.</p>

<p>Transport and format of Life-Cycle Event messages may be
implemented in any manner, as long as their contents conform to the
standard Life-Cycle Event definitions given in <a
href="#LifeCycleEvents"><b>6.2 Standard Life Cycle Events</b></a>.
Any implementation that uses XML format to represent the life-cycle
events must comply with the normative MMI XML schemas contained in
<a href="#Schema"><b>C Event Schemas</b></a>.</p>

<p>The key words <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em>, <em title="MUST NOT in RFC2119 context"
class="RFC2119">MUST NOT</em>, <em
title="REQUIRED in RFC2119 context" class="RFC2119">REQUIRED</em>,
<em title="SHALL in RFC2119 context" class="RFC2119">SHALL</em>,
<em title="SHALL NOT in RFC2119 context" class="RFC2119">SHALL
NOT</em>, <em title="SHOULD in RFC2119 context"
class="RFC2119">SHOULD</em>, <em
title="SHOULD NOT in RFC2119 context" class="RFC2119">SHOULD
NOT</em>, <em title="RECOMMENDED in RFC2119 context"
class="RFC2119">RECOMMENDED</em>, <em
title="MAY in RFC2119 context" class="RFC2119">MAY</em>, and <em
title="OPTIONAL in RFC2119 context" class="RFC2119">OPTIONAL</em>
in this specification are to be interpreted as described in <a
href="#RFC2119">[IETF RFC 2119]</a>.</p>

<p>The terms <em title="BASE URI in RFC2119 context"
class="RFC2119">BASE URI</em> and <em
title="RELATIVE URI in RFC2119 context" class="RFC2119">RELATIVE
URI</em> are used in this specification as they are defined in <a
href="#RFC2396">[IETF RFC 2396]</a>.</p>

<p>Any section that is not marked as 'informative' is
normative.</p>
</div>

<div class="div1">
<h2><a name="d3e274" id="d3e274" />2 Summary</h2>

<p>This section is informative.</p>

<p>This document describes a loosely coupled architecture for
multimodal user interfaces, which allows for co-resident and
distributed implementations, and focuses on the role of markup and
scripting, and the use of well defined interfaces between its
constituents.</p>
</div>

<div class="div1">
<h2><a name="overview" id="overview" />3 Overview</h2>

<p>This section is informative.</p>

<p>This document describes the architecture of the Multimodal
Interaction (MMI) framework <a href="#MMIF">[MMIF]</a> and the
interfaces between its constituents. The MMI Working Group is aware
that multimodal interfaces are an area of active research and that
commercial implementations are only beginning to emerge. Therefore
we do not view our goal as standardizing a hypothetical existing
common practice, but rather providing a platform to facilitate
innovation and technical development. Thus the aim of this design
is to provide a general and flexible framework providing
interoperability among modality-specific components from different
vendors - for example, speech recognition from one vendor and
handwriting recognition from another. This framework places very
few restrictions on the individual components, but instead focuses
on providing a general means for communication, plus basic
infrastructure for application control and platform services.</p>

<p>Our framework is motivated by several basic design goals:</p>

<ul>
<li>Encapsulation. The architecture should make no assumptions
about the internal implementation of components, which will be
treated as black boxes.</li>

<li>Distribution. The architecture should support both distributed
and co-hosted implementations.</li>

<li>Extensibility. The architecture should facilitate the
integration of new modality components. For example, given an
existing implementation with voice and graphics components, it
should be possible to add a new component (for example, a biometric
security component) without modifying the existing components.</li>

<li>Recursiveness. The architecture should allow for nesting, so
that an instance of the framework consisting of several components
can be packaged up to appear as a single component to a
higher-level instance of the architecture.</li>

<li>Modularity. The architecture should provide for the separation
of data, control, and presentation.</li>
</ul>

<p>Even though multimodal interfaces are not yet common, the
software industry as a whole has considerable experience with
architectures that can accomplish these goals. Since the 1980s, for
example, distributed message-based systems have been common. They
have been used for a wide range of tasks, including in particular
high-end telephony systems. In this paradigm, the overall system is
divided up into individual components which communicate by sending
messages over the network. Since the messages are the only means of
communication, the internals of components are hidden and the
system may be deployed in a variety of topologies, either
distributed or co-located. One specific instance of this type of
system is the DARPA Hub Architecture, also known as the Galaxy
Communicator Software Infrastructure <a
href="#Communicator">[Galaxy]</a>. This is a distributed,
message-based, hub-and-spoke infrastructure designed for
constructing spoken dialogue systems. It was developed in the late
1990's and early 2000's under funding from DARPA. This
infrastructure includes a program called the Hub, together with
servers which provide functions such as speech recognition, natural
language processing, and dialogue management. The servers
communicate with the Hub and with each other using key-value
structures called frames.</p>

<p>Another recent architecture that is relevant to our concerns is
the model-view-controller (MVC) paradigm. This is a well known
design pattern for user interfaces in object oriented programming
languages, and has been widely used with languages such as Java,
Smalltalk, C, and C++. The design pattern proposes three main
parts: <em>a Data Model</em> that represents the underlying logical
structure of the data and associated integrity constraints, one or
more <em>Views</em> which correspond to the objects that the user
directly interacts with, and <em>a Controller</em> which sits
between the data model and the views. The separation between data
and user interface provides considerable flexibility in how the
data is presented and how the user interacts with that data. While
the MVC paradigm has been traditionally applied to graphical user
interfaces, it lends itself to the broader context of multimodal
interaction where the user is able to use a combination of visual,
aural and tactile modalities.</p>
</div>

<div class="div1">
<h2><a name="Design" id="Design" />4 Design versus Run-Time
considerations</h2>

<p>This section is informative.</p>

<p>In discussing the design of MMI systems, it is important to keep
in mind the distinction between the design-time view (i.e., the
markup) and the run-time view (the software that executes the
markup). At the design level, we assume that multimodal
applications will take the form of multiple documents from
different namespaces. In many cases, the different namespaces and
markup languages will correspond to different modalities, but we do
not require this. A single language may cover multiple modalities
and there may be multiple languages for a single modality.</p>

<p>At runtime, the MMI architecture features loosely coupled
software constituents that may be either co-resident on a device or
distributed across a network. In keeping with the loosely-coupled
nature of the architecture, the constituents do not share context
and communicate only by exchanging events. The nature of these
constituents and the APIs between them is discussed in more detail
in Sections 3-5, below. Though nothing in the MMI architecture
requires that there be any particular correspondence between the
design-time and run-time views, in many cases there will be a
specific software component responsible for each different markup
language (namespace).</p>

<div class="div2">
<h3><a name="d3e327" id="d3e327" />4.1 Markup and The Design-Time
View</h3>

<p>At the markup level, an application consists of multiple
documents. A single document may contain markup from different
namespaces if the interaction of those namespaces has been defined.
By the principle of encapsulation, however, the internal structure
of documents is invisible at the MMI level, which defines only how
the different documents communicate. One document has a special
status, namely the Root or Controller Document, which contains
markup defining the interaction between the other documents. Such
markup is called Interaction Manager markup. The other documents
are called Presentation Documents, since they contain markup to
interact directly with the user. The Controller Document may
consist solely of Interaction Manager markup (for example a state
machine defined in CCXML <a href="#CCXML">[CCXML]</a> or SCXML <a
href="#SCXML">[SCXML]</a>) or it may contain Interaction Manager
markup combined with presentation or other markup. As an example of
the latter design, consider a multimodal application in which a
CCXML document provides call control functionality as well as the
flow control for the various Presentation documents. Similarly, an
SCXML flow control document could contain embedded presentation
markup in addition to its native Interaction Management markup.</p>

<p>These relationships are recursive, so that any Presentation
Document may serve as the Controller Document for another set of
documents. This nested structure is similar to 'Russian Doll' model
of Modality Components, described below in <a
href="#Runtime"><b>4.2 Software Constituents and The Run-Time
View</b></a>.</p>

<p>The different documents are loosely coupled and co-exist without
interacting directly. Note in particular that there are no shared
variables that could be used to pass information between them.
Instead, all runtime communication is handled by events, as
described below in <a href="#Interfaces"><b>6 Interface between the
Interaction Manager and the Modality Components</b></a>. Note,
however, that this only applies to non-root documents. The IM,
which loads the root document, interacts with "other components".
I.e., the IM (having the root-document) interacts directly through
life-cycle events with Modality Components (having different
documents and/or namespaces).</p>

<p>Furthermore, it is important to note that the asynchronicity of
the underlying communication mechanism does not impose the
requirement that the markup languages present a purely asynchronous
programming model to the developer. Given the principle of
encapsulation, markup languages are not required to reflect
directly the architecture and APIs defined here. As an example,
consider an implementation containing a Modality Component
providing Text-to-Speech (TTS) functionality. This Component must
communicate with the Interaction Manager via asynchronous events
(see <a href="#Runtime"><b>4.2 Software Constituents and The
Run-Time View</b></a>). In a typical implementation, there would
likely be events to start a TTS play and to report the end of the
play, etc. However, the markup and scripts that were used to author
this system might well offer only a synchronous "play TTS" call, it
being the job of the underlying implementation to convert that
synchronous call into the appropriate sequence of asynchronous
events. In fact, there is no requirement that the TTS resource be
individually accessible at all. It would be quite possible for the
markup to present only a single "play TTS and do speech
recognition" call, which the underlying implementation would
realize as a series of asynchronous events involving multiple
Components.</p>

<p>Existing languages such as HTML may be used as either the
Controller Documents or as Presentation Documents. Further examples
of potential markup components are given in <a
href="#ConstituentExamples"><b>5.2.7 Examples</b></a></p>
</div>

<div class="div2">
<h3><a name="Runtime" id="Runtime" />4.2 Software Constituents and
The Run-Time View</h3>

<p>At the core of the MMI runtime architecture is the distinction
between the Interaction Manager (IM) and the Modality Components,
which is similar to the distinction between the Controller Document
and the Presentation Documents. The Interaction Manager interprets
the Controller Document while the individual Modality Components
are responsible for specific tasks, particularly handling input and
output in the various modalities, such as speech, pen, video,
etc.</p>

<p>The Interaction Manager receives all the events that the various
Modality Components generate. Those events may be commands or
replies to commands, and it is up to the Interaction Manager to
decide what to do with them, i.e., what events to generate in
response to them. In general, the MMI architecture follows a
'targetless' event model. That is, the Component that raises an
event does not specify its destination. Rather, it passes it up to
the Runtime Framework, which will pass it to the Interaction
Manager. The IM, in turn, decides whether to forward the event to
other Components, or to generate a different event, etc.</p>

<p>Modality Components are black boxes, required only to implement
the Modality Component Interface API which is described below. This
API allows the Modality Components to communicate with the IM and
thus indirectly with each other, since the IM is responsible for
delivering events/messages among the Components. Since the
internals of a Component are hidden, it is possible for an
Interaction Manager and a set of Components to present themselves
as a Component to a higher-level Interaction Manager. All that is
required is that the IM implement the Component API. The result is
a "Russian Doll" model in which Components may be nested inside
other Components to an arbitrary depth. Nesting components in this
manner is one way to produce a 'complex' Modality Component, namely
one that handles multiple modalities simultaneously. However, it is
also possible to produce complex Modality Components without
nesting, as discussed in <a href="#ModalityComponents"><b>5.2.3 The
Modality Components</b></a>.</p>

<p>In addition to the Interaction Manager and the modality
components, there is a Runtime Framework that provides
infrastructure support, in particular a transport layer which
delivers events among the components.</p>

<p>Because we are using the term 'Component' to refer to a specific
set of entities in our architecture, we will use the term
'Constituent' as a cover term for all the elements in our
architecture which might normally be called 'software
components'.</p>
</div>

<div class="div2">
<h3><a name="Relationship_to_EMMA" id="Relationship_to_EMMA" />4.3
Relationship to EMMA</h3>

<p>The Extended Multimodal Annotation Language <a
href="#EMMA">[EMMA]</a>, is a set of specifications for multimodal
systems, and provides details of an XML markup language for
containing and annotating the interpretation of user input. For
example, a user of a multimodal application might use both speech
to express a command, and keystroke gesture to select or draw
command parameters. The Speech Recognition Modality would express
the user command using EMMA to indicate the input source (speech).
The Pen Gesture Modality would express the command parameters using
EMMA to indicate the input source (pen gestures). Both modalities
may include timing information in the EMMA notation. Using the
timing information, a fusion module combines the speech and pen
gesture information into a single EMMA notation representing both
the command and its parameters. The use of EMMA enables the
separation of recognition process from the information fusion
process, and thus enables reusable recognition modalities and
general purpose information fusion algorithms.</p>
</div>
</div>

<div class="div1">
<h2><a name="OverviewConstituents" id="OverviewConstituents" />5
Overview of Architecture</h2>

<p>Here is a list of the Constituents of the MMI architecture. They
are discussed in more detail below.</p>

<ul>
<li>the Interaction Manager, which coordinates the different
modalities. It is the Controller in the MVC paradigm.</li>

<li>the Data Component, which provides the common data model and
represents the Model in the MVC paradigm.</li>

<li>the Modality Components, which provide modality-specific
interaction capabilities. They are the Views in the MVC
paradigm.</li>

<li>the Runtime Framework, which provides the basic infrastructure
and enables communication among the other Constituents.</li>
</ul>

<div class="div2">
<h3><a name="ArchDiagram" id="ArchDiagram" />5.1 Run-Time
Architecture Diagram</h3>

<img class="center" src="Images/RevisedArchDiagram.png"
alt="architecture diagram" /></div>

<div class="div2">
<h3><a name="Constitents" id="Constitents" />5.2 The
Constituents</h3>

This section presents the responsibilities of the various
constituents of the MMI architecture. 

<div class="div3">
<h4><a name="d3e395" id="d3e395" />5.2.1 The Interaction
Manager</h4>

<p>All life-cycle events that the Modality Components generate <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
delivered to the Interaction Manager. All life-cycle events that
are delivered to Modality Components <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be sent
by the Interaction Manager.</p>

<p>Due to the Russian Doll model, Modality Components <em
title="MAY in RFC2119 context" class="RFC2119">MAY</em> contain
their own Interaction Managers to handle their internal events.
However these Interaction Managers are not visible to the top level
Runtime Framework or Interaction Manager.</p>

<p>If the Interaction Manager does not contain an explicit handler
for an event, it <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> respect any default behavior that has
been established for the event. If there is no default behavior,
the Interaction Manager <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> ignore the event. (In effect, the
Interaction Manager's default handler for all events is to ignore
them.)</p>

<p>The following paragraph is informative.</p>

<p>Normally there will be specific markup associated with the IM
instructing it how to respond to events. This markup will thus
contain a lot of the most basic interaction logic of an
application. Existing languages such as SMIL, CCXML, SCXML, or
ECMAScript can be used for IM markup as an alternative to defining
special-purpose languages aimed specifically at multimodal
applications. The IM fulfills multiple functions. For example, it
is responsible for synchronization of data and focus, etc., across
different Modality Components as well as the higher-level
application flow that is independent of Modality Components. It
also maintains the high-level application data model and may handle
communication with external entities and back-end systems.
Logically these functions could be separated into separate
constituents and implementations may want to introduce internal
structure to the IM. However, for the purposes of this standard, we
leave the various functions rolled up in a single monolithic
Interaction Manager component. We note that state machine languages
such as SCXML are a good choice for authoring such a multi-function
component, since state machines can be composed. Thus it is
possible to define a high-level state machine representing the
overall application flow, with lower-level state machines nested
inside it handling the the cross-modality synchronization at each
phase of the higher-level flow.</p>
</div>

<div class="div3">
<h4><a name="d3e423" id="d3e423" />5.2.2 The Data Component</h4>

<p>This section is informative.</p>

<p>The Data Component is responsible for storing application-level
data. The Interaction Manager is a client of the Data Component and
is able to access and update it as part of its control flow logic,
but Modality Components do not have direct access to it. Since
Modality Components are black boxes, they may have their own
internal Data Components and may interact directly with backend
servers. However, the only way that Modality Components can share
data among themselves and maintain consistency is via the
Interaction Manager. It is therefore a good application design
practice to divide data into two logical classes: private data,
which is of interest only to a given modality component, and public
data, which is of interest to the Interaction Manager or to more
than one Modality Component. Private data may be managed as the
Modality Component sees fit, but all modification of public data,
including submission to back end servers, should be entrusted to
the Interaction Manager.</p>

<p>This specification does not define an interface between the Data
Component and the Interaction Manager. This amounts to treating the
Data Component as part of the Interaction Manager. (Note that this
means that the data access language will be whatever one the IM
provides.) The Data Component is shown with a dotted outline in the
diagram above, however, because it is logically distinct and could
be placed in a separate component.</p>
</div>

<div class="div3">
<h4><a name="ModalityComponents" id="ModalityComponents" />5.2.3
The Modality Components</h4>

<p>This section is informative.</p>

<p>Modality Components, as their name would indicate, are
responsible for controlling the various input and output modalities
on the device. They are therefore responsible for handling all
interaction with the user(s). Their only responsibility is to
implement the interface defined in <a href="#Interfaces"><b>6
Interface between the Interaction Manager and the Modality
Components</b></a>. Any further definition of their
responsibilities will be highly domain- and application-specific.
In particular we do not define a set of standard modalities or the
events that they should generate or handle. Platform providers are
allowed to define new Modality Components and are allowed to place
into a single Component functionality that might logically seem to
belong to two or more different modalities. Thus a platform could
provide a handwriting-and-speech Modality Component that would
accept simultaneous voice and pen input. Such combined Components
permit a much tighter coupling between the two modalities than the
loose interface defined here. Furthermore, modality components may
be used to perform general processing functions not directly
associated with any specific interface modality, for example,
dialog flow control or natural language processing.</p>

<p>In most cases, there will be specific markup in the application
corresponding to a given modality, specifying how the interaction
with the user should be carried out. However, we do not require
this and specifically allow for a markup-free modality component
whose behavior is hard-coded into its software.</p>
</div>

<div class="div3">
<h4><a name="d3e443" id="d3e443" />5.2.4 The Runtime Framework</h4>

<p>The Runtime Framework is a cover term for all the infrastructure
services that are necessary for successful execution of a
multimodal application. This includes starting the components,
handling communication, and logging, etc. For the most part, this
version of the specification leaves these functions to be defined
in a platform-specific way, but we do specifically define a
Transport Layer which handles communications between the
components.</p>

<div class="div4">
<h5><a name="d3e448" id="d3e448" />5.2.4.1 The Event Transport
Layer</h5>

<p>The Event Transport Layer is responsible for delivering events
among the IM and the Modality Components. Clearly, there are
multiple transport mechanisms (protocols) that can be used to
implement a Transport Layer and different mechanisms may be used to
communicate with different modality components. Thus the Event
Transport Layer consists of one or more transport mechanisms
linking the IM to the various Modality Components.</p>

<p>We place the following requirements on all transport
mechanisms:</p>

<ol>
<li>Events <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> be delivered reliably. In particular, the
event delivery mechanism <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> report an error if an event can not be
delivered, for example if the destination endpoint is
unavailable.</li>

<li>Events <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> be delivered to the destination in the
order in which the source generated them. There is no guarantee on
the delivery order of events generated by different sources. For
example, if Modality Component M1 generates events E1 and E2 in
that order, while Modality Component M2 generates E3 and then E4,
we require that E1 be delivered to the Runtime Framework before E2
and that E3 be delivered before E4, but there is no guarantee on
the ordering of E1 or E2 versus E3 or E4.</li>
</ol>

<p>For a sample definition of a Transport Layer relying on HTTP,
see <a href="#HTTPTransport"><b>F HTTP transport of MMI lifecycle
events</b></a>. This definition is provided as an example only.</p>

<div class="div5">
<h6><a name="security" id="security" />5.2.4.1.1 Event and
Information Security</h6>

<p>This section is informative.</p>

<p>Events will often carry sensitive information, such as bank
account numbers or health care information. In addition events must
also be reliable to both sides of transaction: for example, if an
event carries an assent to a financial transaction, both sides of
the transaction must be able to rely on that assent.</p>

<p>We do not currently specify delivery mechanisms or internal
security safeguards to be used by the Modality Components and the
Interaction Manager. However, we believe that any secure system
will have to meet the following requirements at a minimum:</p>

<p>The following two optional requirements can be met by using the
W3C's XML-Signature Syntax and Processing specification <a
href="#XMLSig">[XMLSig]</a>.</p>

<ol>
<li>Authentication. The event delivery mechanism should be able to
ensure that the identity of components in an interaction are
known.</li>

<li>Integrity. The event delivery mechanism should be able to
ensure that the contents of events have not been altered in
transit. 

<p>The remaining optional requirements for event delivery and
information security can be met by following other
industry-standard procedures.</p>
</li>

<li>Authorization. A component should provide a method to ensure
only authorized components can connect to it.</li>

<li>Privacy. The event delivery mechanism should provide a method
to keep the message contents secure from any unauthorized access
while in transit.</li>

<li>Non-repudiation. The event delivery mechanism, in conjunction
with the components, may provide a method to ensure that if a
message is sent from one constituent to another, the originating
constituent cannot repudiate the message that it sent and that the
receiving constituent cannot repudiate that the message was
received.</li>
</ol>

<p>Multiple protocols may be necessary to implement these
requirements. For example, TCP/IP and HTTP provide reliable event
delivery, but additional protocols such as TLS or HTTPS could be
required to meet security requirements.</p>
</div>
</div>
</div>

<div class="div3">
<h4><a name="d3e502" id="d3e502" />5.2.5 System and OS
Security</h4>

<p>This section is informative.</p>

<p>This architecture does not and will not specify the internal
security requirements of a Modality Component or Runtime
Framework.</p>
</div>

<div class="div3">
<h4><a name="d3e509" id="d3e509" />5.2.6 Media stream handling</h4>

<p>Media streams do not typically flow through the Interaction
Manager. This specification does not specify how media connections
are established, as the main focus of this specification is the
flow of control data. However, all control data logically sent
between modality components <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> flow through the Interaction Manager.</p>
</div>

<div class="div3">
<h4><a name="ConstituentExamples" id="ConstituentExamples" />5.2.7
Examples</h4>

<p>This section is informative.</p>

<p>For the sake of concreteness, here are some examples of
components that could be implemented using existing languages. Note
that we are mixing the design-time and run-time views here, since
it is the implementation of the language (the browser) that serves
as the run-time component.</p>

<ul>
<li>CCXML <a href="#CCXML">[CCXML]</a>could be used as both the
Controller Document and the Interaction Manager language, with the
CCXML interpreter serving as the Runtime Framework and Interaction
Manager.</li>

<li>SCXML <a href="#SCXML">[SCXML]</a> could be used as the
Controller Document and Interaction Manager language</li>

<li>In an integrated multimodal browser, the markup language that
provided the document root tag would define the Controller Document
while the associated scripting language could serve as the
Interaction Manager.</li>

<li>HTML <a href="#HTML">[HTML]</a> could be used as the markup for
a Modality Component.</li>

<li>VoiceXML <a href="#VoiceXML">[VoiceXML]</a>could be used as the
markup for a Modality Component.</li>

<li>SVG <a href="#SVG">[SVG]</a> could be used as the markup for a
Modality Component.</li>

<li>SMIL <a href="#SMIL">[SMIL]</a>could be used as the markup for
a Modality Component.</li>
</ul>
</div>
</div>
</div>

<div class="div1">
<h2><a name="Interfaces" id="Interfaces" />6 Interface between the
Interaction Manager and the Modality Components</h2>

<p>The most important interface in this architecture is the one
between the Modality Components and the Interaction Manager.
Modality Components communicate with the IM via asynchronous
events. Constituents <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> be able to send events and to handle
events that are delivered to them asynchronously. It is not
required that Constituents use these events internally since the
implementation of a given Constituent is black box to the rest of
the system. In general, it is expected that Constituents will send
events both automatically (i.e., as part of their implementation)
and under mark-up control.</p>

<p>The majority of the events defined here come in request/response
pairs. That is, one party (either the IM or an MC) sends a request
and the other returns a response. (The exceptions are the
ExtensionNotification, StatusRequest and StatusResponse events,
which can be sent by either party.) In each case it is specified
which party sends the request and which party returns the response.
If the wrong party sends a request or response, or if the request
or response is sent under the wrong conditions (e.g. response
without a previous request) the behavior of the receiving party is
undefined. In the descriptions below, we say that the originating
party <em title="&quot;MAY&quot; in RFC2119 context"
class="RFC2119">"MAY"</em> send the request, because it is up to
the internal logic of the originating party to decide if it wants
to invoke the behavior that the request would trigger. On the other
hand, we say that the receiving party <em
title="&quot;MUST&quot; in RFC2119 context"
class="RFC2119">"MUST"</em> send the response, because it is
mandatory to send the response if and when the request is
received.</p>

<div class="div2">
<h3><a name="ComponentInterface" id="ComponentInterface" />6.1
Common Event Fields</h3>

<p>The concept of 'context' is basic to these events described
below. A context represents a single extended interaction with zero
or more users across one or more modality components. In a simple
unimodal case, a context can be as simple as a phone call or SSL
session. Multimodal cases are more complex, however, since the
various modalities may not be all used at the same time. For
example, in a voice-plus-web interaction, e.g., web sharing with an
associated VoIP call, it would be possible to terminate the web
sharing and continue the voice call, or to drop the voice call and
continue via web chat. In these cases, a single context persists
across various modality configurations. In general, the 'context'
<em title=" SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
cover the longest period of interaction over which it would make
sense for components to store information.</p>

<p>For examples of the concrete XML syntax for all these events,
see <a href="#EventExamples"><b>B Examples of Life-Cycle
Events</b></a></p>

<p>The following common fields are shared by multiple life-cycle
events:</p>

<div class="div3">
<h4><a name="ContextField" id="ContextField" />6.1.1 Context</h4>

<p>A URI that <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> be unique for the lifetime of the system.
It is used to identify this interaction. All events relating to a
given interaction <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> use the same context URI. Events
containing a different context URI <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
interpreted as part of other, unrelated, interactions.</p>
</div>

<div class="div3">
<h4><a name="SourceField" id="SourceField" />6.1.2 Source</h4>

<p>A URI representing the address of the sender of the event. The
recipient of the event <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> be able to send an event back to the
sender by using this value as the 'target' of a message.</p>
</div>

<div class="div3">
<h4><a name="TargetField" id="TargetField" />6.1.3 Target</h4>

<p>A URI that <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> represent the address to which the event
will be delivered.</p>
</div>

<div class="div3">
<h4><a name="RequestIDField" id="RequestIDField" />6.1.4
RequestID</h4>

<p>A unique identifier for a Request/Response pair. Most life-cycle
events come in Request/Response pairs that share a common
RequestID. For any such pair, the RequestID in the Response event
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> match
the RequestID in the request event. The RequestID for such a pair
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
unique within the given context.</p>
</div>

<div class="div3">
<h4><a name="StatusField" id="StatusField" />6.1.5 Status</h4>

<p>An enumeration of 'Success' and 'Failure'. The Response event of
a Request/Response pair <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> use this field to report whether it
succeeded in carrying out the request.</p>
</div>

<div class="div3">
<h4><a name="StatusInfoField" id="StatusInfoField" />6.1.6
StatusInfo</h4>

<p>The Response event of a Request/Response pair <em
title="MAY in RFC2119 context" class="RFC2119">MAY</em> use this
field to provide additional status information.</p>
</div>

<div class="div3">
<h4><a name="DataField" id="DataField" />6.1.7 Data</h4>

<p>Any event <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> use this field to contain arbitrary data.
The format and meaning of this data is application-specific.</p>
</div>

<div class="div3">
<h4><a name="ConfidentialField" id="ConfidentialField" />6.1.8
Confidential</h4>

<p>Any event <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> use this field to indicate whether the
contents of this event are confidential. The default value is
'false'. If the value is 'true', the Interaction Manager and
Modality Component implementations <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> not log
the information or make it available in any way to third parties
unless explicitly instructed to do so by the author of the
application.</p>
</div>
</div>

<div class="div2">
<h3><a name="LifeCycleEvents" id="LifeCycleEvents" />6.2 Standard
Life Cycle Events</h3>

<p>The Multimodal Architecture defines the following basic
life-cycle events which the Interaction Manager and Modality
Components <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> support. These events allow the
Interaction Manager to invoke modality components and receive
results from them. They thus form the basic interface between the
IM and the Modality components. Note that the ExtensionNotification
event offers extensibility since it contains arbitrary content and
can be raised by either the IM or the Modality Components at any
time once the context has been established. For example, an
application relying on speech recognition could use the 'Extension'
event to communicate recognition results or the fact that speech
had started, etc.</p>

<p>In the definitions below, all fields are mandatory, unless
explicitly stated to be optional.</p>

<div class="div3">
<h4><a name="d3e666" id="d3e666" />6.2.1
NewContextRequest/NewContextResponse</h4>

<p>A Modality Component <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send a NewContextRequest to the IM to
request that a new context be created. If this event is sent, the
IM <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
respond with the NewContextResponse event. The NewContextResponse
event <em title="MUST ONLY in RFC2119 context" class="RFC2119">MUST
ONLY</em> be sent in response to the NewContextRequest event. Note
that the IM <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> create a new context without a previous
NewContextRequest by sending a PrepareRequest or StartRequest
containing a new context ID to the Modality Components. Furthermore
the IM may respond with the same context in response to
NewContextRequests from different (multiple) Modality Components,
since the interaction can be started by different Modality
Components independently.</p>

<div class="div4">
<h5><a name="d3e683" id="d3e683" />6.2.1.1 NewContextRequest
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>

<div class="div4">
<h5><a name="d3e717" id="d3e717" />6.2.1.2 NewContextResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the
NewContextRequest event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>. If IM has accepted the NewContextRequest, it <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> set this
field to Success and <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> include a new context identifier.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. A newly created context identifier. This field <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be empty
if status is Failure.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="d3e781" id="d3e781" />6.2.2
PrepareRequest/PrepareResponse</h4>

<p>The IM <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send a PrepareRequest to allow the
Modality Components to pre-load markup and prepare to run. Modality
Components are not required to take any particular action in
response to this event, but they <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
PrepareResponse event. Modality Components that return a
PrepareResponse event with Status of 'Success' <em
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em> be
ready to run with close to 0 delay upon receipt of the
StartRequest.</p>

<p>The Interaction Manager <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send multiple PrepareRequest events to a
Modality Component for the same Context before sending a
StartRequest. Each request <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> reference a different ContentURL or
contain different in-line Content. When it receives multiple
PrepareRequests, the Modality Component <em
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
prepare to run any of the specified content.</p>

<div class="div4">
<h5><a name="d3e806" id="d3e806" />6.2.2.1 PrepareRequest
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. Note that the IM <em title="MAY 
	 in RFC2119 context" class="RFC2119">MAY</em> use the same context
value in multiple PrepareRequest events when it wishes to execute
multiple instances of markup in the same context.</li>

<li><code>ContentURL</code> Optional URL of the content that the
Modality Component <em title="SHOULD in RFC2119 context"
class="RFC2119">SHOULD</em> prepare to execute.</li>

<li><code>Content</code> Optional Inline markup that the Modality
Component <em title="SHOULD in RFC2119 context"
class="RFC2119">SHOULD</em> prepare to execute.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>

<p>The IM <em title="MUST NOT in RFC2119 context"
class="RFC2119">MUST NOT</em> specify both the ContentURL and
Content in a single PrepareRequest. The IM <em
title="MAY in RFC2119 context" class="RFC2119">MAY</em> leave both
<code>contentURL</code> and <code>content</code> empty. In such a
case, the Modality Component <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> revert to its default behavior. For
example, this behavior could consist of returning an error event or
of running a preconfigured or hard-coded script.</p>
</div>

<div class="div4">
<h5><a name="d3e880" id="d3e880" />6.2.2.2 PrepareResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the PrepareRequest
event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the PrepareRequest
event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="StartRequest" id="StartRequest" />6.2.3
StartRequest/StartResponse</h4>

<p>To invoke a modality component, the IM <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> send a
StartRequest. The Modality Component <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
StartResponse event in response. The IM <em
title="MAY in RFC2119 context" class="RFC2119">MAY</em> include a
value in the ContentURL or Content field of this event. In this
case, the Modality Component <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> use this value.</p>

<p>If a Modality Component receives a new StartRequest while it is
executing a previous one, it <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> either cease execution of the previous
StartRequest and begin executing the content specified in the most
recent StartRequest, or reject the new StartRequest, returning a
StartResponse with status equal to 'Failure'.</p>

<div class="div4">
<h5><a name="d3e960" id="d3e960" />6.2.3.1 StartRequest
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. Note that the IM <em title="MAY 
	 in RFC2119 context" class="RFC2119">MAY</em> use the same context
value in multiple StartRequest events when it wishes to execute
multiple instances of markup in the same context.</li>

<li><code>ContentURL</code> Optional URL of the content that the
Modality Component <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> attempt to execute.</li>

<li><code>Content</code> Optional Inline markup that the Modality
Component <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> attempt to execute.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>

<p>The IM <em title="MUST NOT in RFC2119 context"
class="RFC2119">MUST NOT</em> specify both the ContentURL and
Content in a single StartRequest. The IM <em
title="MAY in RFC2119 context" class="RFC2119">MAY</em> leave both
contentURL and content empty. In such a case, the Modality
Component <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> run the content specified in the most
recent PrepareRequest in this context, if there is one. Otherwise
it <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
revert to its default behavior. For example, this behavior could
consist of returning an error event or of running a preconfigured
or hard-coded script.</p>
</div>

<div class="div4">
<h5><a name="d3e1031" id="d3e1031" />6.2.3.2 StartResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the StartRequest
event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="d3e1089" id="d3e1089" />6.2.4 DoneNotification</h4>

<p>If the Modality Component reaches the end of its processing, it
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
return a DoneNotification to the IM.</p>

<div class="div4">
<h5><a name="d3e1097" id="d3e1097" />6.2.4.1 DoneNotification
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID of the StartRequest
event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>

<p>The DoneNotification event is intended to indicate the
completion of the processing that has been initiated by the
Interaction Manager with a StartRequest. As an example a voice
modality component might use the DoneNotification event to indicate
the completion of a recognition task. In this case the
DoneNotification event might carry the recognition result expressed
using EMMA. However, there may be tasks which do not have a
specific end. For example the Interaction Manager might send a
StartRequest to a graphical modality component requesting it to
display certain information. Such a task does not necessarily have
a specific end and thus the graphical modality component might
never send a DoneNotification event to the Interaction Manager.
Thus the graphical modality component would display the screen
until it received another StartRequest (or some other lifecycle
event) from the Interaction Manager.</p>
</div>
</div>

<div class="div3">
<h4><a name="d3e1157" id="d3e1157" />6.2.5
CancelRequest/CancelResponse</h4>

<p>The IM <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send a CancelRequest to stop processing in
the Modality Component. In this case, the Modality Component <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> stop
processing and then <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> return a CancelResponse.</p>

<div class="div4">
<h5><a name="d3e1171" id="d3e1171" />6.2.5.1 CancelRequest
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>

<div class="div4">
<h5><a name="d3e1214" id="d3e1214" />6.2.5.2 CancelResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the CancelRequest
event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="d3e1272" id="d3e1272" />6.2.6
PauseRequest/PauseResponse</h4>

<p>The IM <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send a PauseRequest to suspend processing
by the Modality Component. Modality Components <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
PauseResponse once they have paused, or once they determine that
they will be unable to pause.</p>

<div class="div4">
<h5><a name="d3e1283" id="d3e1283" />6.2.6.1 PauseRequest
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>

<div class="div4">
<h5><a name="d3e1326" id="d3e1326" />6.2.6.2 PauseResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the PauseRequest
event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="d3e1384" id="d3e1384" />6.2.7
ResumeRequest/ResumeResponse</h4>

<p>The IM <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send the ResumeRequest to resume
processing that was paused by a previous PauseRequest. The IM <em
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
send the ResumeRequest to a context that is not paused due to a
previous PauseRequest. Implementations that have paused <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> attempt
to resume processing upon receipt of this event and <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> return a
ResumeResponse afterwards. The 'Status' <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
'Success' if the implementation has succeeded in resuming
processing and <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> be 'Failure' otherwise.</p>

<div class="div4">
<h5><a name="d3e1407" id="d3e1407" />6.2.7.1 ResumeRequest
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>

<div class="div4">
<h5><a name="d3e1450" id="d3e1450" />6.2.7.2 ResumeResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the ResumeRequest
event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="d3e1508" id="d3e1508" />6.2.8
ExtensionNotification</h4>

<p>This event <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> be generated by the IM and <em
title="MAY in RFC2119 context" class="RFC2119">MAY</em> be
generated by the Modality Component. It is used to encapsulate
application-specific events that are extensions to the framework
defined here. For example, if an application containing a voice
modality wanted that modality component to notify the Interaction
Manager when speech was detected, it would cause the voice modality
to generate an ExtensionNotification event ( with a 'name' of
something like 'speechDetected') at the appropriate time.</p>

<div class="div4">
<h5><a name="d3e1519" id="d3e1519" />6.2.8.1 ExtensionNotification
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Name</code>The name of the application-specific
event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="d3e1566" id="d3e1566" />6.2.9
ClearContextRequest/ClearContextResponse</h4>

<p>The IM <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send a ClearContextRequest to indicate
that the specified context is no longer active and that any
resources associated with it may be freed. Modality Components are
not required to take any particular action in response to this
command, but <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> return a ClearContextResponse. Once the
IM has sent a ClearContextRequest to a Modality Component, it <em
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
send the Modality Component any more events for that context.</p>

<div class="div4">
<h5><a name="d3e1580" id="d3e1580" />6.2.9.1 ClearContextRequest
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>

<div class="div4">
<h5><a name="d3e1623" id="d3e1623" />6.2.9.2 ClearContextResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the
ClearContextRequest event.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the value in the StartRequest
event.</li>

<li><code>Status</code> See <a href="#StatusField"><b>6.1.5
Status</b></a>.</li>

<li><code>StatusInfo</code> Optional. See <a
href="#StatusInfoField"><b>6.1.6 StatusInfo</b></a>.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>

<div class="div3">
<h4><a name="d3e1681" id="d3e1681" />6.2.10
StatusRequest/StatusResponse</h4>

<p>The StatusRequest message and the corresponding StatusResponse
are intended to provide keep-alive functionality. Either the IM or
the Modality Component <em title="MAY in RFC2119 context"
class="RFC2119">MAY</em> send the StatusRequest message. The
recipient <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> respond with the StatusResponse
message.</p>

<div class="div4">
<h5><a name="d3e1692" id="d3e1692" />6.2.10.1 Status Request
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. A newly generated identifier used to identify
this request.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. Optional specification of the context for which
the status is requested. If it is present, the recipient <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> respond
with a StatusResponse message indicating the status of the
specified context. If it is not present, the recipient <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> send a
StatusResponse message indicating the status of the underlying
server, namely the software that would host a new context if one
were created.</li>

<li><code>RequestAutomaticUpdate</code>. A boolean value. If it is
'true' the recipient <em title="SHOULD in RFC2119 context"
class="RFC2119">SHOULD</em> send periodic StatusResponse messages
without waiting for an additional StatusRequest message. If it is
'false', the recipient <em title="SHOULD in RFC2119 context"
class="RFC2119">SHOULD</em> send one and only one StatusResponse
message in response to this request.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>

<div class="div4">
<h5><a name="d3e1748" id="d3e1748" />6.2.10.2 StatusResponse
Properties</h5>

<ul>
<li><code>RequestID</code>. See <a href="#RequestIDField"><b>6.1.4
RequestID</b></a>. This <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> match the RequestID in the StatusRequest
event.</li>

<li><code>AutomaticUpdate</code>. A boolean value. If it is 'true'
the sender <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> keep sending StatusResponse messages in
the future without waiting for another StatusRequest message. If it
is 'false', the sender <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> wait for a subsequent StatusRequest
message before sending another StatusResponse message.</li>

<li><code>Context</code> See <a href="#ContextField"><b>6.1.1
Context</b></a>. An optional specification of the context for which
the status is being returned. If it is present, the response <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> represent
the status of the specified context. If it is not present, the
response <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> represent the status of the underlying
server.</li>

<li><code>Status</code> An enumeration of 'Alive' or 'Dead'. The
meaning of these values depends on whether the 'context' parameter
is present. If it is, and the specified context is still active and
capable of handling new life cycle events, the sender <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> set this
field to 'Alive'. If the 'context' parameter is present and the
context has terminated or is otherwise unable to process new life
cycle events, the sender <em title="MUST in RFC2119 context"
class="RFC2119">MUST</em> set the status to 'Dead'. If the
'context' parameter is not provided, the status refers to the
underlying server. If the sender is able to create new contexts, it
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> set
the status to 'Alive', otherwise, it <em
title="MUST in RFC2119 context" class="RFC2119">MUST</em> set it to
'Dead'.</li>

<li><code>Source</code> See <a href="#SourceField"><b>6.1.2
Source</b></a>.</li>

<li><code>Target</code> See <a href="#TargetField"><b>6.1.3
Target</b></a>.</li>

<li><code>Data</code> Optional. See <a href="#DataField"><b>6.1.7
Data</b></a>.</li>

<li><code>Confidential</code> Optional. See <a
href="#ConfidentialField"><b>6.1.8 Confidential</b></a>.</li>
</ul>
</div>
</div>
</div>
</div>
</div>

<div class="back">
<div class="div1">
<h2><a name="d3e1824" id="d3e1824" />A Modality Component
States</h2>

[This section is informative] 

<p>Within an established context, a Modality Component can be
viewed as functioning in one of three states: Idle, Running or
Paused. Lifecycle events received from the Interaction Manager
imply specific actions and transitions between states. The table
below shows possible MC actions, state transitions and response
contents for each Request event the IM may send to a MC in a
particular state.</p>

<p>A <em>Failure: ErrorMessage</em> annotation indicates that the
specified Request event is either invalid or redundant in the
specified state. In this case, the Modality Component responds by
sending a matching Response event with Status=Failure and
StatusInfo=ErrorMessage. In all other cases, the Modality performs
the requested action, possibly transitioning to another state as
indicated.</p>

<table border="1">
<tbody>
<tr>
<th width="25%">event / state</th>
<th width="25%">Idle</th>
<th width="25%">Running</th>
<th width="25%">Paused</th>
</tr>

<tr>
<td>PrepareRequest</td>
<td>preload or update content</td>
<td>preload or update content</td>
<td>preload or update content</td>
</tr>

<tr>
<td rowspan="2">StartRequest</td>
<td><em>Transition: Running</em>
<p>use new content if provided, otherwise use last available
content</p>
</td>
<td rowspan="2">stop processing current content, restart as in
Idle</td>
<td rowspan="2"><em>Transition: Running</em>
<p>stop processing current content, restart as in Idle</p>
</td>
</tr>

<tr>
<td><em>Failure: NoContent</em> if MC requires content to run and
none has been provided</td>
</tr>

<tr>
<td>CancelRequest</td>
<td><em>Ignore</em></td>
<td><em>Transition: Idle</em></td>
<td><em>Transition: Idle</em></td>
</tr>

<tr>
<td rowspan="2">PauseRequest</td>
<td rowspan="2"><em>Failure: ignore</em></td>
<td><em>Transition: Paused</em></td>
<td rowspan="2"><em>Ignore</em></td>
</tr>

<tr>
<td><em>Failure: CantPause</em> if MC is unable to pause</td>
</tr>

<tr>
<td>ResumeRequest</td>
<td><em>Ignore</em></td>
<td><em>Failure: AlreadyRunning</em></td>
<td><em>Transition: Running</em></td>
</tr>

<tr>
<td>StatusRequest</td>
<td>send status</td>
<td>send status</td>
<td>send status</td>
</tr>

<tr>
<td>ClearContextRequest</td>
<td><em>close session</em></td>
<td><em>close session</em></td>
<td><em>close session</em></td>
</tr>
</tbody>
</table>

<p>Here is a state chart representation of these transitions:</p>

<img class="center" src="Images/MC_state_diagram.png"
alt="architecture diagram" /></div>

<div class="div1">
<h2><a name="EventExamples" id="EventExamples" />B Examples of
Life-Cycle Events</h2>

[This section is informative] 

<div class="div2">
<h3><a name="d3e1945" id="d3e1945" />B.1 NewContextRequest (from MC
to IM)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
    &lt;mmi:newContextRequest mmi:source="someURI"
        mmi:target="someOtherURI" mmi:requestID="request-1"&gt;
    &lt;/mmi:newContextRequest&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1950" id="d3e1950" />B.2 NewContextResponse (from
IM to MC)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:newContextResponse mmi:source="someURI" mmi:target="someOtherURI" 
              mmi:requestID="request-1" mmi:status="success" mmi:context="URI-1"&gt;
   &lt;/mmi:newContextResponse&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1955" id="d3e1955" />B.3 PrepareRequest (from IM to
MC, with external markup)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:prepareRequest mmi:source="someURI" mmi:target="someOtherURI" 
                                  mmi:context="URI-1" mmi:requestID="request-1"&gt;
       &lt;mmi:contentURL mmi:href="someContentURI" mmi:max-age="" mmi:fetchtimeout="1s"/&gt;
   &lt;/mmi:prepareRequest&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1960" id="d3e1960" />B.4 PrepareRequest (from IM to
MC, inline VoiceXML markup)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"
    xmlns:vxml="http://www.w3.org/2001/vxml"&gt;
   &lt;mmi:prepareRequest mmi:source="someURI" mmi:target="someOtherURI" 
                       mmi:context="URI-1" mmi:requestID="request-1" &gt;
       &lt;mmi:content&gt;
           &lt;vxml:vxml version="2.0"&gt;
               &lt;vxml:form&gt;
                   &lt;vxml:block&gt;Hello World!&lt;/vxml:block&gt;
               &lt;/vxml:form&gt;
           &lt;/vxml:vxml&gt;
       &lt;/mmi:content&gt;
   &lt;/mmi:prepareRequest&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1965" id="d3e1965" />B.5 PrepareResponse (from MC
to IM, Success)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:prepareResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" 
                        mmi:requestID="request-1" mmi:status="success"/&gt;
&lt;/mmi:mmi&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1970" id="d3e1970" />B.6 PrepareResponse (from MC
to IM, Failure)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:prepareResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" 
                        mmi:requestID="request-1" mmi:status="failure"&gt;
       &lt;mmi:statusInfo&gt;
           NotAuthorized
       &lt;/mmi:statusInfo&gt;
   &lt;/mmi:prepareResponse&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1975" id="d3e1975" />B.7 StartRequest (from IM to
MC)</h3>
</div>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:startRequest mmi:source="someURI" mmi:target="someOtherURI" mmi:context="URI-1" mmi:requestID="request-1"&gt;
       &lt;mmi:contentURL mmi:href="someContentURI" mmi:max-age="" mmi:fetchtimeout="1s"/&gt;
  &lt;/mmi:startRequest&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>

<div class="div2">
<h3><a name="d3e1980" id="d3e1980" />B.8 StartResponse (from MC to
IM)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:startResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1" 
                      mmi:status="failure"&gt;
       &lt;mmi:statusInfo&gt;
           NotAuthorized
       &lt;/mmi:statusInfo&gt;
   &lt;/mmi:startResponse&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1985" id="d3e1985" />B.9 DoneNotification (from MC
to IM, with EMMA result)</h3>

<p>This requestID corresponds to the requestID of the
"StartRequest" event that started it.</p>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"
    xmlns:emma="http://www.w3.org/2003/04/emma"&gt;
   &lt;mmi:doneNotification mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" 
                              mmi:status="success" mmi:requestID="request-1" mmi:confidential="true"&gt;
       &lt;mmi:data&gt;
           &lt;emma:emma version="1.0"&gt;
               &lt;emma:interpretation id="int1" emma:medium="acoustic" emma:confidence=".75" 
                                 emma:mode="voice" emma:tokens="flights from boston to denver"&gt;
                   &lt;origin&gt;Boston&lt;/origin&gt;
                   &lt;destination&gt;Denver&lt;/destination&gt;
               &lt;/emma:interpretation&gt;
           &lt;/emma:emma&gt;
       &lt;/mmi:data&gt;
   &lt;/mmi:doneNotification&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1992" id="d3e1992" />B.10 DoneNotification (from MC
to IM, with EMMA "no-input" result)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"
    xmlns:emma="http://www.w3.org/2003/04/emma"&gt;
   &lt;mmi:doneNotification mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" 
                         mmi:status="success" mmi:requestID="request-1" &gt;
       &lt;mmi:data&gt;
           &lt;emma:emma version="1.0"&gt;
               &lt;emma:interpretation id="int1" emma:no-input="true"/&gt;
           &lt;/emma:emma&gt;
       &lt;/mmi:data&gt;
   &lt;/mmi:doneNotification&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e1997" id="d3e1997" />B.11 CancelRequest (from IM to
MC)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:cancelRequest mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" 
                      mmi:requestID="request-1"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2002" id="d3e2002" />B.12 CancelResponse (from MC
to IM)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:cancelResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1" 
                       mmi:status="success"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2007" id="d3e2007" />B.13 PauseRequest (from IM to
MC)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:pauseRequest mmi:context="someURI" mmi:source="someURI" mmi:target="someOtherURI" 
                     mmi:requestID="request-1"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2012" id="d3e2012" />B.14 PauseResponse (from MC to
IM)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:pauseResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1" 
                      mmi:status="success"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2017" id="d3e2017" />B.15 ResumeRequest (from IM to
MC)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:resumeRequest mmi:context="someURI" mmi:source="someURI" mmi:target="someOtherURI" 
                      mmi:requestID="request-1"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2022" id="d3e2022" />B.16 ResumeResponse (from MC
to IM)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:resumeResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1" 
                       mmi:status="success"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2027" id="d3e2027" />B.17 ExtensionNotification
(formerly the data event, sent in both directions)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:extensionNotification mmi:name="appEvent" mmi:source="someURI" 
       mmi:target="someOtherURI" mmi:context="someURI" mmi:requestID="request-1"&gt;
   &lt;/mmi:extensionNotification&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2032" id="d3e2032" />B.18 ClearContextRequest (from
the IM to MC)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:clearContextRequest mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" 
                            mmi:requestID="request-2"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2037" id="d3e2037" />B.19 ClearContextResponse
(from the MC to IM)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:clearContextResponse mmi:source="someURI" mmi:target="someOtherURI" mmi:context="someURI" 
                            mmi:requestID="request-2" mmi:status="success"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2042" id="d3e2042" />B.20 StatusRequest (from the
IM to the MC)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:statusRequest mmi:requestAutomaticUpdate="true" mmi:source="someURI" 
            mmi:target="someOtherURI" mmi:requestID="request-3" mmi:context="aToken"/&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2047" id="d3e2047" />B.21 StatusResponse (from the
MC to the IM)</h3>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
   &lt;mmi:statusResponse mmi:automaticUpdate="true" mmi:status="alive" 
       mmi:source="someURI" mmi:target="someOtherURI" mmi:requestID="request-3" mmi:context="aToken"/&gt; 
&lt;/mmi:mmi&gt;
</pre>
</div>
</div>
</div>

<div class="div1">
<h2><a name="Schema" id="Schema" />C Event Schemas</h2>

<p>This specification does not require any particular transport
format for life cycle events, however in the case where XML is
used, the following schemas are normative.</p>

<div class="div2">
<h3><a name="d3e2057" id="d3e2057" />C.1 mmi.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             Schema definition for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="NewContextRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="NewContextResponse.xsd"/&gt;
    &lt;xs:include schemaLocation="ClearContextRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="ClearContextResponse.xsd"/&gt;
    &lt;xs:include schemaLocation="CancelRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="CancelResponse.xsd"/&gt;
    &lt;xs:include schemaLocation="DoneNotification.xsd"/&gt;
    &lt;xs:include schemaLocation="ExtensionNotification.xsd"/&gt;
    &lt;xs:include schemaLocation="PauseRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="PauseResponse.xsd"/&gt;
    &lt;xs:include schemaLocation="PrepareRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="PrepareResponse.xsd"/&gt;
    &lt;xs:include schemaLocation="ResumeRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="ResumeResponse.xsd"/&gt;
    &lt;xs:include schemaLocation="StartRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="StartResponse.xsd"/&gt;
    &lt;xs:include schemaLocation="StatusRequest.xsd"/&gt;
    &lt;xs:include schemaLocation="StatusResponse.xsd"/&gt;
    &lt;xs:element name="mmi"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:choice&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:NewContextRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:NewContextResponse"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:ClearContextRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:ClearContextResponse"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:CancelRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:CancelResponse"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:DoneNotification"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:ExtensionNotification"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:PauseRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:PauseResponse"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:PrepareRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:PrepareResponse"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:ResumeRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:ResumeResponse"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:StartRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:StartResponse"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:StatusRequest"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element ref="mmi:StatusResponse"/&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:choice&gt;
            &lt;xs:attribute form="unqualified" name="version" type="xs:decimal" use="required"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2062" id="d3e2062" />C.2 mmi-datatypes.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             general Type definition schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:simpleType name="targetType"&gt;
        &lt;xs:restriction base="xs:string"/&gt;
    &lt;/xs:simpleType&gt;
    &lt;xs:simpleType name="requestIDType"&gt;
        &lt;xs:restriction base="xs:string"/&gt;
    &lt;/xs:simpleType&gt;
    &lt;xs:simpleType name="contextType"&gt;
        &lt;xs:restriction base="xs:string"/&gt;
    &lt;/xs:simpleType&gt;
    &lt;xs:simpleType name="statusType"&gt;
        &lt;xs:restriction base="xs:string"&gt;
            &lt;xs:enumeration value="success"/&gt;
            &lt;xs:enumeration value="failure"/&gt;
        &lt;/xs:restriction&gt;
    &lt;/xs:simpleType&gt;
    &lt;xs:simpleType name="statusResponseType"&gt;
        &lt;xs:restriction base="xs:string"&gt;
            &lt;xs:enumeration value="alive"/&gt;
            &lt;xs:enumeration value="dead"/&gt;
        &lt;/xs:restriction&gt;
    &lt;/xs:simpleType&gt;
    &lt;xs:complexType name="contentURLType"&gt;
        &lt;xs:attribute name="href" type="xs:anyURI" use="required"/&gt;
        &lt;xs:attribute name="max-age" type="xs:string" use="optional"/&gt;
        &lt;xs:attribute name="fetchtimeout" type="xs:string" use="optional"/&gt;
    &lt;/xs:complexType&gt;
    &lt;xs:complexType name="contentType"&gt;
        &lt;xs:sequence&gt;
            &lt;xs:any maxOccurs="unbounded" namespace="http://www.w3.org/2001/vxml" processContents="skip"/&gt;
        &lt;/xs:sequence&gt;
    &lt;/xs:complexType&gt;
    &lt;xs:complexType name="emmaType"&gt;
        &lt;xs:sequence&gt;
            &lt;xs:any maxOccurs="unbounded" namespace="http://www.w3.org/2003/04/emma" processContents="skip"/&gt;
        &lt;/xs:sequence&gt;
    &lt;/xs:complexType&gt;
    &lt;xs:complexType mixed="true" name="anyComplexType"&gt;
        &lt;xs:complexContent mixed="true"&gt;
            &lt;xs:restriction base="xs:anyType"&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:any maxOccurs="unbounded" minOccurs="0" processContents="skip"/&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:restriction&gt;
        &lt;/xs:complexContent&gt;
    &lt;/xs:complexType&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2067" id="d3e2067" />C.3 mmi-attribs.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             general Type definition schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:attributeGroup name="source.attrib"&gt;
        &lt;xs:attribute name="Source" type="xs:string" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="target.attrib"&gt;
        &lt;xs:attribute name="Target" type="mmi:targetType" use="optional"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="requestID.attrib"&gt;
        &lt;xs:attribute name="RequestID" type="mmi:requestIDType" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="context.attrib"&gt;
        &lt;xs:attribute name="Context" type="mmi:contextType" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;  
    &lt;xs:attributeGroup name="confidential.attrib"&gt;
        &lt;xs:attribute name="Confidential" type="xs:boolean" use="optional"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="context.optional.attrib"&gt;
        &lt;xs:attribute name="Context" type="mmi:contextType" use="optional"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="status.attrib"&gt;
        &lt;xs:attribute name="Status" type="mmi:statusType" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="statusResponse.attrib"&gt;
        &lt;xs:attribute name="Status" type="mmi:statusResponseType" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="extension.name.attrib"&gt;
        &lt;xs:attribute name="Name" type="xs:string" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="requestAutomaticUpdate.attrib"&gt;
        &lt;xs:attribute name="RequestAutomaticUpdate" type="xs:boolean" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="automaticUpdate.attrib"&gt;
        &lt;xs:attribute name="AutomaticUpdate" type="xs:boolean" use="required"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="group.allEvents.attrib"&gt;
        &lt;xs:attributeGroup ref="mmi:source.attrib"/&gt;
        &lt;xs:attributeGroup ref="mmi:target.attrib"/&gt;
        &lt;xs:attributeGroup ref="mmi:requestID.attrib"/&gt;
        &lt;xs:attributeGroup ref="mmi:context.attrib"/&gt;
        &lt;xs:attributeGroup ref="mmi:confidential.attrib"/&gt;
    &lt;/xs:attributeGroup&gt;
    &lt;xs:attributeGroup name="group.allResponseEvents.attrib"&gt;
        &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
        &lt;xs:attributeGroup ref="mmi:status.attrib"/&gt;
    &lt;/xs:attributeGroup&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2072" id="d3e2072" />C.4 mmi-elements.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             general elements definition schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    
    &lt;!-- ELEMENTS --&gt;
    &lt;xs:element name="statusInfo" type="mmi:anyComplexType"/&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2077" id="d3e2077" />C.5 NewContextRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             NewContextRequest schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;

    &lt;xs:element name="NewContextRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:source.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:target.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:requestID.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2082" id="d3e2082" />C.6
NewContextResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             NewContextResponse schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="NewContextResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element minOccurs="0" ref="mmi:statusInfo"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2087" id="d3e2087" />C.7 PrepareRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             PrepareRequest schema for MMI Life cycle events version 1.0. 
             The optional PrepareRequest event is an event that the Runtime Framework may send 
             to allow the Modality Components to pre-load markup and prepare to run (e.g. in case of 
             VXML VUI-MC). Modality Components are not required to take any particular action in 
             response to this event, but they must return a PrepareResponse event.
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    
    &lt;xs:element name="PrepareRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:choice&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element name="ContentURL" type="mmi:contentURLType"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element name="Content" type="mmi:anyComplexType"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element minOccurs="0" name="Data" type="mmi:anyComplexType"/&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:choice&gt;
            &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2092" id="d3e2092" />C.8 PrepareResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             PrepareResponse schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="PrepareResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/&gt;
                &lt;xs:element minOccurs="0" ref="mmi:statusInfo"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2097" id="d3e2097" />C.9 StartRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             StartRequest schema for MMI Life cycle events version 1.0. 
             The Runtime Framework sends the event StartRequest to invoke a Modality Component 
             (to start loading a new GUI resource or to start the ASR or TTS). The Modality Component 
             must return a StartResponse event in response. If the Runtime Framework has sent a previous
             PrepareRequest event, it may leave the contentURL and content fields empty, and the Modality
             Component will use the values from the PrepareRequest event. If the Runtime Framework includes 
             new values for these fields, the values in the StartRequest event override those in the 
             PrepareRequest event.
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    
    &lt;xs:element name="StartRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:choice&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element name="ContentURL" type="mmi:contentURLType"/&gt;
                    &lt;xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/&gt;
                &lt;/xs:sequence&gt;
                &lt;xs:sequence&gt;
                    &lt;xs:element name="Content" type="mmi:anyComplexType"/&gt;
                    &lt;xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/&gt;
                &lt;/xs:sequence&gt;
            &lt;/xs:choice&gt;
            &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2102" id="d3e2102" />C.10 StartResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             StartResponse schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="StartResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element name="Data" minOccurs="0" type="mmi:anyComplexType"/&gt;
                &lt;xs:element ref="mmi:StatusInfo" minOccurs="0"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2107" id="d3e2107" />C.11 DoneNotification.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             DoneNotification schema for MMI Life cycle events version 1.0. 
             The DoneNotification event is intended to be used by the Modality Component to indicate that
             it has reached the end of its processing. For the VUI-MC it can be used to return the ASR
             recognition result (or the status info: noinput/nomatch) and TTS/Player done notification. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="DoneNotification"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/&gt;
                &lt;xs:element minOccurs="0" ref="mmi:statusInfo"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2112" id="d3e2112" />C.12 CancelRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             CancelRequest schema for MMI Life cycle events version 1.0. 
             The CancelRequest event is sent by the Runtime Framework to stop processing in the Modality 
             Component (e.g. to cancel ASR or TTS/Playing). The Modality Component must return with a 
             CancelResponse message. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    
    &lt;xs:element name="CancelRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
            &lt;!-- no elements --&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2117" id="d3e2117" />C.13 CancelResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             CancelResponse schema for MMI Life cycle events version 1.0. 
             The CancelRequest event is sent by the Runtime Framework to stop processing in the Modality 
             Component (e.g. to cancel ASR or TTS/Playing). The Modality Component must return with a 
             CancelResponse message. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="CancelResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element ref="mmi:StatusInfo" minOccurs="0"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2122" id="d3e2122" />C.14 PauseRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             PauseRequest schema for MMI Life cycle events version 1.0. 
             The PauseRequest event is sent by the Runtime Framework to pause processing of a Modality 
             Component (e.g. to cancel ASR or TTS/Playing). The Modality Component must return with a 
             PauseResponse message. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    
    &lt;xs:element name="PauseRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
            &lt;!-- no elements --&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2127" id="d3e2127" />C.15 PauseResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             PauseResponse schema for MMI Life cycle events version 1.0. 
             The PauseRequest event is sent by the Runtime Framework to pause the processing of
             the Modality Component (e.g. to cancel ASR or TTS/Playing). The Modality Component 
             must return with a PauseResponse message. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="PauseResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element ref="mmi:StatusInfo" minOccurs="0"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2132" id="d3e2132" />C.16 ResumeRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             ResumeRequest schema for MMI Life cycle events version 1.0. 
             The ResumeRequest event is sent by the Runtime Framework to resume a previously suspended 
             processing task of a Modality Component. The Modality Component must return with a 
             ResumeResponse message. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    
    &lt;xs:element name="ResumeRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
            &lt;!-- no elements --&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2137" id="d3e2137" />C.17 ResumeResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             ResumeRequest schema for MMI Life cycle events version 1.0. 
             The ResumeRequest event is sent by the Runtime Framework to resume a previously suspended 
             processing task of a Modality Component. The Modality Component must return with a 
             ResumeResponse message. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="ResumeResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element ref="mmi:StatusInfo" minOccurs="0"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2142" id="d3e2142" />C.18
ExtensionNotification.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             ExtensionNotification schema for MMI Life cycle events version 1.0. 
             The extensionNotification event may be generated by either the Runtime Framework or the 
             Modality Component and is used to communicate (presumably changed) data values to the 
             other component. E.g. the VUI-MC has signaled a recognition result for any field displayed 
             on the GUI, the event will be used by the Runtime Framework to send a command to the 
             GUI-MC to update the GUI with the recognized value. 
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    
    &lt;xs:element name="ExtensionNotification"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element minOccurs="0" name="data" type="mmi:anyComplexType"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:extension.name.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2147" id="d3e2147" />C.19
ClearContextRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" xmlns:xs="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2008/04/mmi-arch"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             ClearContextRequest schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;

    &lt;xs:element name="ClearContextRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:attributeGroup ref="mmi:group.allEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;

</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2152" id="d3e2152" />C.20
ClearContextResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             ClearContextResponse schema for MMI Life cycle events version 1.0
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="clearContextResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element ref="mmi:statusInfo" minOccurs="0"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:group.allResponseEvents.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2157" id="d3e2157" />C.21 StatusRequest.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             StatusRequest schema for MMI Life cycle events version 1.0. 
             The StatusRequest message and the corresponding StatusResponse are intended to provide keep-alive 
             functionality, informing the Runtime Framework about the presence of the various modality components. 
             Note that both messages are not tied to any context and may thus be sent independent of any user 
             interaction.
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    
    &lt;xs:element name="StatusRequest"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:attributeGroup ref="mmi:context.optional.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:source.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:target.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:requestID.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:requestAutomaticUpdate.attrib"/&gt;
            &lt;!-- no elements --&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>

<div class="div2">
<h3><a name="d3e2162" id="d3e2162" />C.22 StatusResponse.xsd</h3>

<div class="exampleInner">
<pre>
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;xs:schema xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://www.w3.org/2008/04/mmi-arch" 
    attributeFormDefault="qualified" 
    elementFormDefault="qualified"&gt;
    &lt;xs:annotation&gt;
        &lt;xs:documentation xml:lang="en"&gt;
             StatusResponse schema for MMI Life cycle events version 1.0. 
             The StatusRequest message and the corresponding StatusResponse are intended to provide keep-alive 
             functionality, informing the Runtime Framework about the presence of the various modality components. 
             Note that both messages are not tied to any context and may thus be sent independent of any user 
             interaction.
        &lt;/xs:documentation&gt;
    &lt;/xs:annotation&gt;
    &lt;xs:include schemaLocation="mmi-datatypes.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-attribs.xsd"/&gt;
    &lt;xs:include schemaLocation="mmi-elements.xsd"/&gt;
    
    &lt;xs:element name="StatusResponse"&gt;
        &lt;xs:complexType&gt;
            &lt;xs:sequence&gt;
                &lt;xs:element ref="mmi:StatusInfo" minOccurs="0"/&gt;
            &lt;/xs:sequence&gt;
            &lt;xs:attributeGroup ref="mmi:context.optional.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:source.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:target.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:requestID.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:statusResponse.attrib"/&gt;
            &lt;xs:attributeGroup ref="mmi:automaticUpdate.attrib"/&gt;
        &lt;/xs:complexType&gt;
    &lt;/xs:element&gt;
&lt;/xs:schema&gt;
</pre>
</div>
</div>
</div>

<div class="div1">
<h2><a name="LadderDiagrams" id="LadderDiagrams" />D Ladder
Diagrams for the MMI Architecture with a Web Browser and VXML
Interpreter</h2>

[This section is informative] 

<div class="div2">
<h3><a name="d3e2171" id="d3e2171" />D.1 Creating a Session</h3>

<p>The following ladder diagram shows a possible message sequence
upon a session creation. We assume that an Interaction Manager
session is already up and running. The user starts a multimodal
session for example by starting a web browser and fetching a given
URL.</p>

<p>The initial document contains scripts which providing the
modality component functionality (e.g. understanding XML formatted
life-cycle events) and message transport capabilities (e.g. AJAX,
but depends on the exact system implementation).</p>

<p>After loading the initial documents (and scripts) the modality
component implementation issues a mmi:NewContextRequest message to
the IM. The IM may load a corresponding markup document, if
necessary, and initializes and starts a new session.</p>

<p>In this scenario the Interaction Manager manager logic issues a
number of mmi:StartRequest messages to the various modality
components. One message is sent to the graphical modality component
(GUI) to instruct it to load a HTML document. Another message is
sent to a voice modality component (VUI) to play a welcome
message.</p>

<p>The voice modality component has (in this example) to create a
VoiceXML session. As VoiceXML 2.1 does not provide an external
event interface a CCXML session will be used for external
asynchronous communication. Therefore the voice modality component
uses the session creation interface of CCXML 1.0 to create a
session and start a corresponding script. This script will then
make a call to a phone at the user device (which could be a regular
phone or a SIP soft phone on the user's device). This scenario
illustrates the use of a SIP phone, which may reside on the users
mobile handset.</p>

<p>After successful setup of a CCXML session and the voice
connection the voice modality component instructs the CCXML browser
to start a VoiceXML dialog and passing it a corresponding VoiceXML
script. The VoiceXML interpreter will execute the script and play
out the welcome message. After the execution of the VoiceXML script
has finished, the voice modality component notifies the Interaction
Manager using the mmi:done event.</p>

<img class="center"
src="Images/MMI_SequenceDiagrams_1_create_session.png"
alt="session creation ladder" /></div>

<div class="div2">
<h3><a name="d3e2187" id="d3e2187" />D.2 Processing User Input</h3>

<p>The next diagram gives a example for the possible message flow
while processing of user input. In the given scenario the user
wants to enter information using the voice modality component. To
start the voice input the user has to use the "push-to-talk"
button. The "push-to-talk" button (which might be a hardware button
or a soft button on the screen) generates a corresponding event
when pushed. This event is issues as a mmi:Extension event towards
the Interaction Manager. The Interaction Manager logic sends a
mmi:StartRequest to the voice modality component. This
mmi:StartRequest message contains a URL which points to a
corresponding VoiceXML script. The voice modality component again
starts a VoiceXML interpreter using the given URL. The VoiceXML
interpreter loads the document and executes it. Now the system is
ready for the user input. To notify the user about the availability
of the voice input functionality the Interaction Manager might send
an event to the GUI upon receiving the mmi:StartResponse event
(which indicates that the voice modality component has started to
execute the document). But note that this is not shown in the
picture.</p>

<p>The VoiceXML interpreter captures the users voice input and uses
a speech recognition engine to recognize the utterance. The speech
recognition result will be represented as an EMMA document and sent
to the interaction manager using the mmi:done message. The
Interaction Manager logic sends a mmi:Extension message to the GUI
modality component to instruct it to display the recognition
result.</p>

<img class="center"
src="Images/MMI_SequenceDiagrams_2_processing_user_input.png"
alt="session creation ladder" /></div>

<div class="div2">
<h3><a name="d3e2195" id="d3e2195" />D.3 Ending a Session</h3>

<p>In the following scenario a modality component instance will be
destroyed as a reaction to a user input, e.g. because the user
selected to change to the GUI only mode. In this case a
mmi:ClearContextRequest will be issued to the voice modality
component. The voice modality component wrapper will then destroy
the CCXML (and VoiceXML) session.</p>

<p>The application logic (i.e. the IM) may also decide to indicate
the removed voice functionality and disable an icon on the screen
which indicates the availability of the voice modality.</p>

<img class="center"
src="Images/MMI_SequenceDiagrams_3_destroy_session.png"
alt="session creation ladder" /></div>
</div>

<div class="div1">
<h2><a name="LocalizationCustomization"
id="LocalizationCustomization" />E Localization and
Customization</h2>

[This section is informative] 

<p>The MMI architecture specification describes a set of lifecycle
events which define the basic interface between the interaction
management and the modality components. The StartRequest lifecycle
event defines the "content" and "contentURL" elements which may
contain markup code (or references to markup code). The markup has
to be executed by the modality component. Using the "Content" or
"ContentURL" attributes introduces a dependency of the lifecycle
event to a specific modality component implementation. In other
words, the interaction manager has to issue different
StartRequests, depending on which markup a GUI modality component
may be able to process.</p>

<p>But multimodal applications may want to support different
modality component implementations, such as HTML or Flash, for the
same application. In this case the interaction manager should be
independent of the modality component implementation and hence not
generate a markup specific lifecycle event (e.g. containing a link
to HTML or even HTML content), but a further abstracted description
of the command.</p>

<p>Furthermore, localization needs to be taken into account. If the
interaction manager sends markup code to the modality component (or
references to it), this markup code should not contain any
dependencies to the user's language. Instead the interaction
manager needs to send the locale information to the modality
component and let it select the appropriate strings.</p>

<p>Here is an example to show, how these two issues could be
addressed within the lifecycle events. This example uses a generic
data structure to carry the locale information (within the xml:lang
attribute) and the data to be visualized at a GUI.</p>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
    &lt;mmi:startRequest mmi:requestID="123720476141" mmi:context="IM_dcc3c320-9e88-44fe-b91d-02bd02fba1e3" mmi:source="IM" mmi:target="GUI"&gt;
        &lt;mmi:contentURL mmi:href="login"/&gt;
        &lt;mmi:data&gt;
            &lt;gui resourceid="login" xml:lang="de-DE"&gt;
                &lt;data id="back" enabled="false"/&gt;
                &lt;data id="next" enabled="false"/&gt;
            &lt;/gui&gt;
        &lt;/mmi:data&gt;
    &lt;/mmi:startRequest&gt;
&lt;/mmi:mmi&gt;
</pre>
</div>

<p>This StartRequest carries a generic &lt;gui&gt; structure as its
payload which contains a "resourceid" and the xml:lang information.
The "resourceid" has to be interpreted by the modality component
(either to load an HTML document or a corresponding dialog, e.g. if
it is a flash app), whereas "xml:lang" is used by the modality
component to select the appropriate string tables.</p>

<p>The content of the &lt;gui&gt; structure is an application
specific (but generic) description of data to be used by the
modality component. This could contain a description of the status
of GUI elements (such as "enabled" or "disabled") or a list of
items to be displayed. The following example shows a StartRequest
to display a list of music songs. The list of songs will be loaded
from a backend system and are dynamic. The representation of the
song list is agnostic to the modality component implementation. It
is the responsibility of the modality component to interpret the
structure and to display its content appropriately.</p>

<div class="exampleInner">
<pre>
&lt;mmi:mmi xmlns:mmi="http://www.w3.org/2008/04/mmi-arch" version="1.0"&gt;
    &lt;mmi:startRequest mmi:requestID="123720967758" mmi:context="IM_dcc3c320-9e88-44fe-b91d-02bd02fba1e3" mmi:source="IM" mmi:target="GUI"&gt;
        &lt;mmi:contentURL mmi:href="songSelection"/&gt;
        &lt;mmi:data&gt;
            &lt;gui resourceid="songSelection" xml:lang="de-DE"&gt;
                &lt;data id="back" enabled="true"/&gt;
                &lt;data id="next" enabled="false"/&gt;
                &lt;data id="titleList" selected="" enabled="true"&gt;
                    &lt;items&gt;
                        &lt;item id="10"&gt;
                            &lt;arg name="artist"&gt;&lt;![CDATA[One artist]]&gt;
                            &lt;/arg&gt;
                            &lt;arg name="title"&gt;&lt;![CDATA[This is the title]]&gt;
                            &lt;/arg&gt;
                            &lt;arg name="displayName"&gt;&lt;![CDATA[Title]]&gt;
                            &lt;/arg&gt;
                            &lt;arg name="price"&gt;&lt;![CDATA[0.90]]&gt;
                            &lt;/arg&gt;
                        &lt;/item&gt;
                        &lt;item id="11"&gt;
                            &lt;arg name="artist"&gt;&lt;![CDATA[Another artist]]&gt;
                            &lt;/arg&gt;
                            &lt;arg name="title"&gt;&lt;![CDATA[Yet another title]]&gt;
                            &lt;/arg&gt;
                            &lt;arg name="displayName"&gt;&lt;![CDATA[2nd title]]&gt;
                            &lt;/arg&gt;
                            &lt;arg name="price"&gt;&lt;![CDATA[0.90]]&gt;
                            &lt;/arg&gt;
                        &lt;/item&gt;
                    &lt;/items&gt;
                &lt;/data&gt;                            
            &lt;/gui&gt;
        &lt;/mmi:data&gt;
    &lt;/mmi:startRequest&gt;
&lt;/mmi:mmi&gt;

</pre>
</div>
</div>

<div class="div1">
<h2><a name="HTTPTransport" id="HTTPTransport" />F HTTP transport
of MMI lifecycle events</h2>

[This section is informative] 

<p>The "Multimodal Architecture and Interfaces" specification
supports deployments in a variety of topologies, either distributed
or co-located. In case of a distributed deployment, a protocol for
the lifecycle event transport needs to be defined. HTTP is the
major protocol of the web. HTTP is widely adopted, it is supported
by many programming languages and especially used by web browsers.
Technologies like AJAX provide asynchronous transmission of
messages for web browsers and allow to build modality components on
top of it in distributed environments. This section describes how
the HTTP protocol should be used for MMI lifecycle event transport
in distributed deployments. Modality components and the Interaction
Manager need an HTTP processor to send and receive MMI lifecycle
events. The following picture illustrates a possible modularization
of the Runtime Framework, the Interaction Manager and the Modality
Components. It shows internal lifecycle event interfaces (which
abstract from the transport layer) and the HTTP processors. The
HTTP processors are responsible for assembling and disassembling of
HTTP requests, which carry MMI lifecycle event representations as
payloads.</p>

<img class="center" src="Images/HTTP_lifecycle_transport_1.png"
alt="" />
<p>The following sections describe, how the HTTP protocol should be
used to transport MMI lifecycle events.</p>

<p>HTTP defines the concept of client and server <a
href="#RFC2616">[RFC2616]</a>. One possible deployment of the
multimodal architecture is shown in following figure:</p>

<img class="center" src="Images/HTTP_lifecycle_transport_2.png"
alt="" />
<p>In this deployment scenario the Interaction Manager acts as an
HTTP server, whereas modality components are HTTP clients, sending
HTTP requests to the Interaction Manager. But other configurations
are possible.</p>

<div class="div2">
<h3><a name="d3e2240" id="d3e2240" />F.1 Lifecycle event transport
from modality components to Interaction Manager</h3>

<p>The multimodal architecture specification requires an
asynchronous bi-directional event transmission. To achieve this (in
the given scenario, where modality components are HTTP clients and
the Interaction Manager acts as an HTTP server) separate (parallel)
HTTP requests (referred to as send and receive channels in the
picture) are used to send and receive lifecycle events.</p>

<img class="center" src="Images/HTTP_lifecycle_transport_3.png"
alt="" />
<p>Modality components use HTTP/POST requests to send MMI lifecycle
events to the IM. The request contains the following URL request
parameters:</p>

<ul>
<li><code>Context</code> (or <code>token</code>)</li>

<li><code>Source</code></li>
</ul>

<p>The lifecycle event itself is contained in the body of the
HTTP/POST request. The <code>Content-Type</code> header field of
the HTTP/POST request has to be set according to the lifecycle
event format, e.g. “text/xml”.</p>

<p>The URL request parameters <code>Context</code> and
<code>Source</code> are equivalent to the respective MMI lifecycle
event attributes. The <code>Context</code> must be used whenever
available. The <code>Context</code> is only unknown to the modality
component during startup of a multimodal session, as the
<code>Context</code> will be returned from the Interaction Manager
to the Modality component with the <code>NewContextResponse</code>
lifecycle event. Hence, when sending a
<code>NewContextRequest</code>, the context is unknown. Therefore a
<code>token</code> is used to associate the
<code>NewContextRequest</code> and <code>NewContextResponse</code>
messages.</p>

<p>The <code>token</code> is a unique id (preexisting knowledge,
e.g. generated by the modality component during registration) to
identify the channel between a modality component and the
Interaction Manager.</p>

<p>Once the <code>Context</code> is exchanged, the
<code>Context</code> must be used with subsequent requests and the
<code>token</code> must not be used anymore.</p>

<p>The response (to a HTTP/POST request, which carries a lifecycle
event from a Modality Component to to the Interaction Manager) must
not contain any content and the HTTP response code must be “204 No
Content”.</p>

<p>The HTTP processor of the Interaction Manager is expected to
handle POST requests (which contain lifecycle events sent from the
modality component to the Interaction Manager) as following:</p>

<ul>
<li>use the <code>context</code> (or <code>token</code>) parameter
to identify the corresponding interaction manager session</li>

<li>read lifecycle event from request body</li>

<li>forward MMI event to corresponding Interaction Manager
session</li>

<li>return "204 No Content" HTTP status code in case of success or
4XX/5XX codes in case of failure (see error handling section
below)</li>
</ul>

<br />
<br />
</div>

<div class="div2">
<h3><a name="d3e2332" id="d3e2332" />F.2 Lifecycle event transport
from IM to modality components (HTTP clients only)</h3>

Modality components, which are not HTTP servers (such as modality
components build on top of web browsers) are not able to receive
HTTP requests. Thus, to receive MMI events from the Interaction
Manager, such modality components need to poll for events. The
modality component has to send an HTTP/GET request to the
Interaction Manager to request for the next MMI event. For network
performance optimization the HTTP processor of the Interaction
Manager may block the HTTP request for a certain time to avoid
delay and network traffic (long living HTTP request). The modality
component may control the maximum delay using the optional
parameter <code>timeout</code> (in milliseconds). The request
contains the following URL request parameters: 

<ul>
<li><code>Context</code> (or <code>token</code>)</li>

<li><code>Source</code></li>

<li><code>timeout</code> (optional)</li>
</ul>

<p>See discussion of the parameter <code>Context</code> in the
previous section. The parameter <code>Source</code> describes the
source of the request, i.e. the modality components id. The
parameter <code>timeout</code> is optional and describes the
maximum delay in milliseconds. Only positive integer values are
allowed for the parameter <code>timeout</code>. The request with
<code>timeout</code> set to “0” returns immediately. The
Interaction Manager may limit the timeout to a (platform specific)
maximum value. In case of absence of the parameter
<code>timeout</code> the Interaction Manager uses a platform
specific default.</p>

<p>The HTTP response body contains the lifecycle event as a string.
The HTTP response header must contain the <code>Content-Type</code>
header field, which describes the format of the lifecycle event
string (e.g. “text/xml”).</p>

<p>The HTTP processor of the Interaction Manager is expected to
handle HTTP/GET requests (which are used by the Modality Component
to receive lifecycle events) as following:</p>

<ul>
<li>use <code>Context</code> (or <code>token</code>) parameter to
identify the corresponding Interaction Manager session</li>

<li>use <code>Source</code> parameter to identify modality
component id</li>

<li>check for corresponding events (i.e. are there events to send
from Interaction Manager to this particular Modality Component).
This step might be blocking for a certain time (according to
timeout parameter) to optimize network performance.</li>

<li>generate HTTP response containing lifecycle event string (and
set <code>Content-Type</code> header field appropriately). Use "200
OK" HTTP status code in case an event is contained in the response,
“204 No Content” in case of timeout or 4XX/5XX codes in case of
failure (see error handling section below)</li>
</ul>

<br />
<br />
<p>The following figure shows a sequence of HTTP requests: <img
class="center" src="Images/HTTP_lifecycle_transport_4.png"
alt="" /> <img class="center"
src="Images/HTTP_lifecycle_transport_5.png" alt="" /></p>

<p>If the IM receives a HTTP/GET request containing an invalid
<code>token</code> or <code>context</code>, it must return a 409
(Conflict) response code.</p>
</div>

<div class="div2">
<h3><a name="d3e2419" id="d3e2419" />F.3 Lifecycle event transport
from Interaction Manager to modality components (HTTP servers)</h3>

<p>For modality components, which are HTTP servers themselves, the
Interaction Manager needs to send a lifecycle event through an
HTTP/POST request. The request contains the following
parameters:</p>

<ul>
<li><code>Context</code></li>

<li><code>Target</code></li>
</ul>

See discussion of parameters in previous sections. Again, the
parameter <code>Target</code> is equivalent to the corresponding
MMI lifecycle event attribute and describes the receiver of the
event. Hence, the receiver of the HTTP request uses this parameter
to identify the corresponding modality component. <br />
<br />
</div>

<div class="div2">
<h3><a name="d3e2435" id="d3e2435" />F.4 Error handling</h3>

<p>Various MMI lifecycle events (especially response events)
contain <em>Status</em> and <em>StatusInfo</em> fields. These
fields should be used for error indication whenever possible.
However, a failure during delivery of a lifecycle event needs to be
indicated using HTTP response codes.</p>

<p>The HTTP processor of the Interaction Manager has to use HTTP
response codes to indicate success or errors during request
handling. In case of a successful processing of a request
(successful in terms of transport, i.e. an event has been
successfully delivered) a 2XX status code (e.g. "204 No Content")
has to be returned. Transport related errors, which lead to failure
in delivery of a lifecycle event, are indicated using 4XX or 5XX
response codes. 4XX error codes referring to "client errors" (wrong
parameters etc.) whereas 5XX error codes indicating server errors
(see also HTTP response codes in <a
href="#RFC2616">[RFC2616]</a>).</p>

<p>The treatment of transport errors is up to the implementation,
but the implementation should make errors visible to author code
(e.g. raise event within Interaction Manager when a lifecycle event
has not been successfully delivered to a Modality Component).</p>
</div>
</div>

<div class="div1">
<h2><a name="glossary" id="glossary" />G Glossary</h2>

[This section is informative] 

<ul>
<li>CCXML: <a href="#CCXML">[CCXML]</a> is designed to provide
telephony call control support for dialog systems, such as
VoiceXML.</li>

<li>Controller Document: A document that contains markup defining
the interaction between the other documents. Such markup is called
Interaction Manager markup.</li>

<li>Data Component: The Data Component is a sub-component of the
Runtime Framework which is responsible for storing
application-level data.</li>

<li>Interaction Manager: The Interaction Manager (IM) is the
component that is responsible for handling all life-cycle events
that the other Components generate. It is responsible for
synchronization of data and focus, etc., across different Modality
Components as well as the higher-level application flow that is
independent of Modality Components.</li>

<li>Life cycle events: The Multimodal Architecture defines basic
life-cycle events which must be supported by all modality
components. These events allow the Runtime Framework to invoke
modality components and receive results from them. They form the
basic interface between the Runtime Framework and the Modality
components.</li>

<li>Modality Component: Modality Components are responsible for
controlling the various input and output modalities on the device.
Modality components may also be used to perform general processing
functions not directly associated with any specific interface
modality, for example, dialog flow control or natural language
processing</li>

<li>Nested components: An Interaction Manager and a set of
Components can present themselves as a Component to a higher-level
Framework. All that is required is that the IM implement the
Component API. The result is a "Russian Doll" model in which
Components may be nested inside other Components to an arbitrary
depth.</li>

<li>Runtime Framework: The Runtime Framework is responsible for
starting the application and interpreting the Controller Document.
It provides the basic infrastructure into which the IM and the
various Modality Components plug into and controls the
communication among the other Constituents.</li>

<li>SCXML: "State Chart extensible Markup Language". <a
href="#SCXML">[SCXML]</a> provides a generic state-machine based
execution environment based on CCXML and Harel State Tables.</li>

<li>Software Constituent: An architecturally significant entity in
the architecture. Because we are using the term 'Component' to
refer to a specific set of entities in our architecture, we will
use the term 'Constituent' as a cover term for all the elements in
our architecture which might normally be called 'software
components'.</li>

<li>VoiceXML: <a href="#VoiceXML">[VoiceXML]</a> is designed for
creating audio dialogs that feature synthesized speech, digitized
audio, recognition of spoken and DTMF key input, recording of
spoken input, telephony, and mixed initiative conversations.</li>
</ul>
</div>

<div class="div1">
<h2><a name="creating_MC" id="creating_MC" />H Types of Modality
Components</h2>

[This section is informative] 

<div class="div2">
<h3><a name="Simple_modality_components"
id="Simple_modality_components" />H.1 Simple modality
components</h3>

<p>Modality components can be classified into either of three
categories: simple, complex or nested.</p>

<p>A simple modality component presents information to a user or
captures information from a user as directed by an interaction
manager. A simple modality component is atomic in that it can not
be portioned into two or ore simple modality components that send
events among themselves. A simple modality component is like a
black box in that the interaction manager can not directly access
any function inside of the black box other than by using life-cycle
events.</p>

<p>A simple modality component might contain functionality to
present one of the following types of information to the user or
user agent. For example:</p>

<ul>
<li>TTS—generates synthetic speech from a text string</li>

<li>Audio replay—replays an audio file to a user</li>

<li>GUI presentation—presents HTML on a display device.</li>

<li>Ink replay—replays one or more ink strokes</li>

<li>Video replay—replays one or more video clips</li>
</ul>

<p>A simple modality component might contain functionality to
capture one of the following types of information from the user or
user agent as directed by a complex modality or interaction
manager:</p>

<ul>
<li>Audio capture—records user utterances</li>

<li>ASR—captures text from the user by using a grammar to convert
spoken voice into text</li>

<li>DTMF—captures integers from a user by using a grammar a user
capture digits represented by the sounds created by touch tone
keypad on a phone</li>

<li>Ink capture—capture one or more ink strokes</li>

<li>Ink recognition—captures one or more ink strokes and interprets
them as text by using a grammar.</li>

<li>Speaker verification—determines if a user is who the user
claims to be by comparing spoken voice characteristics with the
voice characteristics known to be associated with the user</li>

<li>Speaker identification—determines who a speak is by comparing
spoken voice characteristics with a set of preexisting voice
characteristics of several individuals.</li>

<li>Face verification—determines if a user is who the user claims
to be by comparing face patterns with the face patterns known to be
associated with the user</li>

<li>Face identification—determines who a speak is by comparing face
pattern characteristics with a set of preexisting face patterns of
several individuals</li>

<li>GPS—captures the current GPS location of a device.</li>

<li>Keyboard or mouse—captures information entered by the user
using a keyboard or mouse.</li>
</ul>

<img class="center" src="Images/figure1.png"
alt="Two simple modality components" />
<p class="caption">Figure 1: Two simple modality components</p>

<p>Figure 1 illustrates two simple modality components—ASR modality
for capturing input from the user and TTS for presenting output to
the user. Note that all information exchanged between the two
modality components must be sent as life-cycle events to the
interaction manager which forwards them to the other modality
component.</p>
</div>

<div class="div2">
<h3><a name="Complex_modality_components"
id="Complex_modality_components" />H.2 Complex modality
components</h3>

<p>A complex modality component may contain functionality of two or
more simple modality components, for example:</p>

<ul>
<li>GUI—presents information to the user, and captures keystrokes
and mouse movements</li>

<li>VXML—presents a VoiceXML dialog to the user that both present
speech to the user and captures the user's speech</li>

<li>GUI/VUI—enables user to both speak and listen, and read and
type.</li>
</ul>

<img class="center" src="Images/figure2.png"
alt="A basic modality component with two functions" />
<p class="caption">Figure 2: A basic modality component with two
functions</p>

<p>Figure 2 illustrates a complex modality component containing two
functions, ASR and TTS. The ASR and TTS functions within the
complex modality component may communicate directly with each
other, in addition to sending and receiving life-cycle events with
the interaction manager</p>
</div>

<div class="div2">
<h3><a name="Nested_modality_components"
id="Nested_modality_components" />H.3 Nested modality
components</h3>

<p>A nested modality component is a set of modality components and
a script (possibly written in SCXML) that manages them. The script
communicates with the child modality components using life cycle
events. The script communicates with the interaction manager using
only life-cycle events. The child modality components may not
communicate directly with each other.</p>

<img class="center" src="Images/figure3.png"
alt="A nested modality component with two child modality components, ASR and TTS" />
<p class="caption">Figure 3: A nested modality component with two
child modality components, ASR and TTS.</p>

<p>Figure 3 illustrates a nested modality component with two child
modality components, ASR and TTS.</p>

<p>In effect, the script within a nested modality component can be
thought of as an interaction manager that manages the child
modality components. In effect, a nested modality component is a
nested interaction manager. This is the so-called "Russian Doll"
model of nested interaction managers.</p>
</div>
</div>

<div class="div1">
<h2><a name="references" id="references" />I Normative
References</h2>

<dl>
<dt class="label"><a name="RFC2119" id="RFC2119" />IETF RFC
2119</dt>

<dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>RFC 2119:
Key words for use in RFCs to Indicate Requirement
Levels</cite></a>. Internet Engineering Task Force, 1997. (See
http://www.ietf.org/rfc/rfc2119.txt.)</dd>

<dt class="label"><a name="RFC2396" id="RFC2396" />IETF RFC
2396</dt>

<dd><a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>RFC 2396:
Uniform Resource Identifiers</cite></a>. Internet Engineering Task
Force, 1995. (See http://www.ietf.org/rfc/rfc2396.txt.)</dd>

<dt class="label"><a name="RFC2616" id="RFC2616" />RFC2616</dt>

<dd><a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>"Hypertext
Transfer Protocol -- HTTP/1.1"</cite></a> , R. Fielding et al.
editors. IETF, 1999.</dd>
</dl>
</div>

<div class="div1">
<h2><a name="d3e2590" id="d3e2590" />J Informative References</h2>

<dl>
<dt class="label"><a name="CCXML" id="CCXML" />CCXML</dt>

<dd><a href="http://www.w3.org/TR/ccxml/"><cite>"Voice Browser Call
Control: CCXML Version 1.0"</cite></a> , R.J. Auburn, editor, World
Wide Web Consortium, 2005.</dd>

<dt class="label"><a name="EMMA" id="EMMA" />EMMA</dt>

<dd><a href="http://www.w3.org/TR/emma/"><cite>"Extensible
multimodal Annotation markup language (EMMA)"</cite></a>, Michael
Johnson et al. editors. EMMA is an XML format for annotating
application specific interpretations of user input with information
such as confidence scores, time stamps, input modality and
alternative recognition hypotheses, World Wide Web Consortium,
2005.</dd>

<dt class="label"><a name="Communicator"
id="Communicator" />Galaxy</dt>

<dd><a href="http://communicator.sourceforge.net/"><cite>"Galaxy
Communicator"</cite></a> Galaxy Communicator is an open source hub
and spoke architecture for constructing dialogue systems that was
developed with funding from Defense Advanced Research Projects
Agency (DARPA) of the United States Government.</dd>

<dt class="label"><a name="MMIF" id="MMIF" />MMIF</dt>

<dd><a href="http://www.w3.org/TR/mmi-framework/"><cite>"W3C
Multimodal Interaction Framework"</cite></a> , James A. Larson,
T.V. Raman and Dave Raggett, editors, World Wide Web Consortium,
2003.</dd>

<dt class="label"><a name="MMIUse" id="MMIUse" />MMIUse</dt>

<dd><a
href="http://www.w3.org/TR/mmi-use-cases/#driving-dir"><cite>"W3C
Multimodal Interaction Use Cases"</cite></a>, Emily Candell and
Dave Raggett, editors, World Wide Web Consortium, 2002.</dd>

<dt class="label"><a name="SCXML" id="SCXML" />SCXML</dt>

<dd><a
href="http://www.w3.org/TR/2006/WD-scxml-20060124/"><cite>"State
Chart XML (SCXML): State Machine Notation for Control
Abstraction"</cite></a> , Jim Barnett et al. editors. World Wide
Web Consortium, 2006.</dd>

<dt class="label"><a name="SMIL" id="SMIL" />SMIL</dt>

<dd><a
href="http://www.w3.org/TR/2005/REC-SMIL2-20051213/"><cite>"Synchronized
Multimedia Integration Language (SMIL 2.1)"</cite></a> , Dick
Bulterman et al. editors. World Wide Web Consortium, 2005.</dd>

<dt class="label"><a name="SVG" id="SVG" />SVG</dt>

<dd><a href="http://www.w3.org/TR/SVG11/"><cite>"Scalable Vector
Graphics (SVG) 1.1 Specification"</cite></a> , Jon Ferraiolo et al.
editors. World Wide Web Consortium, 2003.</dd>

<dt class="label"><a name="VoiceXML" id="VoiceXML" />VoiceXML</dt>

<dd><a href="http://www.w3.org/TR/voicexml20/"><cite>"Voice
Extensible Markup Language (VoiceXML) Version 2.0"</cite></a> ,
Scott McGlashan et al. editors. World Wide Web Consortium,
2004.</dd>

<dt class="label"><a name="HTML" id="HTML" />HTML</dt>

<dd><a
href="http://www.w3.org/TR/1999/REC-html401-19991224/"><cite>"HTML
4.01 Specification"</cite></a> , Raggett et al. editors. World Wide
Web Consortium, 1999.</dd>

<dt class="label"><a name="XMLSig" id="XMLSig" />XMLSig</dt>

<dd><a
href="http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/"><cite>"XML-Signature
Syntax and Processing"</cite></a> Eastlake et al., editors. World
Wide Web Consortium, 2001.</dd>
</dl>
</div>
</div>
</body>
</html>