discontinued / server · Files

index.html 189 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 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  <title>Authoring Techniques for Device Independence</title>
  <!-- In-line styles -->
  <style type="text/css">
/* ==== style definitions local to this document ==== */
.definition { }
/* begin w3c styles */
body { margin: 2em 1em 2em 70px }
h1, h2, h3 { color: #005A9C; background: white }
h1 { font: 170% sans-serif }
h2 { font: 150% sans-serif }
h3 { font: 130% sans-serif }
h4 { font: bold 120% sans-serif }
h5 { font: bold italic 100% sans-serif }
h5.goal { margin-bottom: 0 }
h5.impl { margin-bottom: 0 }
h6 { font: small-caps 100% sans-serif }
div.head { margin-bottom: 1em }
div.head h1 { margin-top: 2em; clear: both }
div.head table { margin-left: 2em; margin-top: 2em }
div.head img { color: white; border: none } /* remove border from top image */
p.copyright { font-size: small }
pre { margin-left: 2em }
dt, dd { margin-top: 0; margin-bottom: 0 } /* opera 3.50 */
dt { font-weight: bold }
ul.contents { list-style: disc; list-style: none }
ul.simple { list-style: disc; list-style: none }
p.goal { background-color: #FFFFE0; color: black; border: thin solid; 
         margin-top: 0; margin-bottom: 10px; padding: 5px}
p.practice { background-color: #FFFFE0; color: black; border: thin solid; 
         margin-top: 0; margin-bottom: 10px; padding: 5px}
p.technique { background-color: #FFFFE0; color: black; border: thin solid; 
         margin-top: 0; margin-bottom: 10px; padding: 5px}
p.requirement { background-color: #FFFFE0; color: black; border: thin solid; 
         margin-top: 0; margin-bottom: 10px; padding: 5px}
p.goal-heading { font: bold italic 100% sans-serif; margin-bottom: 0 }
p.practice-heading { font: bold italic 100% sans-serif; margin-bottom: 0 }
p.technique-heading { font: bold italic 100% sans-serif; margin-bottom: 0 }
p.requirement-heading { font: bold italic 100% sans-serif; margin-bottom: 0 }
p.impl { background-color: #FFFFE0; color: black; border: thin solid; 
         margin-top: 0; margin-bottom: 10px; padding: 5px }
@media aural {
  h1, h2, h3 { stress: 20; richness: 90 }
  p.copyright { volume: x-soft; speech-rate: x-fast }
  dt { pause-before: 20% }
  pre { speak-punctuation: code }
}
/* ==== end w3c styles ==== */
/* ==== end local style definitions ====*/
/* ==== begin document specific styles ==== */
.indent1 { margin-left: 00px}
.indent2 { margin-left: 00px}
.indent3 { margin-left: 10px}
.indent4 { margin-left: 20px}
.indent5 { margin-left: 30px}
.indent6 { margin-left: 40px}
.indented { margin-left: 20px}
.hilite {  background-color: #FFFF99}
.newtext { background-color: #CCFFCC}
.todo { color: #FFFF00; background-color: #FF0000; font-weight: bold}
.superscript {  font-size: x-small; line-height: 4px}
.oldtext { text-decoration: line-through; background-color: #FFCCCC}
.samplefooter {  color: #006666; text-align: center; font-weight: bold}
.figurefooter { color: #660088; text-align: center; font-weight: bold }
.highlightedcode {  color: #336600}
.glossary {  font-variant: small-caps; color: #990033; text-decoration: underline}
.excised {  background-color: #EEFFFF}
/* ==== end document specific styles ==== */</style>
  <!-- Local copy of style -->
  <!-- Live copy of style -->
  <link href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"
  type="text/css">
</head>

<body bgcolor="#FFFFFF" link="#0000FF" vlink="#0000FF" alink="#0000FF">

<div class="head">
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
alt="W3C" height="48" width="72"></a>

<h1>Authoring Techniques for Device Independence</h1>

<h2>W3C Working Group Note 18 February 2004</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2004/NOTE-di-atdi-20040218/">http://www.w3.org/TR/2004/NOTE-di-atdi-20040218/</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/di-atdi/">http://www.w3.org/TR/di-atdi/</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2003/WD-di-atdi-20031106/">http://www.w3.org/TR/2003/WD-di-atdi-20031106/</a></dd>
  <dt>Editors:</dt>
    <dd>Rotan Hanrahan &lt;<a
      href="mailto:rotan.hanrahan@mobileaware.com">rotan.hanrahan@mobileaware.com</a>&gt;<br>
      Roland Merrick &lt;<a
      href="mailto:roland_merrick@uk.ibm.com">roland_merrick@uk.ibm.com</a>&gt;</dd>
  <dt>Contributors:</dt>
    <dd>See <a href="#appAcknowledgements">Acknowledgements</a></dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
©2004<a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">
W3C</abbr></a> <sup>®</sup> ( <a href="http://www.csail.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a> , <a
href="http://www.ercim.org/">ERCIM</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>,
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software">software
licensing</a> rules apply.</p>
</div>
<hr title="Separator for header">

<h2><a name="abstract">Abstract</a></h2>

<p>The document provides a summary of several techniques and best practices
that Web site authors and solution providers may employ when creating and
delivering content to a diverse set of access mechanisms.</p>

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

<p><em>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/.</em></p>

<p>This document is a W3C Working Group Note. It represents the views of the
W3C Device Independence Working Group at the time of publication. There are
currently no plans to amend this document further. Publication as a Working
Group Note 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>This document is published as part of the <a
href="http://www.w3.org/2001/di/Activity.html">W3C Device Independence
Activity</a> by the Device Independence Working Group. It is a deliverable as
defined in the <a
href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html">Charter</a>
of that group.</p>

<p>Comments on this document may be sent to the public <a
href="mailto:www-di@w3.org">www-di@w3.org</a> mailing list (archived at <a
href="http://lists.w3.org/Archives/Public/www-di/">http://lists.w3.org/Archives/Public/www-di/</a>).</p>

<p>Patent disclosures relevant to this document may be found on the <a
href="/2001/di/Disclosures.html">WG patent disclosure page</a>.</p>

<h2><a name="contents">Table of Contents</a></h2>

<h3 id="vtoc">Visual Table of Contents</h3>
<map name="Map">
  <area shape="rect" coords="3,2,151,50" href="#introduction"
  alt="Introduction" title="Introduction">
  <area shape="rect" coords="2,66,150,138" href="#classification"
  alt="Classification of Techniques" title="Classification of Techniques">
  <area shape="rect" coords="2,151,149,227" href="#deliveryContext"
  alt="Delivery Context" title="Delivery Context">
  <area shape="rect" coords="2,241,149,311" href="#generalTechniques"
  alt="General DI Authoring Techniques"
  title="General DI Authoring Techniques">
  <area shape="rect" coords="179,43,286,78" href="#varyStyle"
  alt="Techniques to vary style for different contexts"
  title="Techniques to vary style for different contexts">
  <area shape="rect" coords="211,118,319,152" href="#varyContent"
  alt="Techniques to vary content for different contexts"
  title="Techniques to vary content for different contexts">
  <area shape="rect" coords="194,81,302,117" href="#varyLayout"
  alt="Techniques to vary layout for different contexts"
  title="Techniques to vary layout for different contexts">
  <area shape="rect" coords="226,152,331,189" href="#varyStructure"
  alt="Techniques to vary structure for different contexts"
  title="Techniques to vary structure for different contexts">
  <area shape="rect" coords="255,225,369,266" href="#varyInteraction"
  alt="Techniques to vary application interaction for different contexts"
  title="Techniques to vary application interaction for different contexts">
  <area shape="rect" coords="401,53,549,107" href="#appAdaptationTechniques"
  alt="Adaptation Techniques" title="Adaptation Techniques">
  <area shape="rect" coords="416,120,526,155" href="#sec1AdaptationProcesses"
  alt="Adaptation Processes" title="Adaptation Processes">
  <area shape="rect" coords="416,169,526,204"
  href="#sec2AdaptationProcessors" alt="Adaptation Processors"
  title="Adaptation Processors">
  <area shape="rect" coords="400,232,546,310" href="#appToS"
  alt="Types of Structure" title="Types of Structure">
  <area shape="rect" coords="403,0,550,49" href="#conclusions"
  alt="Conclusions" title="Conclusions">
  <area shape="rect" coords="244,189,350,224" href="#varyNavigation"
  alt="Techniques to vary navigation features for different contexts"
  title="Techniques to vary navigation features for different contexts">
</map>

<p align="center"><img src="toc.png" width="548" height="317" usemap="#Map"
border="0" alt="graphical TOC"></p>
<!-- TOC Begin -->

<h3 id="btoc">Brief Table of Contents</h3>
<ul class="contents">
  <li><a href="#introduction">1 Introduction</a></li>
  <li><a href="#classification">2 Classification of Authoring
  Techniques</a></li>
  <li><a href="#deliveryContext">3 Delivery Context</a></li>
  <li><a href="#generalTechniques">4 General Authoring Techniques</a></li>
  <li><a href="#varyStyle">5 Techniques to Vary Style for Different Delivery
    Contexts</a></li>
  <li><a href="#varyLayout">6 Techniques to Vary Layout for Different
    Delivery Contexts</a></li>
  <li><a href="#varyContent">7 Techniques to Vary Content for Different
    Delivery Contexts</a></li>
  <li><a href="#varyStructure">8 Techniques to Vary Structure for Different
    Delivery Contexts</a></li>
  <li><a href="#varyNavigation">9 Techniques to Vary Navigation for Different
    Delivery Contexts</a></li>
  <li><a href="#varyInteraction">10 Techniques to Vary Application
    Interaction for Different Delivery Contexts</a></li>
  <li><a href="#authoringTechniquesWorkshop">11 Authoring Techniques
    Workshop</a></li>
  <li><a href="#conclusions">12 Conclusions</a></li>
  <li><a href="#appReferences">Appendix A References</a></li>
  <li><a href="#appAdaptationTechniques">Appendix B Adaptation
  Techniques</a></li>
  <li><a href="#appToS">Appendix C Types of Structure</a></li>
  <li><a href="#appDIAI">Appendix D Device Independence Authoring
    Implications</a></li>
  <li><a href="#appAcknowledgements">Appendix E Acknowledgements</a></li>
</ul>

<h3 id="dtoc">Detailed Table of Contents</h3>
<ul class="contents">
  <li><a href="#introduction">1 Introduction</a>
    <ul>
      <li><a href="#sec1Scope">1.1 Scope</a></li>
      <li><a href="#sec2Goals">1.2 Goals</a>
        <ul>
          <li><a href="#charterGoals">1.2.1 Goals as Specified in the
            Charter</a></li>
          <li><a href="#currentPractices">1.2.2 Current Practices and
            Techniques</a></li>
        </ul>
      </li>
      <li><a href="#sec3Audience">1.3 Audience</a></li>
      <li><a href="#objectives">1.4 Objectives of Authoring Techniques</a>
        <ul>
          <li><a href="#technicalMotivation">1.4.1 Technical Motivation</a>
            <ul>
              <li><a href="#tmVariability">1.4.1.1 Variability</a></li>
              <li><a href="#tmScalability">1.4.1.2 Scalability</a></li>
            </ul>
          </li>
          <li><a href="#nonTechMotivation">1.4.2 Non-technical Motivation</a>
            <ul>
              <li><a href="#ntmAffordability">1.4.2.1 Affordability</a></li>
              <li><a href="#ntmAccessibility">1.4.2.2 Accessibility</a></li>
              <li><a href="#ntmBranding">1.4.2.3 Branding and
              Consistency</a></li>
            </ul>
          </li>
        </ul>
      </li>
      <li><a href="#sec5Organisation">1.5 Organization of the
      Material</a></li>
      <li><a href="#sec5Terminology">1.6 Terminology</a></li>
    </ul>
  </li>
  <li><a href="#classification">2 Classification of Authoring Techniques</a>
    <ul>
      <li><a href="#sec1MultipleAuthoring">2.1 Multiple Authoring</a>
        <ul>
          <li><a href="#multAuthAssocAdapt">2.1.1 Associated Adaptation
            Techniques</a></li>
        </ul>
      </li>
      <li><a href="#sec2SingleAuthoring">2.2 Single Authoring</a>
        <ul>
          <li><a href="#exAuthorHints">2.2.1 Example: Author Hints</a></li>
          <li><a href="#exCSSMQ">2.2.2 Example: CSS Media Queries</a></li>
          <li><a href="#multAuthAssocAdapt">2.2.3 Associated Adaptation
            Techniques</a></li>
        </ul>
      </li>
      <li><a href="#sec3FlexibleAuthoring">2.3 Flexible Authoring</a>
        <ul>
          <li><a href="#exLayouts">2.3.1 Example: Layouts and Portals</a></li>
          <li><a href="#exAltContent">2.3.2 Example: Alternative
          Content</a></li>
          <li><a href="#flexAuthAssocAdapt">2.3.3 Associated Adaptation
            Techniques</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#deliveryContext">3 Delivery Context</a>
    <ul>
      <li><a href="#sec1AuthorAwarenessOfContext">3.1 Author Awareness of
        Context</a></li>
      <li><a href="#contextAuthAssocAdapt">3.2 Associated Adaptation
        Techniques</a></li>
    </ul>
  </li>
  <li><a href="#generalTechniques">4 General Authoring Techniques</a>
    <ul>
      <li><a href="#aspectsOfAuthoring">4.1 Aspects of Authoring</a></li>
      <li><a href="#ATForSpecificAspects">4.2 Authoring Techniques for
        Specific Aspects</a></li>
    </ul>
  </li>
  <li><a href="#varyStyle">5 Techniques to Vary Style for Different Delivery
    Contexts</a>
    <ul>
      <li><a href="#contextSensStyle">5.1 Context-sensitive Style
        Selection</a></li>
      <li><a href="#scriptedStyle">5.2 Scripted Style Selection</a></li>
      <li><a href="#serverSideStyling">5.3 Server-side Styling</a></li>
      <li><a href="#xformsStyling">5.4 XForms Styling</a></li>
    </ul>
  </li>
  <li><a href="#varyLayout">6 Techniques to Vary Layout for Different
    Delivery Contexts</a>
    <ul>
      <li><a href="#layoutPrinciples">6.1 Principles</a>
        <ul>
          <li><a href="#varyLayoutPrincLayoutRep">6.1.1 Explicit Layout
            Representations</a></li>
          <li><a href="#varyLayoutPrincMapContentToLayout">6.1.2 Mapping
            Content to Layout</a></li>
        </ul>
      </li>
      <li><a href="#layoutCSS">6.2 Using CSS for Explicit Layout</a>
        <ul>
          <li><a href="#varyLayoutCSSMQ">6.2.1 CSS Media Queries</a></li>
          <li><a href="#varyLayoutDevDepStyle">6.2.2 Device Dependent
            Stylesheets</a></li>
        </ul>
      </li>
      <li><a href="#layoutSMIL">6.3 Using SMIL for Explicit Layout</a></li>
      <li><a href="#layoutVolantis">6.4 Existing Layout Techniques</a></li>
    </ul>
  </li>
  <li><a href="#varyContent">7 Techniques to Vary Content for Different
    Delivery Contexts</a>
    <ul>
      <li><a href="#contentOrderedDelivery">7.1 Ordered Delivery</a>
        <ul>
          <li><a href="#contentSelection">7.2 Selection Techniques</a>
            <ul>
              <li><a href="#contentSMIL">7.2.1 SMIL</a></li>
              <li><a href="#contentCSSMQ">7.2.2 CSS Media Queries</a></li>
              <li><a href="#contentLayouts">7.2.3 Layouts</a></li>
            </ul>
          </li>
          <li><a href="#contentIncremental">7.3 Incremental
          Refinement</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#varyStructure">8 Techniques to Vary Structure for Different
    Delivery Contexts</a>
    <ul>
      <li><a href="#strucureAggregation">8.1 Aggregation</a></li>
      <li><a href="#structureDecomposition">8.2 Decomposition</a>
        <ul>
          <li><a href="#structurePagination">8.2.1 Pagination and Page
            Numbers</a></li>
          <li><a href="#structureADDecomposition">8.2.2 Author Defined
            Decomposition</a></li>
        </ul>
      </li>
      <li><a href="#structureAssocAdapt">8.3 Associated Adaptation
        Techniques</a></li>
    </ul>
  </li>
  <li><a href="#varyNavigation">9 Techniques to Vary Navigation for Different
    Delivery Contexts</a>
    <ul>
      <li><a href="#structNavLinking">9.1 Linking</a></li>
      <li><a href="#structNavAuthored">9.2 Authored Navigation</a></li>
      <li><a href="#structNavURI">9.3 URI</a></li>
      <li><a href="#structNavTools">9.4 Navigation Tools</a>
        <ul>
          <li><a href="#toolHTMLLinks">9.4.1 HTML Linking</a></li>
          <li><a href="#toolXLink">9.4.2 XLink</a></li>
          <li><a href="#toolXPointer">9.4.3 XPointer</a></li>
          <li><a href="#toolHLink">9.4.4 HLink</a></li>
        </ul>
      </li>
      <li><a href="#interactionSMIL">9.5 SMIL Interaction</a></li>
    </ul>
  </li>
  <li><a href="#varyInteraction">10 Techniques to Vary Application
    Interaction for Different Delivery Contexts</a>
    <ul>
      <li><a href="#interactionForms">10.1 Forms</a>
        <ul>
          <li><a href="#decompositionForm">10.1.2 Decomposition of a
          Form</a></li>
        </ul>
      </li>
      <li><a href="#interactionSession">10.2 Interaction Session</a></li>
    </ul>
  </li>
  <li><a href="#authoringTechniquesWorkshop">11 Authoring Techniques
    Workshop</a>
    <ul>
      <li><a href="#workshopResults">11.1 Results of the Workshop</a>
        <ul>
          <li><a href="#workshopFragment">11.1.1 Fragment (Authoring Unit)</a>
            <ul>
              <li><a href="#workshopURI">11.1.1.1 URIs for Authoring
              Units</a></li>
              <li><a href="#workshopRecursiveDef">11.1.1.2 Recursive
                Definition of Authoring Unit</a></li>
            </ul>
          </li>
          <li><a href="#workshopLayout">11.1.2 Layout</a></li>
          <li><a href="#workshopSingleURI">11.1.3 Single URI</a></li>
          <li><a href="#workshopRoleOfCSS">11.1.4 Role of CSS</a></li>
        </ul>
      </li>
      <li><a href="#workshopTechnology">11.2 Authoring Technology Identified
        by the Workshop</a>
        <ul>
          <li><a href="#wsCommonalities">11. 2.1 Commonalties of
            Approaches</a>
            <ul>
              <li><a href="#wsSeparation">11.2.1.1 Separation of Content,
                Layout and Style</a></li>
              <li><a href="#wsAssocOfStyleTL">11.2.1.2 Association of Style
                at Top Level</a></li>
              <li><a href="#wsMediaRefs">11.2.1.3 Media References to be
                Replaced by Media Sets</a></li>
              <li><a href="#wsLayoutHierarchy">11.2.1.4 Layout
              Hierarchy</a></li>
              <li><a href="#wsIncAndExc">11.2.1.5 Inclusion and
              Exclusion</a></li>
              <li><a href="#wsSeqOfAdapt">11.2.1.6 Sequence of Adaptation
                Steps</a></li>
              <li><a href="#wsUseOfCSS">11.2.1.7 Use of CSS for
              Styling</a></li>
            </ul>
          </li>
          <li><a href="#wsImpactOnMarkup">11.2.2 Impact on Markup</a>
            <ul>
              <li><a href="#wsAssocOfStyles">11.2.2.1 Association of
                Styles</a></li>
              <li><a href="#wsUnitsOfContent">11.2.2.2 Units of
              Content</a></li>
              <li><a href="#wsAlternativeIncExc">11.2.2.3 Alternative
                Inclusions and Exclusions</a></li>
              <li><a href="#wsApplLayouts">11.2.2.4 Application of
              Layouts</a></li>
              <li><a href="#wsAssocContentLayout">11.2.2.5 Association of
                Content and Layout</a></li>
              <li><a href="#wsPassthrough">11.2.2.6 Passthrough of Arbitrary
                Markup</a></li>
              <li><a href="#wsAttrModify">11.2.2.7 Attribute
              Modification</a></li>
              <li><a href="#wsMarkupOfInput">11.2.2.8 Markup of Input</a></li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#conclusions">12 Conclusions</a></li>
  <li><a href="#appReferences">A References</a></li>
  <li><a href="#appAdaptationTechniques">B Adaptation Techniques</a>
    <ul>
      <li><a href="#sec1AdaptationProcesses">B.1 Adaptation Processes</a>
        <ul>
          <li><a href="#sec11SelectAndRemove">B.1.1 Select/Remove</a>
            <ul>
              <li><a href="#urlRedirection">B.1.1.1 Selection via URL
                Redirection</a></li>
              <li><a href="#inDocDecisions">B.1.1.2 In-document Decision
                Tags</a></li>
              <li><a href="#layoutConditions">B.1.1.3 Layout-based
                Conditions</a></li>
              <li><a href="#styleDecisions">B.1.1.4 Style-based
              Decisions</a></li>
              <li><a href="#relevanceOfContent">B.1.1.5 Relevance of
                Content</a></li>
            </ul>
          </li>
          <li><a href="#sec12NavigationGeneration">B.1.2 Navigation
            Generation</a>
            <ul>
              <li><a href="#navGenTOC">B.1.2.1 Table of Contents</a></li>
              <li><a href="#navGenMenus">B.1.2.2 Navigation Menus</a>
                <ul>
                  <li><a href="#navGenNearest">B.1.2.2.1 Nearest Neighbor and
                    Home</a></li>
                  <li><a href="#navGenFullSite">B.1.2.2.2 Full Site
                    Representation</a></li>
                </ul>
              </li>
              <li><a href="#navGenNextPrevious">B.1.2.3 Next and Previous
                links</a>
                <ul>
                  <li><a href="#relToCurrent">B.1.2.3.1 Relative to Current
                    Path</a></li>
                  <li><a href="#relToSite">B.1.2.3.2 Relative to Site
                    Structure</a></li>
                </ul>
              </li>
              <li><a href="#navGenNextBack">B.1.2.4 Next and Back
              Links</a></li>
            </ul>
          </li>
          <li><a href="#sec13AdaptationViaSubstitution">B.1.3 Adaptation via
            Substitution</a></li>
          <li><a href="#sec14AdaptationViaTransformation">B.1.4 Adaptation
            via Transformation</a></li>
        </ul>
      </li>
      <li><a href="#sec2AdaptationProcessors">B.2 Adaptation Processors</a>
        <ul>
          <li><a href="#sec21ServerSideAdaptation">B.2.1 Server-side
            Adaptation</a>
            <ul>
              <li><a href="#ssaVariantSelection">B.2.1.1 Variant
              Selection</a></li>
              <li><a href="#ssaTransformation">B.2.1.2 Transformation</a></li>
              <li><a href="#ssaMediaAdatation">B.2.1.3 Media
              Adaptation</a></li>
              <li><a href="#ssaMediaInfo">B.2.1.4 Using
              Meta-information</a></li>
              <li><a href="#adaptViaDecomposition">B.2.1.5
              Decomposition</a></li>
            </ul>
          </li>
          <li><a href="#sec22ClientSideAdaptation">B.2.2 Client-side
            Adaptation</a>
            <ul>
              <li><a href="#csaImage">B.2.2.1 Image Resizing</a></li>
              <li><a href="#csaFont">B.2.2.2 Font Substitution</a></li>
              <li><a href="#csaTranscode">B.2.2.3 Transcoding</a></li>
              <li><a href="#csaRenderer">B.2.2.4 Dedicated Rendering</a></li>
              <li><a href="#csaFormResize">B.2.2.5 Form Resizing</a></li>
              <li><a href="#contextualSelection">B.2.2.6 Contextual
                Selection</a></li>
            </ul>
          </li>
          <li><a href="#sec23IntermediateAdaptation">B.2.3 Intermediate
            Adaptation</a>
            <ul>
              <li><a href="#iaContentAdaptation">B.2.3.1 Content
                Adaptation</a></li>
              <li><a href="#iaSelectingServer">B.2.3.2 Selecting a
              Server</a></li>
              <li><a href="#iaDeliveryAndProtocol">B.2.3.3 Delivery and
                Protocol Adaptation</a></li>
            </ul>
          </li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#appToS">C Types of Structure</a>
    <ul>
      <li><a href="#tosLinear">C.1 Linear</a></li>
      <li><a href="#tosHierarchy">C.2 Hierarchy</a></li>
      <li><a href="#tosMesh">C.3 Mesh</a></li>
      <li><a href="#tosGeospatial">C.4 Other Geospatial Structures</a></li>
    </ul>
  </li>
  <li><a href="#appDIAI">D Device Independence Authoring Implications</a></li>
  <li><a href="#appAcknowledgements">E Acknowledgments</a></li>
</ul>

<h3 id="samp">List of Samples</h3>
<ul class="contents">
  <li><a href="#sampleStyleSelectMQ">1 Stylesheet selection via Media
    Queries</a></li>
  <li><a href="#sampleTextPosSMIL">2 Text positioning via SMIL</a></li>
  <li><a href="#sampleSMIL">3 SMIL Switch to select alternative
  content</a></li>
  <li><a href="#sampleMQTag">4 Selection of style sheet using Media Queries
    in tag attributes</a></li>
  <li><a href="#sampleMQImport">5 Importing a style sheet using Media Queries
    in a style sheet</a></li>
  <li><a href="#sampleSMILTempAnc">6 SMIL temporal anchors (areas)</a></li>
  <li><a href="#sampleMetaTag">7 Meta tag redirection</a></li>
  <li><a href="#sampleRelevance">8 A method of incorporating "relevance" into
    content markup</a></li>
</ul>

<h3 id="fig">List of Figures</h3>
<ul class="contents">
  <li><a href="#figureRadioToDrop">1 Control transformation from radio
    buttons to a drop-down box</a></li>
  <li><a href="#figureLableToList">2 Control transformation from
    label-textfield pairs to a list-textfield pair</a></li>
  <li><a href="#figureIntermediateAdaptArch">3 Intermediate Adaptation
    Architecture</a></li>
  <li><a href="#figureLinearStructure">4 Linear structure based on navigation
    from page to page</a></li>
  <li><a href="#figureHierarchy">5 A hierarchy of pages</a></li>
  <li><a href="#figureMesh">6 A mesh of pages</a></li>
</ul>
<!-- TOC End -->

<h2><a name="introduction" class="indent2">1 Introduction</a></h2>

<h3 class="indent3"><a name="sec1Scope"></a>1.1 Scope</h3>

<p class="indent3">Drawing on the experience of technology providers and Web
authors, this Note presents an overview of many existing techniques and best
practices that may be used to deliver tailored content and applications to a
wide variety of devices. It shows, in practical terms, how one might address
the problems of content creation, content maintenance and content adaptation.
It explores the issues associated with managing an application's interaction
with a user where different devices and modalities are present.</p>

<p class="indent3">This Note is restricted to content and applications that
are intended for Web delivery, employing technologies that are associated
with the Web, and in particular those technologies that have been recommended
by the W3C or are being developed by the W3C. Furthermore, while the Web can
be used to deliver a wide variety of media types, this Note shall focus on
media that is represented by, or referenced through, markup languages. XHTML
and its associated technologies shall play a key role in this Note, but the
legacy of older technologies shall be recognized as an important domain of
interest.</p>

<p class="indent3">Implementation-specific issues shall be recognized, but
not elaborated, in this Note. This includes issues such as performance and
scaling, security, resource consumption etc. It is recognized that different
implementations of the same authoring techniques, and their associated
adaptation techniques, will have different properties and that these
differences provide scope for business opportunities. These differences are
not a concern of this Note.</p>

<p class="indent3">This Note includes discussions on the features of
authoring tools, site creation and maintenance tools, storage, delivery,
adaptation, end-user devices and software on such devices.</p>

<p class="indent3">This is a rapidly changing area and as a consequence some
of the techniques described will be superseded or obsoleted by new
developments as well as the emergence of new techniques made possible by new
developments. Readers are encouraged to seek additional information through
the references and other sources.</p>

<h3 class="indent3"><a name="sec2Goals"></a>1.2 Goals</h3>

<h4 class="indent4"><a name="charterGoals"></a>1.2.1 Goals as Specified in
the Charter</h4>

<p class="indent4">This Note is one of the deliverables of the Device
Independence Working Group. According to the charter, <a
href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html#auth-techniques">section
3.2.2</a>, the purpose of this document is to:</p>

<p class="indent4">"<i>propose some techniques for authors to achieve greater
device independence. [...]</i></p>

<p class="indent4"><i>Firstly, using existing techniques, to:</i></p>
<ul>
  <li><i>describe how authors use current markup and adaptation techniques to
    deliver to different devices</i></li>
  <li><i>show how separation between content and its presentation on
    different devices can be achieved</i></li>
  <li><i>cover approaches that include adaptation on the client, the origin
    server and on intermediaries</i></li>
  <li><i>give examples based on existing markup and adaptation
  techniques</i></li>
  <li><i>point out where current approaches do not address all the
  goals</i></li>
</ul>

<p class="indent4"><i>Secondly, using techniques based on XForms, to:</i></p>
<ul>
  <li><i>show how navigation can be described independently of target device
    (e.g. for non-visual and different sizes of visual device)</i></li>
  <li><i>show how interaction can be expressed in a device independent
    manner</i></li>
  <li><i>show how applications can be customized for different target
    delivery contexts</i>"</li>
</ul>

<p class="indent4">The quoted charter items lead to stipulation of the
following goals for this document:</p>

<p class="goal-heading"><span class="indent4">DIAT:G-1: Authoring
Practice</span></p>

<p class="goal"><span class="indent4">Identify the current and proposed
techniques to support authoring for multiple devices, and present these as
abstractions of the process from the original authoring step up to and
including the final delivery of content to the access mechanism.</span></p>

<p class="goal-heading"><span class="indent4">DIAT:G-2: Adaptation
Techniques</span></p>

<p class="goal"><span class="indent4">Identify the range of content
adaptation techniques and how they may be applied at the different stages of
the delivery process (from server through intermediaries to the
device).</span></p>

<p class="goal-heading"><span class="indent4">DIAT:G-3:
Requirements</span></p>

<p class="goal"><span class="indent4">Identify the requirements that should
be satisfied by implementations of techniques identified in this document. In
particular, this relates to the technical requirements for markup languages
and other technologies offered by the W3C.</span></p>

<p class="goal-heading"><span class="indent4">DIAT:G-4: XForms</span></p>

<p class="goal"><span class="indent4">Identify techniques, based on XForms,
to support device-independent navigation and interaction. These techniques
must support the tailoring of presentation, interaction modes and navigation
within form-based Web applications.</span></p>

<h4 class="indent3"><a name="currentPractices"></a>1.2.2 Current Practices
and Techniques</h4>

<p class="indent4">This document shall identify known (published) practices
and techniques that address the following issues:</p>
<ul>
  <li>Creation of original, reusable and adaptable content</li>
  <li>Representation of author intentions and decisions</li>
  <li>Creating and adapting navigation features</li>
  <li>Design and adaptation of interactive content</li>
  <li>Use and management of contextual information</li>
</ul>

<p class="indent4">The focus shall be on open and accessible standards and
"best" practices, particularly those advocated by W3C Recommendations and by
respected organizations.</p>

<h3 class="indent3"><a name="sec3Audience"></a>1.3 Audience</h3>

<p class="indent3">This Note is intended as background material for people
interested in the techniques associated with delivering content and
applications from web sites to devices with very different capabilities. It
assumes that the reader is familiar with the Authoring Challenges document
[<a href="#refAC">AC</a>] that preceded this document.</p>

<p class="indent3">In particular, the audience for this Note includes:</p>
<ul>
  <li>individuals from W3C Member organizations with an interest in authoring
    for multiple devices</li>
  <li>members of W3C Working Groups who are evolving existing markup
  standards</li>
  <li>companies engaged in developing systems that support authoring for
    multiple devices</li>
  <li>individuals and organizations that design and develop web
  applications</li>
  <li>device experts</li>
</ul>

<h3><a name="objectives" class="indent3">1.4 Objectives of Authoring
Techniques</a></h3>

<p class="indent3">The objective of authoring is to create content for an
audience. The objective of content delivery is to convey the authored content
to the audience. In general, the objective of Device Independent Authoring
Techniques is to facilitate content delivery to as wide an audience as
possible while:</p>
<ul>
  <li>respecting the constraints of the end user devices,</li>
  <li>taking advantage of specific features of end user devices and</li>
  <li>respecting, where possible, the known preferences of the end user.</li>
</ul>

<p class="indent3">Each technique has technical and non-technical
motivations, described below. Technical motivations refer to technical issues
raised by increasing variety of devices and device features. Non-technical
motivations refer to issues raised by people (authors and end users), the way
they create and consume content, the business processes and other human
activities that form the context of the Web.</p>

<p class="indent3"><em>Authoring Techniques</em> are ways in which various
technologies can be utilized to minimize the number and types of materials
that need to be created to satisfy a range of device types. The techniques
also provide mechanisms for incremental additions to the set of materials
created to support a Web Page to enable it to be better adapted to a device
(or class of devices). Most of these techniques involve the provision of
alternatives and a mechanism to choose between these alternatives at run
time. These techniques must:</p>
<ul>
  <li>Capture suitability to particular delivery contexts</li>
  <li>Take account of Authoring Challenges: Variability, Scalability and
    Affordability</li>
</ul>

<p class="indent3">Ultimately, the most important feature of an authoring
technique is its ability to produce a good rendering on the client of the
original content created by the author. This is a subjective assessment and
is beyond the scope of this document.</p>

<h4 class="indent4"><a name="technicalMotivation"></a>1.4.1 Technical
Motivation</h4>

<p class="indent4">In a strict sense, a Device Independent Authoring
Technique is a method of creating content that can be delivered to any
conceivable device. In practice this is impossible, so the real techniques
seek to minimize the number of materials needed to satisfy a range of device
types. There are many different types of material that are needed to satisfy
a user request for a Web Page. These include various types of media that
constitute the content of the page as well as supporting material such as
styling and layout rules that determine how the content is rendered.</p>

<p class="indent4">The creation of these materials is what we call
<em>Authoring</em> and typically these materials must be adapted for delivery
to specific devices. The construction of adaptation processes may also be
regarded as a form of authoring, though more usefully regarded as a form of
programming. Authoring of raw material, styles, layouts and adaptation
processes may be performed by different individuals with different skills,
which support specialization of the various contributors. The technical
challenge is to facilitate this separation of concerns.</p>

<h5 class="indent5"><a name="tmVariability"></a>1.4.1.1 Variability</h5>

<p class="indent5">One of the identified Authoring Challenges is Variability,
by which is meant the ability of an authoring technique to vary the content
according to the delivery context. Technically, this requires access to
parameters defining the delivery context and a means of content selection
according to these parameters. Some authoring techniques seek to expose as
many parameters as possible, accompanied by powerful selection methods. Other
techniques seek to abstract these parameters while making the selection
process as implicit as possible. The former approach gives the author more
control but requires more effort, while the latter sacrifices control to
reduce effort.</p>

<h5 class="indent5"><a name="tmScalability"></a>1.4.1.2 Scalability</h5>

<p class="indent5">A technique that is suitable for a small amount of content
should also be suitable for a large amount. Ideally, the amount of additional
effort should scale with the amount of content.</p>

<h4 class="indent4"><a name="nonTechMotivation"></a>1.4.2 Non-technical
Motivation</h4>

<p class="indent4">The non-technical motivation for Device Independent
Authoring Techniques is centered around the requirements and constraints
imposed by the creators of content and the audience for this content. In
simple terms: time is precious, effort is expensive, users are demanding and
consistency is desirable.</p>

<h5 class="indent5"><a name="ntmAffordability"></a>1.4.2.1 Affordability</h5>

<p class="indent5">Creating content is an expensive and time-consuming
activity. It is expensive because it consumes the time of the authors. It is
generally accepted that additional effort by authors is required for Device
Independence, and the various authoring techniques attempt to minimize this
additional effort. There are other costs, such as the investment in
adaptation mechanisms, but these tend to be less significant.</p>

<h5 class="indent5"><a name="ntmAccessibility"></a>1.4.2.2 Diversity of
Devices</h5>

<p class="indent5">Authors intend their content to be accessed by as large an
audience as possible, regardless of the constraints of the delivery context.
The majority of these constraints come from the limitations of the end user
devices, though similar constraints can be imposed by the end users
themselves. An authoring technique should overcome the constraints so that
the greatest number of delivery contexts can be supported.</p>

<h5 class="indent5"><a name="ntmBranding"></a>1.4.2.3 Branding and
Consistency</h5>

<p class="indent5">Branding is a business motivation that seeks to present a
consistent image of the business across the spectrum of delivery contexts.
Consistency also reduces end-user confusion, thereby giving the end-user more
freedom to migrate from one device to another as circumstances may dictate. A
Device Independent Authoring Technique should support the consistency of the
end-user experience.</p>

<h3 align="left"><a name="sec5Organisation" class="indent3">1.5 Organization
of the Material</a></h3>

<p class="indent3">Section 2 describes a classification of Authoring
Techniques that shall be referred to in subsequent sections. Section 3
describes the Delivery Context, whose variability is the prime motivation for
Device Independent Authoring, as explained in Section 4. Section 5 introduces
some general authoring techniques whose application spans numerous
classification, and explains that most Device Independent Authoring
Techniques aim to support variability in six aspects: Style, Layout, Content,
Structure, Navigation and Interaction. Techniques specific to these aims are
covered in Sections 5 through 10. Section 11 summarizes the Authoring
Techniques Workshop, the event that marked the beginning of this document.
Section 12 draws conclusions from the document.</p>

<p class="indent3">The focus of this document is on Device Independent
Authoring, but this is inevitably associated with Adaptation Techniques,
details of which are presented in Appendix B. The adaptation of content may
also necessitate adaptation of structure, so a brief summary of
content-related structures is presented in Appendix C. The appendices may be
read independently of the rest of the document.</p>

<h3><a name="sec5Terminology" class="indent3">1.6 Terminology</a></h3>

<p class="indent3">The Device Independence Working Group has defined a number
of terms related to Device Independence. This Note adopts these terms as
presented in the Glossary of Terms [<a href="#refGlossary">DIWG
Glossary</a>].</p>

<h2 class="indent2"><a name="classification"></a>2 Classification of
Authoring Techniques</h2>

<p class="indent2">Three broad classifications of authoring techniques are
identified in this section. In all classifications, the following features
are assumed:</p>
<ol>
  <li>Regardless of the access mechanism, the device independence principle
    [DIP-2] of having a single URI will hold.</li>
  <li>DIP-2 only applies to the Web Page Identifier. It does not necessarily
    have to apply to resources subsequently referenced. For example, the URI
    of a page will adhere to DIP-2, but the URIs of images within the page
    may differ according to the device context.</li>
  <li>There may be one or more authors who contribute to the production of a
    presentation page. In the case of multiple authors there is <i>no
    requirement</i> that all participating authors will use the same
    authoring techniques. In the classifications described below, the term
    "author" shall be assumed to include the plural case.</li>
  <li>The current set of W3C Recommendations shall be the basis of authoring
    techniques. It is recognized that the absence of a Recommendation for
    Device Independent authoring means that the techniques may rely on
    proprietary solutions, but that where this is the case the solutions
    shall be in a manner consistent with established W3C approaches.
    Significantly divergent solutions (e.g. OO-based content generation via
    object serialization) are not considered here.</li>
</ol>

<p class="indent2">The Authoring Challenges [<a href="#refAC">AC</a>]
document highlighted a number of (overlapping) challenges facing content
authors. The document identified 55 implications [<a
href="#appDIAI">DIAI</a>] of Device Independence within 10 categories (listed
in <a href="http://www.w3.org/TR/acdi/#sec-conclusions-categorising">AC
Section 8.1</a>), reproduced below.</p>
<ol>
  <li>Provide Comprehensive Scope (diverse set of delivery options)</li>
  <li>Support Smooth Extensibility (new technology smoothly and easily
    accommodated)</li>
  <li>Support Simplicity (a little effort can produce a functional
  result)</li>
  <li>Support Abstraction (can use abstractions of devices, interaction and
    other aspects of authoring/delivery)</li>
  <li>Support Delivery Context Variability (DC may influence the
  presentation)</li>
  <li>Support Author Specified Variability (permit selections, aggregation,
    layout and related decisions)</li>
  <li>Client-Side Processing (scripts, objects, browser functions etc.)</li>
  <li>Extensions to Existing W3C Standards (use and extend W3C
  technologies)</li>
  <li>Context Aware (modality, language and other influencing parameters)</li>
  <li>Affordability (supports reuse, avoid duplication of effort and
    resources, future-proof)</li>
</ol>

<p class="indent2">Some, but not all, of these features are provided by
current technology. It will be obvious to readers of this document that there
are gaps between the identified challenges of Device Independence and the
available authoring techniques. Closing these gaps is a prime motivation of
the DIWG.</p>

<p>The following subsections introduce the three main classifications of
authoring techniques. General descriptions are followed by concrete examples
(including markup where appropriate). All of these authoring techniques rely
on various adaptation techniques, discussed in Appendix B.</p>

<h3 class="indent3"><a name="sec1MultipleAuthoring"></a>2.1 Multiple
Authoring</h3>

<p class="indent3">In the Multiple Authoring classification, the author
creates a different version of the content for each (class of) device.
Devices that have not been specifically addressed by the author may result in
lack of service for such devices, in contravention of <a
href="http://www.w3.org/TR/di-princ/#DIP-3">DIP-3</a>, which states "<i>It
should be possible to provide a functional presentation, in response to a
request for a Web page identifier, in any given delivery context that has an
adequate access mechanism</i>." To avoid such a contravention, a delivery
solution may select an available authored version that is functionally
compatible with the context, but there is no guarantee of such
availability.</p>

<p class="indent3">There are certain cases where Multiple Authoring is
preferred. The production of multimedia resources may require additional
author input, such as the creation of corporate branding resources (e.g.
logos) at various sizes and resolutions. This is a case where "pixel perfect"
control is an essential feature for the author with sound business reasons
for avoiding less precise methods.</p>

<h4 class="indent4"><a name="multAuthAssocAdapt"></a>2.1.1 Associated
Adaptation Techniques</h4>

<p class="indent4">The ability to select from a set of possible versions of
content can be supported by techniques such as URL Redirection (by
server-side adaptation) or Server Selection (by an intermediate adaptation
such as a Proxy). Client-side selection-based adaptation is also supported by
various technologies.</p>

<h3 class="indent3"><a name="sec2SingleAuthoring">2.2 Single
Authoring</a></h3>

<p class="indent3">In the Single Authoring classification, most of the
author's effort is focussed on creating a single version of the content. An
adaptation solution translates the single authored content into a form
appropriate to the device. The author may have the requirement/option to
provide additional information to assist the adaptation solution. Typically
the effort involved in creating the single version of content is greater than
any individual version created by a Multiple Authoring technique. However,
this effort is expended only once and therefore Single Authoring techniques
involve less total effort.</p>

<p class="indent3">In some Single Authoring techniques, the author may be
required to create one or more resources for each delivery context. The
resources may take the form of styles, scripts, configurations etc. However,
these resources can be re-used and are therefore considered to be a once-off
effort. These resources are also "Single Authored".</p>

<p class="indent3">Some Single Authoring techniques are described below.
Corresponding adaptation techniques are described in Appendix B.</p>

<h4 class="indent4"><a name="exAuthorHints"></a>2.2.1 Example: Author
Hints</h4>

<p class="indent4">Hinting is the means by which an author conveys meta-data
related to parts of the authored content. For example, an author may express
the relative importance of parts of the content through hints. Hints may be
represented within the authored content as additional markup, additional
attributes, specially formatted comments etc. These can be added to familiar
Web markup (e.g. XHTML) via an authoring-specific markup module. It is also
possible to represent hints outside of the document if parts of the authored
content can be addressed individually (e.g. using XPath).</p>

<p class="indent4">Where custom modules or extensions to a markup language
are used in the authoring solution, it is expected that these extensions are
not visible beyond the authoring/adaptation environment.</p>

<h4 class="indent4"><a name="exCSSMQ"></a>2.2.2 Example: CSS Media
Queries</h4>

<p class="indent4">In CSS <a href="#refMediaQueries">Media Queries</a>, the
author defines rules based on contextual information. These rules are
typically captured as a class and XHTML tags in a document may be assigned a
class via the <i>class</i> attribute. The rules then affect the presentation
of content associated with the class. These rules may be executed by the
client, by an intermediate or by the origin server.</p>

<p class="indent4">CSS Media Queries require that the author is familiar with
specific device features. Abstract characteristics are not generally
supported. The expression language cannot (currently) be extended. Future
versions of CSS Media Queries may address these shortcomings.</p>

<p class="indent4">The following sample (from <i><a
href="http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708/#color-index">http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708/#color-index</a></i>)
illustrates the use of Media Queries to indicate that a particular stylesheet
is appropriate to delivery contexts involving displays with at least 256
colors:</p>
<a name="sampleStyleSelectMQ"></a>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent4">
  <tbody>
    <tr>
      <td><pre class="indent4">&lt;?xml-stylesheet
  <b>media="all and (min-color-index: 256)"</b>
  href="http://www.example.com/..."
?&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 1 : Stylesheet selection via Media Queries</p>

<h4 class="indent4"><a name="multAuthAssocAdapt2"></a>2.2.3 Associated
Adaptation Techniques</h4>

<p class="indent4">Adaptation techniques associated with the authoring
techniques in this section include the following: (More details may be found
in Appendix B.)</p>
<dl class="indent4">
  <dt>Transcoding</dt>
    <dd>Conversion of non-presentation (domain-specific) content to a
      presentation form (e.g. News Markup Language [<a
      href="#refNewsML">NewsML</a>] to XHTML), or the conversion of one
      presentation form into an alternative presentation form supported by
      the client (e.g. XHTML to WML).</dd>
  <dt>Image/Binary Transcoding</dt>
    <dd>Changing the formats/resolutions of media resources (e.g. images) to
      suit the delivery context (e.g. TIFF to PNG).</dd>
  <dt>Decomposition</dt>
    <dd>Dividing the original content into smaller parts to accommodate
      limited display capabilities.</dd>
</dl>

<h3 class="indent3"><a name="sec3FlexibleAuthoring"></a>2.3 Flexible
Authoring</h3>

<p class="indent3">In the Flexible Authoring classification, the author has
complete freedom to combine Single and Multiple Authoring techniques. Thus
the author may create single versions of some resource(s) for subsequent
adaptation, and multiple versions of other documents when fine control or
specific features are required. This flexibility may also be applied within a
document where part of the document uses Single Authoring and the rest uses
Multiple Authoring.</p>

<h4 class="indent4"><a name="exLayouts"></a>2.3.1 Example: Layouts and
Portals</h4>

<p class="indent4">In a layout-based authoring technique, the author provides
separate pieces of content. Some or all of these pieces are subsequently
aggregated into a complete presentation using a layout as determined by the
context. Portal systems are examples of such an approach, where each portlet
is an individually authored piece of content that is aggregated (and possibly
adapted) into a context-appropriate layout. A detailed discussion of layout
authoring techniques is presented in Section 8.</p>

<h4 class="indent4"><a name="exAltContent"></a>2.3.2 Example: Alternative
Content</h4>

<p class="indent4">The alternative content authoring technique is a form of
Flexible Authoring applied within a document. It permits the author to
express a set of alternative content fragments/resources and a means of
selection within the set. An ordering may be imposed on the set to influence
the selection mechanism. Client-side methods have been available for some
time (viz. &lt;frames&gt; and &lt;noframes&gt;) but incomplete support in
clients makes this useful only in limited cases. Current technologies provide
more sophisticated solutions, such as the switch mechanism in SMIL as in <a
href="#contentSMIL">section 7.2.1</a>.</p>

<h4 class="indent4"><a name="flexAuthAssocAdapt"></a>2.3.3 Associated
Adaptation Techniques</h4>

<p class="indent4">In addition to the adaptation techniques associated with
single authoring, the following adaptation techniques are prevalent among
flexible authoring solutions: (More details may be found in Appendix B.)</p>
<dl class="indent4">
  <dt>Selection</dt>
    <dd>The selection of content resources from the set of available
      resources under the influence of the delivery context and using
      decisions determined by the author.</dd>
  <dt>Generated Navigation</dt>
    <dd>The creation of navigation aids (e.g. menus) from the adapted
    content.</dd>
  <dt>Intermediate and Client Adaptation</dt>
    <dd>The adaptation of content by an intermediate process (e.g. a proxy)
      or by the client itself.</dd>
</dl>

<h2><a name="deliveryContext" class="indent2">3 Delivery Context</a></h2>

<p class="indent2">The delivery context [described in <a
href="#refDCO">DCO</a>] is the set of all (available) parameters pertaining
to the characteristics of the delivery channel, which includes the server,
the communication media, intermediate active components, the edge device and
the rendering mechanism. It is expected that a subset of the delivery context
will influence what is delivered to the client and how it is delivered. In
solutions that provide device independence, it is typically the case that the
delivery context influences the content adaptation processes. The content
author will optionally provide additional information to affect this
adaptation within particular contexts.</p>

<h3 class="indent3"><a name="sec1AuthorAwarenessOfContext"></a>3.1 Author
Awareness of Context</h3>

<p class="indent3">In practice, several technologies permit the author to
insert rules into the content whose execution is influenced by certain core
device characteristics, including the selection of layouts. This means that
the author is made aware of at least some of the delivery context parameters,
and consequently the success of the authoring process may depend on the
author's correct understanding of these parameters.</p>

<p class="indent3">The more parameters that are offered to the author, the
more confusing the authoring process can become. For this reason, context
information can be aggregated and/or classified so that the author may apply
decisions to greater ranges of possible contexts. As an example, consider an
adaptation solution that includes the orientation of the screen (portrait,
square or landscape) as a parameter, rather than offering the exact aspect
ratio. Alternatively, the author may be provided with a library of methods to
simplify the task. For example, consider a method called "isPortrait" that
uses the specific aspect ratio to decide if the display is portrait.</p>

<p class="indent3">CSS Media Queries are a good illustration of author
awareness of context. Only a small number of attributes are present, and the
operations on these attributes are limited. Nevertheless, this is sufficient
for the author to control styling for various classes of device. Fine control
of styling is not possible because of the limited set of attributes and
limited operations. For this the author must resort to more complex
techniques with a more complete set of presentation attributes. To this end,
the DIWG is working to create a core set of presentation characteristics [<a
href="#refCPCReq">CPCReq</a>].</p>

<h3 class="indent3"><a name="contextAuthAssocAdapt"></a>3.2 Associated
Adaptation Techniques</h3>

<p class="indent3">Context is used in all adaptation techniques since the
objective of adaptation is to produce a result that is appropriate to the
context. In some techniques (e.g. Selection) the author is aware of the
context and supplies information related to the context (e.g. decision
expressions). In other techniques (e.g. Decomposition) the relevant
contextual information only plays a role after authoring.</p>

<h2><a name="generalTechniques" class="indent2">4 General Authoring
Techniques</a></h2>

<p>There are two general techniques for Device Independent Authoring. They
are, in accordance with the classification introduced in Section 2, as
follows:</p>
<ul>
  <li>Multiple Authoring with Contextual Selection (MA/CS)</li>
  <li>Single Authoring with Contextual Adaptation (SA/CA)</li>
</ul>

<p>These, however, are extremes in a spectrum of techniques. MA/CS is an
extreme because it places a significant burden on the author, and SA/CA is an
extreme because it places a significant burden on the adaptation. In simple
and constrained circumstances, these techniques may be viable, but generally
they are inflexible, will not scale and are onerous to maintain.</p>

<p>Compromises between the two extremes can produce useful techniques, which
will be explored in detail in subsequent sections.</p>

<h3 class="indent3"><a name="aspectsOfAuthoring"></a>4.1 Aspects of
Authoring</h3>

<p class="indent3">To facilitate compromise, the objectives of authoring can
be divided into several aspects, and different authoring techniques can be
applied to the different aspects. The following (overlapping) authoring
aspects are generally recognized:</p>
<dl class="indent3">
  <dt>Style</dt>
    <dd>The visual appearance of text (e.g. fonts and color) and minor layout
      features such as text justification and indentation.</dd>
  <dt>Layout</dt>
    <dd>The visual or temporal relationship of parts of the delivered
    content.</dd>
  <dt>Content</dt>
    <dd>The raw text (or speech) and other media resources forming part of
      the delivery, intended to convey some information to the end user.</dd>
  <dt>Structure</dt>
    <dd>The relationship between parts of the delivered content and
      subsequently delivered content, typically being the dominant influence
      on navigation.</dd>
  <dt>Navigation</dt>
    <dd>The features offered to the user to enable the user move from the
      currently perceived unit to some related perceived unit, with the
      minimum of user effort.</dd>
  <dt>Application Interaction</dt>
    <dd>The manner in which the user conveys information to the origin server
      via features of the delivered content, for the purpose of influencing
      subsequent content delivery and/or associated applications.</dd>
</dl>

<p class="indent3">Each of these aspects can be addressed by different
authoring techniques if the aspect can be sufficiently detached from the
others. For example, Style can be separated through the use of Cascading
Style Sheets (CSS), which affords the author the opportunity to use multiple
styles for the same raw content.</p>

<h3 class="indent3"><a name="ATForSpecificAspects"></a>4.2 Authoring
Techniques for Specific Aspects</h3>

<p class="indent3">Sections 5 through 10 will explore different authoring
techniques that enable the author to vary different authoring aspects
according to the delivery context. These techniques would normally be used in
combination to achieve maximum benefit and should not be considered as
solutions in isolation. Many of these techniques rely on specific
adaptations, which are subsequently documented in Appendix B.</p>

<h2><a name="varyStyle" class="indent2">5 Techniques to Vary Style for
Different Delivery Contexts</a></h2>

<p class="indent2">Changes in style will change the presentation of resources
without actually changing the resource itself. Sometimes the changes are
considerable, such as making the content invisible. Sometimes the changes are
more subtle, such as indenting by a few pixels. Since these changes
predominantly affect the appearance of content, the appropriate authoring
tools support WYSIWYG editing and/or device emulation. It is then the
author's task to determine which styles suit the various delivery
contexts.</p>

<h3 class="indent3"><a name="contextSensStyle"></a>5.1 Context-sensitive
Style Selection</h3>

<p class="indent3">The delivery context can influence the selection of
styles. In particular, this feature is provided in CSS Media Queries. The
author creates (or acquires) different style sheets appropriate to the range
of style-capable devices to be supported and then determines the conditions
under which each style will be used. These conditions are then expressed
using CSS Media Queries. The client first retrieves the resource and then
retrieves the appropriate style in accordance with the conditions.</p>

<h3 class="indent3"><a name="scriptedStyle"></a>5.2 Scripted Style
Selection</h3>

<p class="indent3">The styles associated with elements in delivered content
may be accessible (via a DOM) to scripting on the client. So, for example,
the author may include script in the content that responds to events and
changes the styles accordingly. This technique is used to provide content
that becomes highlighted when the user points to certain regions (e.g.
mouseover events) and regions of the content that "collapse" by changing the
style to invisible.</p>

<p class="indent3">In some cases, aspects of the delivery context can be
determined by client-side scripts, which enables them to make adjustments to
the styles applied to the delivered content. For example, the font size could
be reduced when the content is rendered in a small window.</p>

<p class="indent3">Client-side scripting tends to be the most
device-sensitive technology and consequently non-portable. Therefore the
author must resort to creating different scripts for the different devices,
and sometimes no scripted features at all when the behavior is not supported
by the device. Scripted style cannot be considered a viable device
independent style authoring technique.</p>

<h3 class="indent3"><a name="serverSideStyling"></a>5.3 Server-side
Styling</h3>

<p class="indent3">In cases where the client does not support styles, it is
still possible for the author to use styles in the original content. An
adaptation process in the origin server (or intermediate) would replace the
styling with explicit presentation features, such as &lt;font&gt; tags. The
WYSIWYG aspect of authoring in these circumstances needs to incorporate the
adaptation process in order to determine the effects of the adaptation.</p>

<p class="indent3">The context-sensitive capability of technologies such as
Media Queries can be supported in server-side styling with the aid of context
carrying technologies (e.g. CC/PP and UAProf). Scripted style selection is
generally not possible, since this is a client-side function.</p>

<h3 class="indent3"><a name="xformsStyling"></a>5.4 XForms Styling</h3>

<p class="indent3">XForms provides an "appearance" attribute that can be
specified on all Form Controls. This provides an author with the ability to
provide a hint to the component responsible for rendering XForms Form
Controls. There are three pre-specified values: full; compact; minimal; and
an ability for an author to define their own value but with no pre-specified
meaning.</p>

<p class="indent3">The attribute does not specify what exactly is to be
rendered but is merely a hint. The XForms &lt;select1&gt; control is a good
example to consider. The following are an explanation of how the hints should
be interpreted for this control:</p>
<dl class="indent3">
  <dt>Full</dt>
    <dd>The entire set of alternatives that the user is to choose from should
      be presented simultaneously to the user. On a personal computer browser
      this could be represented as radio buttons.</dd>
  <dt>Minimal</dt>
    <dd>The smallest number of alternatives that the user is to choose from
      should be presented simultaneously to the user and they should be
      provided with a method to explore the other alternatives. On a personal
      computer browser this could be represented as a drop down list.<span
      class="newtext"><span class="newtext"></span></span></dd>
  <dt>Compact</dt>
    <dd>A subset of alternatives that the user is to choose from should be
      presented simultaneously to the user and they should be provided with a
      method to explore the other alternatives. On a personal computer
      browser this could be represented as a list box.</dd>
</dl>

<h2><a name="varyLayout" class="indent2">6 Techniques to Vary Layout for
Different Delivery Contexts</a></h2>

<p class="indent2">To enable support for the wide variation in the output
capability of different delivery contexts, it is necessary to be able to
provide a variety of different layouts. Variations in the size and aspect
ratio of displays, for example, can mean that a different physical layout is
required to support a harmonized user experience.</p>

<p class="indent2">The DIWG Authoring Challenges specify the following
requirement for layout.</p>

<blockquote>
  <p><b>DIAC-4.3: Layout</b>: <i>Authoring techniques that support DI should
  provide mechanisms that allow authors to express the layout of material
  that varies between different devices with different delivery contexts. In
  particular, they should support different spatial and temporal layout of
  material.</i></p>
</blockquote>

<p class="indent2">Although it is possible to arrange for explicit
representations of layout using commonly available technologies, such as
XHTML and CSS, it is unusual to find such an approach being used in current
web sites. This section covers the basic principles associated with explicit
provision of layout, and examines a number of current techniques.</p>

<h3 class="indent3"><a name="layoutPrinciples"></a>6.1 Principles</h3>

<p class="indent3">The basic principles of using explicit layouts are the
same as those for any properties that may vary between delivery contexts.
First, there must be an explicit representation of the properties, in this
case the layouts. Second there must be a method by which the layout can be
referenced in a manner that is independent of the delivery context.</p>

<h4 class="indent4"><a name="varyLayoutPrincLayoutRep"></a>6.1.1 Explicit
Layout Representations</h4>

<p class="indent4">The kind of information needed for an explicit layout is
information that will allow the basic differences between delivery contexts
to be taken into account. For example, one of the major differences between
delivery contexts for display devices is the number of pixels that can be
used. Another is the aspect ratio.</p>

<p class="indent4">Layout representations typically divide the output into a
number of areas in which content can be placed. An individual area might
contain a single piece of content, such as an image, or a large amount of
content, such as several paragraphs of text. These areas are not limited to
representing spatial display. Some systems allow them to represent temporal
information allowing control over spoken output, for example.</p>

<h4 class="indent4"><a name="varyLayoutPrincMapContentToLayout"></a>6.1.2
Mapping Content to Layout</h4>

<p class="indent4">To make use of an explicit layout representation there
must be a way to assign content to particular areas of the layout. Current
techniques make use of direct references from the markup that defines the
content to the layout representation. These references use names. Areas in
the layout have some unique name or ID. The content to be assigned to a
particular area references it using that name or ID. Where multiple pieces of
content reference the same area, simple rules define the ordering of output
within the area. Usually this is based on the order in which the references
are encountered within the content.</p>

<h3 class="indent3"><a name="layoutCSS"></a>6.2 Using CSS for Explicit
Layout</h3>

<p class="indent3">CSS is able to provide the basic functions referred to in
DI Principles. For example, it is possible to associate size and position
information with, for example, &lt;div&gt; elements, with particular IDs, in
a style sheet. By using &lt;div&gt; elements with those IDs when authoring
content, material can be targetted to a particular place in the layout.</p>

<h4 class="indent4"><a name="varyLayoutCSSMQ"></a>6.2.1 CSS Media Queries</h4>

<p class="indent4">The ability to associate subsets of a style sheet with
particular properties associated with a device makes it possible to have
several versions of the &lt;div&gt; styles in a single sheet and to select
the one most appropriate.</p>

<h4 class="indent4"><a name="varyLayoutDevDepStyle"></a>6.2.2 Device
Dependent Stylesheets</h4>

<p class="indent4">Current capabilities for selecting different styles from
within a single CSS are rather limited for general use in device
independence. However, systems with specialist adaptation mechanisms, which
can select between different versions of entire style sheets, exist and could
be employed to give greater control. Some commercial systems are capable of
this kind of adaptation of style sheets.</p>

<h3 class="indent3"><a name="layoutSMIL"></a>6.3 Using SMIL for Explicit
Layout</h3>

<p class="indent3">SMIL 2.0 includes an explicit layout notion based on its
&lt;layout&gt;, &lt;root-layout&gt; and &lt;region&gt; elements. SMIL
contains a number of layout modules for specific types of rendering,
including multi-window visual display and audio display. As such, it is a
good example of the ability of layouts to represent both spatial and temporal
information.</p>

<p class="indent3">The following example illustrates how two pieces of text
can be positioned using SMIL:</p>
<a name="sampleTextPosSMIL"></a>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent5">
  <tbody>
    <tr>
      <td><pre> 
&lt;smil xmlns="http://www.w3.org/2001/SMIL20/"&gt;
 &lt;head&gt;
  &lt;layout&gt;
   &lt;root-layout width="320" height="480" /&gt; 
   &lt;region id="a" top="5" bottom="100" /&gt;
   &lt;region id="b" top="200" bottom="280" /&gt;
  &lt;/layout&gt;
 &lt;/head&gt;
 &lt;body&gt;
  &lt;text region="a" src="text.html"/&gt;
  &lt;text region="b" src="additional_text.html"/&gt;
 &lt;/body&gt;
&lt;/smil&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 2 : Text positioning via SMIL</p>

<p class="indent3">The layout defines two regions within a root-layout. The
size of the root-layout determines the physical size of the displayed
material, in this case 320 pixels in width and 480 pixels in height. Within
this root-layout two regions are defined. Both are the full width of the
root-layout. The first starts 5 pixels below the start of the root-layout.
The second starts 200 pixels below the start of the root-layout.</p>

<p class="indent3">The &lt;body&gt; element within the example defines two
&lt;text&gt; elements. Each of these assigns text to one of the regions in
the layout.</p>

<p class="indent3">There is a clear logical separation here between the
information in the layout and the way content is mapped to it. If the layout
is modified, the final presentation can be varied without the content being
changed. Similarly the content can be changed without affecting the layout.
Only the id of the &lt;region&gt; element links the content with the
layout.</p>

<p class="indent3">Currently, it is possible for an implementation of SMIL to
have its own mechanism for allowing different versions of a layout to be
associated with some context attributes, and a mechanism to support custom
attributes, thereby providing the means to use delivery context data.</p>

<p class="indent3">In conjunction with a server side adaptation that, for
example, constructs the SMIL markup from definitions of content and an
appropriate layout, this markup shows nearly all of the characteristics
needed for support of multiple delivery contexts.</p>

<h3 class="indent3"><a name="layoutVolantis"></a>6.4 Existing Layout
Techniques</h3>

<p class="indent3">Implementation details of several layout techniques are
outlined in an accompanying Submission document [<a
href="#ATSub">ATSub</a>].</p>

<h2><a name="varyContent" class="indent2">7 Techniques to Vary Content for
Different Delivery Contexts</a></h2>

<h4 class="indent4"><a name="contentOrderedDelivery"></a>7.1 Ordered
Delivery</h4>

<p class="indent4">An author will wish to have control over the order in
which parts of the content are delivered, typically to reflect dependencies
within the content. Structures with a natural order can define a traversal of
the content. Typically these structures will have a well-defined origin,
which is important to identify the entry point. Of less importance is an exit
point in the structure, since most usage patterns do not require a specific
exit procedure.</p>

<p class="indent4">The use of links to the next, and previous, content
relative to the most recently delivered content can facilitate navigation of
linear and hierarchical content structures. Several Web site authoring tools
will automate the creation of these navigation aids. Many browsers maintain a
navigation history that is accessible to client-side script, with which the
author may provide a "Previous/Back" linking feature.</p>

<p class="indent4">In more complex situations (e.g. e-commerce Web sites) the
determination of the "Next" page is done by an application using session
information. The author would employ a workflow approach to enable the
application determine the order of delivery. Such techniques are beyond the
scope of this document.</p>

<h4 class="indent4"><a name="contentSelection"></a>7.2 Selection
Techniques</h4>

<p class="indent4">Selection techniques solve the problem of choosing from
the available fragments of content to create a presentation for the user.
Selections are typically based on matching certain characteristics of the
delivery context to features of the content fragments. Below are examples of
established selection techniques and the technologies that employ them.</p>

<h5 class="indent5"><a name="contentSMIL"></a>7.2.1 SMIL &lt;switch&gt;
Element</h5>

<p class="indent5">The Synchronized Multimedia Integration Language (version
2.0) [<a href="#refSMIL">SMIL 2.0</a>] allows authors to create interactive
multimedia presentations. Authors can describe the temporal behavior of a
multimedia presentation, associate hyperlinks with media objects and describe
the layout of the presentation on a screen.</p>

<p class="indent5">In SMIL, the &lt;switch&gt; element enables an author to
specify a list of alternative elements, selected according to Boolean tests.
The first acceptable element in the list is chosen. A default selection can
be defined as the last element in the set by having no constraints, as
illustrated below.</p>

<p class="indent5"><a name="sampleSMIL"></a></p>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent4">
  <tbody>
    <tr>
      <td><pre class="indent4"> 
&lt;smil:switch&gt;
  &lt;html:img
    src="bigColorImages/logo.gif"
    title="Company logo"
    alt="logo"
    <b>smil:systemScreenSize="768X1024"</b> /&gt; 
  &lt;html:img
    src="smallMonoImages/logo.gif"
    title="Company logo"
    alt="logo"
    <b>smil:systemScreenSize="160X160"</b> /&gt; 
  &lt;html:img
    src="defaultImages/logo.gif"
    title="Company logo"
    alt="logo" /&gt;
&lt;/smil:switch&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 3 : SMIL Switch to select alternative
content</p>

<p class="indent5">SMIL test attributes are permitted outside &lt;switch&gt;
elements, though this usage does not permit selection from a set of
alternatives, nor does it support the concept of defaults.</p>

<h5 class="indent5"><a name="contentCSSMQ"></a>7.2.2 CSS Media Queries</h5>

<p class="indent5">CSS Media Queries [<a href="#refMediaQueries">Media
Queries</a>] is a W3C Working Draft to enhance the @media rules of CSS and
the "media" attribute in HTML. Using a Media Queries expression, it is
possible to select a stylesheet based on context properties. The recognized
set of properties covers a small range that includes size, resolution, type
of device and color capability. The following example illustrates the
selection of a style sheet based on the device type:</p>
<a name="sampleMQTag"></a>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent4">
  <tbody>
    <tr>
      <td><pre class="indent5"> 
&lt;link
  rel="stylesheet"
  type="text/css"
  media="handheld"
  href="portabledevice.css"
&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 4 : Selection of style sheet using Media
Queries in tag attributes</p>

<p class="indent5">Here is a another expression as it would be represented in
CSS:</p>
<a name="sampleMQImport"></a>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent4">
  <tbody>
    <tr>
      <td><pre class="indent5"> 
@media screen and (max-device-width: 300px) {
  @import url(narrowwindow.css)
}</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 5 : Importing a style sheet using Media
Queries in a style sheet</p>

<p class="indent5">Media Queries avoids the escaped versions of characters
"&lt;", "&gt;" and "&amp;" in expressions by using "min-" and "max-"
prefixes. It also uses "and" for conjunctions, and "," for disjunctions. This
makes the expression syntax easier to read, which is important if the
expressions are to be hand-crafted and later read by humans (possibly for
maintenance purposes). With the increasing use of authoring tools, this
"legibility" feature of the expression language may become less important.</p>

<p class="indent5">It is generally assumed that the Media Queries expressions
will be processed by the client. This does not preclude the processing of
Media Queries (and CSS in general) at some other point in the delivery path,
such as in an intermediate system or in the origin server itself.</p>

<p class="indent5">Unfortunately, Media Queries is limited and inextensible
in its current form and is therefore suitable only for simple multi-device
solutions.</p>

<h5 class="indent5"><a name="contentLayouts"></a>7.2.3 Layouts</h5>

<p class="indent5">A layout is a structure containing references to content
fragments. Selection of fragments based on layouts usually involves two
steps. The first step is to select the appropriate layout, based on context
information. The second step is to populate the layout with fragments of
content. This can be achieved by (indirect) references to fragments in the
layout itself, or by a separate process that maps content fragments to
portions of the layout. The process is similar to the well-established
mail-merge operations of popular office automation solutions.</p>

<h4 class="indent4"><a name="contentIncremental"></a>7.3 Incremental
Refinement</h4>

<p class="indent4">In incremental refinement, the set of possible subsequent
"pages" of content is reduced each time the user follows a step within the
navigation structure. After a number of navigation steps, the user has
focussed on a specific subset of the content and no further refinement of the
selection is necessary or possible. Informally, this may be viewed as a Zoom
in/out feature.</p>

<p></p>

<h2 class="indent2"><a name="varyStructure" class="indent2">8 Techniques to
Vary Structure for Different Delivery Contexts</a></h2>

<h3 class="indent3"><a name="strucureAggregation"></a>8.1 Aggregation</h3>

<p class="indent3">Aggregation is the process of bringing together Authored
Units from one or more sources to form a single fragment. Aggregation may be
executed at the time of authoring, during adaption, or by the client. An
authoring solution that supports aggregation must provide the author with the
means of expressing which content fragments will be aggregated, and/or of
expressing the process by which the content fragments will be selected for
aggregation.</p>

<p class="indent3">Since individual content fragments contain structure of
their own, the aggregation of such fragments will inevitably produce a new
structure. Any factors that influence aggregation may therefore be used to
vary the structure of content, especially if these factors are determined by
the delivery context.</p>

<p class="indent3">Implementations of the aggregation technique include:</p>
<ul>
  <li>Inclusion Mechanisms (XInclude, Server-side Include (SSI), JSP Include,
    etc.)</li>
  <li>Media References (HTML &lt;img&gt; and &lt;object&gt; tags)</li>
</ul>

<h3 class="indent3"><a name="structureDecomposition"></a>8.2
Decomposition</h3>

<p class="indent3">Decomposition is the act of dividing up one or more
authored units to create a set of perceivable units appropriate for a
particular delivery context. An authoring solution that supports
decomposition must provide the author with the means of expressing how the
authored units will be divided, and may necessitate a means of referencing
the individual perceivable units thereby produced.</p>

<p class="indent3">Decomposed content has a significantly different structure
to the original content from which it was derived. This has implications for
the manner in which the content is navigated, and possibly for linking to or
within the content.</p>

<h4 class="indent4"><a name="structurePagination"></a>8.2.1 Pagination and
Page Numbers</h4>

<p class="indent4">One form of decomposition commonly known as "pagination"
occurs when the original content is linear in structure and is divided into
an ordered sequence according to a simple quantitative rule. The ordered
sequence permits the end user to select any page at random, though the
preferred selection is indicated by the order of the sequence. Examples of
pagination include:</p>
<dl class="indent4">
  <dt>Paper pages</dt>
    <dd>Delivery of content to a printer is an instance of pagination where
      the quantitative rule depends on the size of the paper and the amount
      of paper required to render the content.</dd>
  <dt>Tabbed pages</dt>
    <dd>In a tabbed presentation, several pages are available to the user.
      The user determines which one is visible by selecting a (named) tab in
      a menu composed of tabs. This visualisation is popular because of its
      similarity to tabbed pages in physical (paper) filing systems.</dd>
  <dt>"Wizards"</dt>
    <dd>A wizard is typically a form comprising sub-forms whose order of
      completion is determined by dependencies within the form. The size of
      any sub-form depends on the semantic relationships between the elements
      of the form and the available space for presentation. The user is only
      permitted to progress to the next sub-form when the input requirements
      of the current sub-form are satisfied..</dd>
</dl>

<p class="indent4">Each "page" of a pagination could be referred to by its
sequence number (e.g. Page 5 of 12) but the author cannot know these sequence
numbers in advance. Thus it would be inappropriate for the author to say "see
Page 5" because in different pagination contexts the same content may be
rendered on a page other than the 5th.</p>

<p class="indent4">A solution is to permit the author to make references such
as "as mentioned <i>X</i>", (X being a named anchor) which may subsequently
be rendered as "as mentioned <i>in Page 5</i>" in pagination contexts, or
perhaps "as mentioned <i>in Section 4.2</i>" in a section-based decomposition
context or "as mentioned <i>here</i>" where the "<i>here</i>" is rendered as
a hyperlink in non-decomposition contexts. Ensuring the link is compatible
with the surrounding text can be achieved through simple heuristics (e.g.
deciding when to prefix the reference with the word "in"). The use of a
phrase such as "click <i>here</i>" would avoid this issue but would not be in
keeping with accepted Web accessibility guidelines.</p>

<p class="indent4">Several pagination solutions are available to authors,
including the many technologies from the Desktop Publishing and Word
Processing domains, and markup technologies such as XSL Formatting Objects
(XSL-FO) [<a href="#refXSL">XSL</a> chapter 6]. In the case of XSL-FO, a
"page-master" element describes the shape and orientation of the page(s), and
a "page-sequence" element contains the content that flows into the pages
defined by the page-masters. A "page-sequence-master" element determines the
order in which page-masters are chosen. A "simple-page-master" element can be
used on its own to produce a sequence of pages from a flow of content such
that each page has similar dimensions. This is the most simple approach to
pagination, and the discussion below will assume this simple approach of
using equally sized pages.</p>

<h4 class="indent4"><a name="structureADDecomposition"></a>8.2.2 Author
Influenced Decomposition</h4>

<p class="indent4">Decomposition is an unavoidable necessity when the client
is incapable of rendering the entire content. Knowing that decomposition is
likely, authoring techniques exist that give the author the ability to
influence or control the decomposition. Among these techniques are:</p>
<ul>
  <li><b>Page Breaks</b><br>


    <table width="90%" border="0" cellspacing="0" cellpadding="0">
      <tbody>
        <tr valign="top">
          <td><img src="pagebreak.png" width="303" height="114"
            alt="A page on the left with two paragraphs separated by a mark representing a page break. On the right are two pages, each containing one of the original paragraphs."></td>
          <td>This technique is common in word-processing solutions. The
            author inserts a mark, typically after a paragraph of text, to
            indicate that this is an appropriate place to divide the text.
            The insertion of such a mark, and its position, can be made
            conditional on contextual information (e.g. page length). Fixed
            and optional page breaks can be supported by letting an
            adaptation system interpret existing separator elements such as
            &lt;hr&gt;. Alternatively, page breaks (such as the conditional
            "before start of new chapter" break) may be indicated explicitly
            by the author (e.g. XSL-FO).</td>
        </tr>
      </tbody>
    </table>
    <br>
  </li>
  <li><b>Widow/Orphan Control</b><br>


    <table width="90%" border="0" cellspacing="0" cellpadding="0">
      <tbody>
        <tr valign="top">
          <td><img src="widow-orphan.png" width="383" height="196"
            alt="On the left is a page whose second paragraph is large. On the right are two versions of the original split over two pages. The first has divided the second paragraph at the first line. The second version has split before the start of the second paragraph."></td>
          <td>This is another word-processing technique in which a style is
            applied to the text such that paragraphs are divided so as to
            avoid leaving a single line on a page, separate from the rest of
            the paragraph. A "widow" is a division of N lines into 1 line on
            one page, followed by N-1 lines on the next page. An "orphan"
            occurs when the split is N-1 lines on the first page and 1 line
            on the next page. Avoiding these is possible when there are more
            than 3 lines in the paragraph, though it may result in a page not
            being completely filled with text.</td>
        </tr>
      </tbody>
    </table>
    <br>
  </li>
  <li><b>"Keep Together" and "Keep With Next"</b><br>


    <table width="90%" border="0" cellspacing="0" cellpadding="0">
      <tbody>
        <tr>
          <td><p>Another word-processing style that requires that paragraphs
            are not divided, and are not separated from their subsequent
            paragraphs. "Keep Together" is applied to paragraphs. "Keep With
            Next" is typically applied to headings. An adaptation system
            could use custom styles, as per CSS, to support this pagination
            feature. This feature is present in XSL-FO in the form of the
            "keep-with-next" and "keep-with-previous" properties of the break
            element.</p>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
  </li>
  <li><b>Sectioning</b><br>


    <table width="90%" border="0" cellspacing="0" cellpadding="0">
      <tbody>
        <tr valign="top">
          <td><img src="sectioning.png" width="279" height="192"
            alt="To the left is a page of paragraphs, some preceded by H1 headings. To the right are multiple pages, each H1 starting at the top of a new page."></td>
          <td><p>The author uses headings to identify sections within the
            content. Decomposition can then be applied using the headings as
            division points. The &lt;h<i>n&gt;</i> tags in HTML are typical
            candidates for decomposition via sectioning. The (sub)section
            titles also provide useful text for links to each section, for
            example in a Table Of Contents. Unfortunately, this approach does
            not fit with XML or DOM approaches since the identified sections
            do not correspond to any identifiable sub-tree within the
            document markup hierarchy.</p>
            XHTML 2.0 explicitly supports this concept through its
            &lt;section&gt; element, and this will identify document
            sub-trees.</td>
        </tr>
      </tbody>
    </table>
    <br>
  </li>
  <li><b>Regions</b><br>


    <table width="90%" border="0" cellspacing="0" cellpadding="0">
      <tbody>
        <tr valign="top">
          <td><img src="regions.png" width="277" height="196"
            alt="To the left is a page with delimited regions, some nested. To the righ are pages containing complete regions."></td>
          <td><p>A region is a subset of the content identified by a starting
            mark and an ending mark. In XHTML, the &lt;span&gt; and
            &lt;div&gt; tags can be used to identify regions. Decomposition
            involves extracting regions from the content. The "id" attribute
            can uniquely identify fragments within a document. Since regions
            may be nested, this approach permits varying sizes of region to
            be selected, according to the rendering limits of the client.</p>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
  </li>
</ul>

<h3 class="indent3"><a name="structureAssocAdapt"></a>8.3 Associated
Adaptation Techniques</h3>

<p class="indent3">Adaptation techniques associated with the authoring
techniques in this section include the following: (More details may be found
in Appendix B.)</p>
<dl class="indent3">
  <dt>Decomposition</dt>
    <dd>Dividing the original content into smaller parts to accommodate
      limited display capabilities.</dd>
  <dt>Navigation Generation</dt>
    <dd>The automatic creation of navigation aids to support dynamically
      structured content.</dd>
</dl>

<h2 class="indent2"><a name="varyNavigation">9 Techniques to Vary Navigation
for Different Delivery Contexts</a></h2>

<p class="indent2">Navigation is an essential part of any content delivered
to the end user. It enables the user to consume the content in the order
intended by the author, and to locate parts of the content whenever
necessary.</p>

<p class="indent2">Navigation may be created explicitly by the author,
generated under the influence of the author, or generated completely
automatically. Typically, navigation links within raw content (e.g. paragraph
of text) are placed there by the author. Menus and "site-wide" navigation
features can be automated because the links are usually determined by the
structure of the site and not by the content of the individual resources.
Nevertheless, the author may wish to exert some influence over how much
navigation is generated (e.g. nearest-neighbor linking, or site-wide random
navigation) and how it is presented (e.g. static list of hyperlinks, or a
client-side interactive mechanism).</p>

<h3 class="indent3"><a name="structNavLinking"></a>9.1 Linking</h3>

<p class="indent3">Links provide the user with the means of moving from one
presentation unit to another, or to positions within these presentation
units. The hyperlink is the most common form of link, typically rendered as a
highlighted part of the content that responds to an event (such as a mouse
click) by navigating to the target of the link.</p>

<p class="indent3">Adaptation of the original content to suit the delivery
context can have considerable effects on linking. For example, links within
the same (original) page may, through decomposition, become links between
different pages.</p>

<h3 class="indent3"><a name="structNavAuthored"></a>9.2 Authored
Navigation</h3>

<p class="indent3">The easiest, though least flexible, approach to navigation
is to let the author create it. The following navigation features can be
utilized by the author:</p>
<dl class="indent3">
  <dt>Hyperlinks (navigable anchors within content)</dt>
    <dd>A hyperlink is an embedded reference to a resource, or a part
      thereof, that is followed in response to an event (typically
      user-initiated). The problems of link maintenance are well understood
      but device independent authoring of links is less understood. Consider
      the simple choice of authoring a link to a help resource: one may write
      "For assistance please <u>consult</u> our help desk" where the
      <i>consult</i> is the anchor. In contexts where display space is at a
      premium, the link may be better written as the shorter - though less
      informative - "<u>Help</u>". Further complexities are encountered when
      the targets of the links must vary according to context. For example,
      links to subsections of a single document on a large browser may be
      links to separate pages when presented on a small device.</dd>
  <dt>Menus (navigable anchors surrounding content)</dt>
    <dd>Menus are a structured collection of links, commonly presented as a
      hierarchy. The hierarchy relates to the structure of the collection of
      resources being made available to the end user. A menu is placed
      outside of the main content and may be used for random access to
      related resources. It is possible (and likely) that the structure of
      these resources will change in response to different contexts,
      necessitating the creation of different menus. Menus may be presented
      as stylized (e.g. indented) lists of links, or dynamically with the aid
      of client-site processing such as embedded scripting.</dd>
  <dt>Access Keys (shortcuts to navigable anchors)</dt>
    <dd>An access key is an event associated with a link within the current
      presentation. The event is generated by a single action involving a
      keyboard or number pad. This makes the feature very dependent on the
      client hardware and possibly unsuitable for authoring. However, it may
      be generated as part of an adaptation process. It is desirable for
      ease-of-use (e.g. for devices with limited keyboards) and for some user
      accessibility requirements (e.g. users with limited manual
    dexterity).</dd>
</dl>

<h3 class="indent3"><a name="structNavURI"></a>9.3 URI</h3>

<p class="indent3">A URI should be interpreted as a reference to a resource.
It is possible that this single resource will have multiple representations,
according to the presentation capabilities of the access mechanism and other
contextual factors. It is possible that the same URI will produce different
content, though this is not the same as saying that the associated resource
has changed.</p>

<p class="indent3">For example, a web page URL (a specific form of URI)
offering the current weather forecast will obviously offer varying content
according to when you use the URI, but there is no doubt that the URI always
refers to the same resource, as implied by "<i>current</i> weather
forecast".</p>

<p class="indent3">One can extend this example to say that the URI will offer
different representations of resources, according to the device being used to
access it.</p>

<h3 class="indent3"><a name="structNavTools"></a>9.4 Navigation Tools</h3>

<p class="indent3">There are several tools at the disposal of the author,
some of which are described below.</p>

<h4 class="indent4"><a name="toolHTMLLinks"></a>9.4.1 HTML Linking</h4>

<p class="indent4">The standard HTML linking mechanism is the anchor tag,
<b>&lt;a href="url"&gt;...&lt;/a&gt;</b>, which has been a key feature of the
Web since its inception. It identifies a region of the content that, when
selected by the user, will cause the browser to load the content referenced
by the <b>href</b> attribute. The simplicity of this mechanism ensures that
creating webs of content is easy to achieve.</p>

<p class="indent4">The original linking mechanism has its deficiencies. For
example, the original link did not clearly indicate the relationship to the
linked content, despite the availability of a 'rel' attribute. The lack of a
formal definition for link relationship (versus the informal proposals that
were offered) meant that the 'rel' attribute was almost never used. Links can
only be in one direction. Links can reference named anchors in the target,
but cannot reference arbitrary locations or regions within the target. There
is no provision for error handling. The type of the referenced target cannot
be identified. (This feature was subsequently introduced in HTML 4.) The
limitations of HTML linking have led to alternative linking mechanisms, some
of which are described below.</p>

<h4 class="indent4"><a name="toolXLink"></a>9.4.2 XLink</h4>

<p class="indent4">The XML Linking Language [<a href="#refXLink">XLink</a>]
allows elements to be inserted into XML documents in order to create and
describe links between resources. It uses XML syntax to create structures
that can describe links similar to the simple unidirectional hyperlinks of
today's HTML, as well as more sophisticated links. It is a key component of
many XML technologies.</p>

<h4 class="indent4"><a name="toolXPointer"></a>9.4.3 XPointer</h4>

<p class="indent4">The XML Pointer Language [<a
href="#refXPointer">XPointer</a>] is the language to be used as the basis for
a fragment identifier for any URI reference that locates a resource whose
Internet media type is one of text/xml, application/xml,
text/xml-external-parsed-entity, or
application/xml-external-parsed-entity.</p>

<p class="indent4">Note: The design described in previous versions of
XPointer has been factored into a basic framework (<a
href="http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a>)
which defines XPointer schemes and simple "barename" fragment identifiers,
and three additional schemes: <a
href="http://www.w3.org/TR/xptr-element/">http://www.w3.org/TR/xptr-element/</a>,
for addressing elements by their position in the document tree, <a
href="http://www.w3.org/TR/xptr-xmlns/">http://www.w3.org/TR/xptr-xmlns/</a>,
for binding namespace prefixes to namespace name and <a
href="http://www.w3.org/TR/xptr-xpointer/">http://www.w3.org/TR/xptr-xpointer/</a>,
for full XPath-based addressing.</p>

<h4 class="indent4"><a name="toolHLink"></a>9.4.4 HLink</h4>

<p class="indent4">HLink provides XHTML Family Members with the ability to
specify which attributes of elements represent hyperlinks, and how those
hyperlinks should be traversed, and extends XLink use to a wider class of
languages than those restricted to the syntactic style allowed by XLink.</p>

<h3 class="indent3"><a name="interactionSMIL"></a>9.5 SMIL Interaction</h3>

<p class="indent3">SMIL supports interaction concepts that go beyond those
offered by HTML. In particular, hyperlinking has been extended to support
temporal anchors:</p>
<ul>
  <li>Timed navigation links that are only accessible during certain periods
    of the SMIL presentation.</li>
  <li>Ability to navigate to a "point in time" of a presentation. This is
    facilitated via anchors that are placed in a presentation (e.g. a video).
    The SMIL 1.0 anchor tag has been replaced by the SMIL 2.0 area tag. (See
    <i><a
    href="http://www.w3.org/TR/smil20/extended-linking.html#edef-area">http://www.w3.org/TR/smil20/extended-linking.html#edef-area</a></i>
    )</li>
</ul>
<a name="sampleSMILTempAnc"></a>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent5">
  <tbody>
    <tr>
      <td><pre> 
&lt;smil:video
 src="/videos/sample" 
 region="video"
 title="Sample presentation"
 alt="Just another sample video sequence"
 abstract="A 30 second two-part talking head sequence"
&gt;
 &lt;smil:area id="woman" begin="0s" end="15s" title="Woman talking"/&gt;
 &lt;smil:area id="man" begin="15s" end="30s" title="Man talking"/&gt;
&lt;/smil:video&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 6 : SMIL temporal anchors (areas)</p>

<p class="indent3">This feature provides a new dimension for authoring and
adaptation. For example, temporal anchors open up possibilities for
decomposition so that long verbal/visual presentations can be divided into
smaller parts according to author-identified boundaries.</p>

<p class="indent3">Timed links enable the author to present navigation
options that are relevant to the presentation context. Since only a subset of
all of the available links need to be accessible at any given moment, this
feature reduces the need for screen space (or access keys) for links, which
is an important consideration for small devices.</p>

<h2 class="indent2"><a name="varyInteraction">10 Techniques to Vary
Application Interaction for Different Delivery Contexts</a></h2>

<h3 class="indent3"><a name="interactionForms"></a>10.1 Forms</h3>

<p class="indent3">During the design of XForms a great deal of effort was
devoted to making the User Interface part of XForms device independent.
XForms User Interface Form Controls are abstract in nature and defer the
actual appearance to a combination of the XForms Processor (which should
depend on the device) and styling. As an example XForms defines a
&lt;select1&gt; form control. The control is intended to specify that the
user is to choose exactly one item from a set of alternatives. The selection
of which widget (visual representation) to render is determined by the
processor on the target device, possibly influenced by a style associated
with the form control. Adaptation of form controls is illustrated in Appendix
B.2.2.5</p>

<h5 class="indent4"><a name="authoringForm"></a>10.1.1 Authoring a Form</h5>

<p class="indent4">A Web Page may contain more than one form. The presence of
one or more forms in a Web Page will not introduce any additional
difficulties into the adaptation process of pagination unless the need arises
to split a single form.</p>

<p class="indent4">Forms are often complex entities that include
relationships between the various parts of the form. For example, forms that
are used for making travel arrangements often include a <em>departure</em>
field and a <em>return</em> field. A constraint is normally specified that
the <em>departure</em> must be earlier than <em>return</em>. In XForms this
would be accomplished with a model item constraint determined by the author.
With HTML forms this would have been implemented with some form of
<em>script</em>, requiring the author to be a skilled programmer.</p>

<h5 class="indent4"><a name="decompositionForm"></a>10.1.2 Decomposition of a
Form</h5>

<p class="indent4">The two parts of an XForms form need to be considered
whenever decomposing a Web Page that includes XForms. In the simple case
where a form will not be split then both the &lt;model&gt; (which in XHTML is
part of the &lt;head&gt;) and the form controls (which in XHTML is part of
the &lt;body&gt;) need to be copied.</p>

<p class="indent4">If the only consideration for decomposition is the user
experience then there are no particular difficulties in splitting a form such
that it spans multiple Perceivable Units within a <strong>single</strong>
Delivery Unit.</p>

<p class="indent4">The problem gets considerably more difficult if it becomes
necessary to split a form into more than one Delivery Unit. A general
solution does not yet exist but would need to cater for the dependencies that
can exist between the different parts of a form, particularly interfield
constraints and event handling.</p>

<p class="indent4">If a form (either XForms or HTML) cannot be automatically
adapted then changes will need to be made to the specific Web Page. This may
include the author creating alternative versions of the form which are
compatible with the constraints of the devices. Some changes may be cosmetic,
e.g. reduction of white space. Some are more fundamental and involve
redesign, e.g. removal of less important components. However, it is not
possible to "compress" a form <i>ad infinitum</i>, so at some point one must
consider splitting the original form into a collection of smaller forms, such
that the semantics of the collection is equivalent to the original single
form.</p>

<h3 class="indent3"><a name="interactionSession"></a>10.2 Interaction
Session</h3>

<p class="indent3">A session is a sequence of interactive steps that
influence an information state (context) that persists between each step in
the sequence. A session is typically initiated by an initial request from an
end-user, and each subsequent step comes from further requests from the same
end-user. These subsequent requests are a result of the responses sent to
previous requests.</p>

<p class="indent3">Sessions play an important role in web-based applications.
They enable a service to have a dialogue with the end-user while being able
to accumulate information during the dialogue. The accumulated information
may relate to security and authentication, to user preferences and to
requests for specific services (e.g. financial transactions).</p>

<p class="indent3">Many session mechanisms rely on cooperation from the
client application (browser) to maintain sessions. The server will create a
unique key to represent the session and will rely on the client to supply
this key in all subsequent requests. In HTTP, the key is conveyed via
cookies.</p>

<p class="indent3">Alternative client devices must provide similar session
support mechanisms to ensure that services can be offered via these devices.
If HTTP cookies are not available in the client device, an intermediate
(proxy) may supply this functionality, as illustrated in <a
href="#refWAP">WAP</a>. If cookies are not supported in the delivery path,
then alternative means must be used to support the session keys. These
alternatives include URL rewriting, where the session keys are embedded into
the URLs of any links within the page delivered to the client. Selection of
such links ensures that the key is returned to the server in subsequent
requests.</p>

<p class="indent3">Where possible, the session mechanism is hidden from the
author, who only needs to be assured of the existence of a session context in
order to proceed with subsequent stages of the service delivery. The author
can deal with the context as an abstraction. Popular technologies such as JSP
and ASP incorporate the context as a server-accessible object without
exposing the author to the details of the mechanism.</p>

<h2 class="indent2"><a name="authoringTechniquesWorkshop"></a>11 Authoring
Techniques Workshop</h2>

<p class="indent2">The DIWG Charter required that the DI Working Group hold a
public workshop on authoring techniques. This took place in September 2002
and the main points are summarized in this section. A detailed account of the
workshop can be viewed on-line [<a href="#refDIATW">DIATW</a>].</p>

<h3 class="indent3"><a name="workshopResults"></a>11.1 Results of the
Workshop</h3>

<p class="indent3">A number of important results were obtained from the
workshop, including insights into the following:</p>
<ul>
  <li>The roles and importance of sub-document fragments.</li>
  <li>The concept of content layouts, separate from the actual content.</li>
  <li>The independence of URIs.</li>
  <li>The role of CSS in Device Independence.</li>
</ul>

<p class="indent3">These are summarized in the following subsections.</p>

<h4 class="indent4"><a name="workshopFragment"></a>11.1.1 Fragment (Authoring
Unit)</h4>

<p class="indent4">A common theme at the workshop was that of a "fragment of
content", though this concept was expressed via many different names and
definitions. It is generally agreed that there needs to be a definition for
something that is less than a document, and there needs to be a set of
properties, structures and operations surrounding this less-than-document
concept.</p>

<p class="indent4">Among the alternative names for "authoring units" proposed
by the attendees were "Content Block", "Pane" and "Group".</p>

<h5 class="indent5"><a name="workshopURI"></a>11.1.1.1 URIs for Authoring
Units</h5>

<p class="indent5">An authoring unit should be capable of direct addressing
so that it can be referenced by external documents or processes.</p>

<h5 class="indent5"><a name="workshopRecursiveDef"></a>11.1.1.2 Recursive
Definition of Authoring Unit</h5>

<p class="indent5">An authoring unit may comprise other authoring units.
(This raises a potential nomenclature problem: the concept of "unit" does not
permit further division.)</p>

<h4 class="indent4"><a name="workshopLayout"></a>11.1.2 Layout</h4>

<p class="indent4">Generally, a layout is a structure that determines how to
process a collection of content fragments together to present a single
document. The process can be influenced by adaptation.</p>

<h4 class="indent4"><a name="workshopSingleURI"></a>11.1.3 Single URI</h4>

<p class="indent4">A resource, referenced by a single URI, should (where
possible) be independent of the device or the context in which the resource
is made available to the end-user. A resource is not to be confused with the
concept of a document. For example, a resource could be "today's weather
forecast". On some devices this would include a textual description and some
maps, while on other devices only the text might be available. Nevertheless,
the same URI is used in each case. The text fragment may in fact be the same
fragment in all cases, as may the graphic fragment, but not all fragments are
appropriate to the context.</p>

<h4 class="indent4"><a name="workshopRoleOfCSS"></a>11.1.4 Role of CSS</h4>

<p class="indent4">The assumption that CSS is processed on the client was
challenged. While it would appear that CSS was designed to be executed by the
browser, it is clear that practitioners in the mobile Web technologies feel
that server or intermediate processing is as important.</p>

<h3 class="indent3"><a name="workshopTechnology"></a>11.2 Authoring
Technology Identified by the Workshop</h3>

<p class="indent3">The following is a summary derived from position papers
submitted by workshop participants: Covigo, MobileAware, Volantis, NTT
DoCoMo, and HP. It includes conclusions for the DIWG's work on Device
Independent Markup. Presentations by some participants included knowledge
from commercially available implementations.</p>

<p></p>

<h4 class="indent4"><a name="wsCommonalities"></a>11. 2.1 Commonalties of
Approaches</h4>

<p class="indent4">The broad range of solutions presented and discussed at
the workshop revealed a number of common approaches to Device Independence,
some of which are incorporated into commercially available products.</p>

<p></p>

<h5 class="indent5"><a name="wsSeparation"></a>11.2.1.1 Separation of
Content, Layout and Style</h5>

<p class="indent5">All the approaches provide a separation of content,
layout, and style.</p>

<p class="indent5">This is not just a good practice even for conventional
website authoring, but offers additional benefits for DI authoring. The
separation of these three domains allows the adaptation mechanisms to combine
content, layout, and style in a flexible manner. A prerequisite for this is
that the author can express choices, at least for layout and styles. How the
combination of content with sets of layouts and sets of styles is performed,
and how much of that combining process is under the control of the author, is
an extra topic.</p>

<p class="indent5">Two important aspects need to be associated with the units
of content to support the selection and layout of these units:</p>
<dl class="indent5">
  <dt>Scope</dt>
    <dd>The adaptation mechanism needs to know the maximum scope of a content
      unit. Scope in this context means the boundaries within which a content
      unit can be rearranged. Examples for denoting this are &lt;canvas&gt;
      or &lt;head&gt;.</dd>
  <dt>Smallest unit</dt>
    <dd>The adaptation mechanism also needs to know the <i>content unit</i>,
      which must not be split or distributed across different cells of a
      layout. One submitter expressed the concept via an attribute called
      "split-ability".</dd>
</dl>

<p></p>

<h5 class="indent5"><a name="wsAssocOfStyleTL"></a>11.2.1.2 Association of
Style at Top Level</h5>

<p class="indent5">Most submitters associate style (or sets of styles) with
content using a top-level element, such as &lt;head&gt; or &lt;canvas&gt;.
This is straightforward, since the author normally likes to apply a uniform
style to the entire website.</p>

<h5 class="indent5"><a name="wsMediaRefs"></a>11.2.1.3 Media References to be
Replaced by Media Sets</h5>

<p class="indent5">Media are typically resources such as images, audio files,
animations, which are normally inserted in a web page by a reference
mechanism. Since the media needs to be well suited for a particular device or
class of device, most implementors offer a choice of media. The available
selection of media is however not listed directly in the content section of
the DI document, but only referenced in the content section. Regarding the
media selection list itself, implementors invented diverse constructs to
associate the individual media with properties which help the adaptation
process in choosing the most appropriate one.</p>

<p class="indent5">A significant difference in the approaches is the type of
(meta-)data associated with the media. Some describe the media properties
(size, resolution, etc.), some describe the suitability of a particular media
for particular (classes of) devices. The latter alternative is easier to
process for the adaptation engine, but creates dependency on the
classification of devices, which may change over time. In the latter case,
the author also needs to know what media are suitable for what devices.</p>

<h5 class="indent5"><a name="wsLayoutHierarchy"></a>11.2.1.4 Layout
Hierarchy</h5>

<p class="indent5">Separated from content, all submitters provide means to
specify layout in the form of a hierarchy. In conventional HTML authored
documents, layout is most often expressed through (nested) tables. A DI
authoring system needs a similar way to arrange content on a page, but in
more flexible way, so that the adaptation process can rearrange the cells of
a table layout matching the device's display properties. Most authors choose
to invent new markup to express re-arrangeable units of content.</p>

<h5 class="indent5"><a name="wsIncAndExc"></a>11.2.1.5 Inclusion and
Exclusion</h5>

<p class="indent5">All submitters mention the need for a mechanism to
conditionally include or exclude sections of content. However, they are not
very specific about how to express the conditions. Technologies to fill that
gap may be XInclude, XLink, or SMIL (Media feature sets). This can be
considered as a generalization of Media References (mentioned above). Most
implementors use different mechanisms for inclusion of media versus inclusion
of other content. The topic is also related to aggregation in the context of
portals. The adaptation mechanism needs hints when to include or exclude
content. This leads to the question of how to express conditional inclusion /
exclusion and what range of conditions is needed.</p>

<p></p>

<h5 class="indent5"><a name="wsSeqOfAdapt"></a>11.2.1.6 Sequence of
Adaptation Steps</h5>

<p class="indent5">Most submitters agree that adaptation should occur in the
following sequence:</p>
<dl class="indent5">
  <dt>Content Assembly</dt>
    <dd>This means the inclusion or exclusion of content according to hints
      given by the author matched against the actual delivery context,
      followed by a proper arrangement of the content units on a screen
      (voice neglected here). It could involve two separate steps.</dd>
  <dt>Decomposition (Pagination)</dt>
    <dd>If the previous step leads to oversize layout for a target screen,
      splitting up into sequential pages is required. This step needs
      information about the smallest units and automatic insertion of
      additional navigation to allow the user to step through the fragmented
      page.</dd>
  <dt>Optimization</dt>
    <dd>Optimization consists of adapting the layout generated by the two
      preceding steps to the properties of a device by transforming tables
      and lists into the most appropriate representation. It may also be
      necessary to transform controls and links.</dd>
</dl>

<p></p>

<h5 class="indent5"><a name="wsUseOfCSS"></a>11.2.1.7 Use of CSS for
Styling</h5>

<p class="indent5">All submitters assume CSS for styling. This is natural
since it is the technology that is most progressed and can also include
device-dependent hints. One participant mentioned that server-side CSS
processing may be needed to feed devices which don't understand CSS. From a
consistency and technology point of view, it would be preferable to use
XSL:FO instead of CSS, but industry did not follow this route and DI
authoring systems need to be compatible with today's environment.</p>

<p></p>

<h4 class="indent4"><a name="wsImpactOnMarkup"></a>11.2.2 Impact on
Markup</h4>

<p class="indent4">Submitters emphasize that new markup was needed to express
the semantics sketched in the preceding subsection, but they also emphasize
that the amount of additional markup should be minor and compatible with
existing markup.</p>

<p class="indent4">The question is one of deciding which body of markup to
use as a basis for additional markup. Most authors seem to rely on XHTML
Strict.</p>

<p class="indent4">One view expressed at the workshop was for the DIWG to
base its work on the (then current) XHTML 2.0 Working Draft, which has the
disadvantage of being incompatible with previous XHTML versions, but the
advantage is that XHTML 2.0 contains many features which can be extended for
DI authoring.</p>

<p class="indent4">Below is an examination of how markup used by the
submitters in their implementations could be replaced by XHTML 2.0 markup.</p>

<p></p>

<h5 class="indent5"><a name="wsAssocOfStyles"></a>11.2.2.1 Association of
Styles</h5>

<p class="indent5">Since association of styles should happen at top level,
the &lt;head&gt; or &lt;body&gt; element could be extended either by
appropriate attributes or by a sub-element taken from XLink or XInclude.</p>

<p></p>

<h5 class="indent5"><a name="wsUnitsOfContent"></a>11.2.2.2 Units of
Content</h5>

<p class="indent5">Consider the following possible, though not official,
enhancement to XHTML. A nestable element of XHTML 2.0 called &lt;section&gt;
could be the element that denotes a unit of content. Whether this unit is
permitted to be further subdivided might be expressed by a new attribute
"splittable". To assist the adaptation process, such a unit of content needs
many more attributes such as:</p>
<ul>
  <li>Relevance (could be "optional", "mandatory", or a range of numeric
    values)</li>
  <li>Distance (numeric value to identify how far apart the layouting process
    may drag the units</li>
  <li>Splitability (yes or no, to indicate if the content is splittable)</li>
  <li>Suitability (to denote the suitability of this unit for specific
    devices, device classes or modes)</li>
  <li>Navindex (taken from XHTML 2.0, to support navigation).</li>
</ul>

<p class="indent5">Since these enhancements would only be used during
authoring and adaptation, and not delivered directly to the client, they
would not adversely affect any devices that support XHTML 2.0.</p>

<h5 class="indent5"><a name="wsAlternativeIncExc"></a>11.2.2.3 Alternative
Inclusions and Exclusions</h5>

<p class="indent5">Regardless of whether a choice of media is needed to allow
flexible inclusion, or a choice of content units, some markup is required to
express the selection possibilities. The markup should be usable for choice
of media and choice of other content to be included. Most authors invented
their own markup, but XLink, XInclude and SMIL need to be looked at first.
XML Schema also provides elements such as &lt;choice&gt;.</p>

<p class="indent5">Beyond a basic choice statement, the set of expressible
conditions need to be determined. In particular one must be clear whether the
conditions should be based on properties of the content (special case: media)
or on the delivery context or on both.</p>

<p></p>

<h5 class="indent5"><a name="wsApplLayouts"></a>11.2.2.4 Application of
Layouts</h5>

<p class="indent5">Some authors have invented new markup to express the
application of layouts, though conventional table markup may be suitable (at
least as a base) for expressing arrangement of content units on a page. It is
likely that the table cells need additional attributes to provide hints to
the adaptation process. The same may be true for rows and columns. XHTML
offers only one table feature that may be used in adaptation: the
<i>colgroup</i> element, that can group related columns.</p>

<p></p>

<h5 class="indent5"><a name="wsAssocContentLayout"></a>11.2.2.5 Association
of Content and Layout</h5>

<p class="indent5">Authors generally agree that content and layout should be
separately defined and associated in a most dynamic way. In current
implementations, this is done through referencing a separate section of the
DI authored document. The first question to be answered is whether layout
should reference content or whether content should reference layout, or
whether a bidirectional reference is needed. The second question to be
answered is whether XHTML 2.0 reference mechanism (which is actually HLink)
is suitable or whether XLink needs a closer look.</p>

<p></p>

<h5 class="indent5"><a name="wsPassthrough"></a>11.2.2.6 Passthrough of
Arbitrary Markup</h5>

<p class="indent5">One author mentioned the availability of markup that
encloses code to be passed though the adaptation process without any
modification. The primary purpose is to pass scripts to the client device.
Again, it needs to be checked whether this requires new markup or can be done
with constructs such as [CDATA]. In either case, it is a requirement that
adds some additional complexity.</p>

<p></p>

<h5 class="indent5"><a name="wsAttrModify"></a>11.2.2.7 Attribute
Modification</h5>

<p class="indent5">One author suggested a helper element that facilitates the
modification of any attribute of a preceding element. This is an
unconventional approach, but apparently can help avoid the redefinition of
existing markup.</p>

<p></p>

<h5 class="indent5"><a name="wsMarkupOfInput"></a>11.2.2.8 Markup of
Input</h5>

<p class="indent5">One author mentioned new markup to express basic
interaction primitives. It was hoped that XForms would provide the needed
features. The necessary variation in the presentation of form input fields
(depending on delivery context) may be achieved by combining XForms with
conditional inclusion or exclusion as mentioned above. This would be
preferable to extending XForms with new attributes.</p>

<h2 class="indent2"><a name="conclusions"></a>12 Conclusions</h2>

<p class="indent3">This Note has presented several techniques for device
independent authoring, all falling within a spectrum of classification
ranging from Single Authoring to Multiple Authoring, which in turn typically
serve as input to various forms of Adaptation.</p>

<p class="indent3">Single Authoring is preferable because it improves
affordability by avoiding extra work, does not require device/modality
expertise, simplifies authoring tools, reduces maintenance overheads and
reduces storage overheads. There are cases where multiple authoring is
necessary, though the reasons for such necessity can vary and are not always
technical in nature.</p>

<p class="indent3">Multiple Authoring techniques are generally to be avoided
because of the considerable list of disadvantages, including:</p>
<ol>
  <li>It negatively impacts the affordability of device-independent
  authoring.</li>
  <li>The author is required to do additional work in order to support
    additional contexts. With the growing diversity of contexts this has
    already become untenable.</li>
  <li>An author is required to be familiar with the technical requirements
    (e.g. markup) of every context to which the content is offered.</li>
  <li>Authoring tools are required to be capable of supporting every
    technology required of every supported context.</li>
  <li>Maintenance of content must be replicated across every version of the
    content.</li>
</ol>

<p class="indent3">Several W3C Recommendations incorporate aspects of
Multiple or Flexible Authoring, such as selection in Media Queries and SMIL.
None of these features are sufficiently mature to fully support the growing
demands of device diversity, though the trend is towards supporting
independence of the device while adding contextually sensitive features.</p>

<p class="indent3">Adaptation is equally challenging. We can already see some
of the necessary adaptation tools in XSLT (transcoding), XSL-FO (flow and
pagination) and XForms (context-aware presentation). One key to successful
adaptation is awareness of context. To this end, technologies such as CC/PP
will play a vital role.</p>

<p class="indent3">Device Independence can be achieved through a combination
of the following intertwined features, which hopefully will be increasingly
present in future W3C Recommendations:</p>
<ul>
  <li>Context Awareness, described through delivery/document properties.</li>
  <li>Independent Authoring, which is Single or Flexible as appropriate.</li>
  <li>Adaptation, through novel processes.</li>
</ul>

<p class="indent2" align="center"><b>- Appendices -</b></p>

<h2><a name="appReferences">A References</a></h2>
<dl>
  <dt><a name="refAC"></a>Authoring Challenges (AC)</dt>
    <dd><i><a href="http://www.w3.org/TR/2002/WD-acdi-20021018/">Device
      Independence Authoring Challenges</a></i>, Rhys Lewis, Oct 2002. W3C
      Working Draft available at
    http://www.w3.org/TR/2002/WD-acdi-20021018/</dd>
  <dt><a name="ATSub"></a>Authoring Techniques Submissions</dt>
    <dd><i>Submissions to DI Public Mailing List (<a
      href="mailto:www-di@w3.org">www-di@w3.org</a>) relating to Authoring
      Techniques</i>. List of submissions available at<a
      href="http://www.w3.org/2001/di/submission.html">
      http://www.w3.org/2001/di/submission.html</a></dd>
  <dt class="label"><a name="refCCPP"></a>CC/PP</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/">Composite
      Capability/Preference Profiles: Structure and Vocabularies</a>, Graham
      Klyne, Franklin Reynolds, Chris Woodrow, Hidetaka Ohto, Mark H. Butler,
      Nov 2002. W3C Working Draft available at
      http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/</dd>
  <dt><a name="CONSENSUS"></a>CONSENSUS</dt>
    <dd><i><a href="http://www.consensus-online.org/">European Commission
      funded project IST 2001 32407</a></i> to create a single authoring tool
      for mobile browsers. Details at http://www.consensus-online.org/</dd>
  <dt class="label"><a name="refCPC"></a>CPC</dt>
    <dd><i>Core Presentation Characteristics</i>. At the time of publication
      of this document there is no public version of the CPC. Refer to the
      Requirements. [<a href="#refCPCReq">CPCReq</a>]</dd>
  <dt class="label"><a name="refCPCReq"></a>CPCReq</dt>
    <dd><i><a href="http://www.w3.org/TR/cpc-req/">Core Presentation
      Characteristics: Requirements and Use Cases</a></i>, Markus Lauff, Amy
      Yu, May 2003. W3C Working Draft. Latest version available at
      http://www.w3.org/TR/cpc-req/</dd>
  <dt class="label"><a name="refCSS2"></a>CSS2</dt>
    <dd><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/"><i>Cascading
      Style Sheets level 2</i></a>, Bert Bos, Håkon Wium Lie, Chris Lilley,
      Ian Jacobs, May 1998. W3C Recommendation available at
      http://www.w3.org/TR/1998/REC-CSS2-19980512/</dd>
  <dt class="label"><a name="refCssMobile"></a>CSS Mobile Profile 1.0</dt>
    <dd><a href="http://www.w3.org/TR/css-mobile"><cite>CSS Mobile Profile
      1.0</cite></a>, Ted Wugofski, Doug Dominiak, Peter Stark, 2001. W3C
      Recommendation available at http://www.w3.org/TR/css-mobile</dd>
  <dt class="label"><a name="refDCO"></a>DCO</dt>
    <dd><i><a href="http://www.w3.org/TR/2002/WD-di-dco-20021213/">Delivery
      Context Overview for Device Independence</a></i>, Roger Gimson, 2002.
      W3C Working Draft available at http://www.w3.org/TR/DI-DCO/</dd>
  <dt class="label"><a name="refDIP"></a>DIP</dt>
    <dd><a href="http://www.w3.org/TR/di-princ/"><cite>Device Independence
      Principles</cite></a>, Roger Gimson, 2001. W3C Working Draft available
      at http://www.w3.org/TR/di-princ/</dd>
  <dt class="label"><a name="refDIATW"></a>DIATW</dt>
    <dd><i><a href="http://www.w3.org/2002/07/DIAT/">Device Independence
      Authoring Tools Workshop</a></i> organised by W3C Device Independence
      Working Group and held at SAP University, St. Leon-Rot, Germany, 25-25
      September 2002. Details at: http://www.w3.org/2002/07/DIAT/</dd>
  <dt><a name="refGlossary"></a>DIWG Glossary</dt>
    <dd><i>Glossary of Terms for Device Independence</i>, Rhys Lewis, 2003.
      This document uses definitions from the following generic version: <a
      href="http://www.w3.org/TR/di-gloss/">http://www.w3.org/TR/di-gloss/</a>
      <br>
      The Current W3C Working Draft is available at <a
      href="http://www.w3.org/TR/di-gloss/">http://www.w3.org/TR/di-gloss/</a></dd>
  <dt class="label"><a name="refECMAScript"></a>ECMAScript</dt>
    <dd><a
      href="http://www.ecma-international.org/publications/standards/Ecma-262.htm"><i>The
      ECMAScript scripting language</i></a>, (ECMA-262), 3rd Edition, 1999.
      Details at
      http://www.ecma-international.org/publications/standards/Ecma-262.htm</dd>
  <dt class="label"><a name="refXML"></a>Extensible Markup Language (XML)
  1.0</dt>
    <dd><a href="http://www.w3.org/TR/REC-xml"><cite>Extensible Markup
      Language(XML) 1.0 (Second Edition)</cite></a>, Tim Bray, Jean Paoli, C.
      M. Sperberg-McQueen, 2000. W3C Recommendation available at
      http://www.w3.org/TR/REC-xml</dd>
  <dt><a name="refXSL"></a>Extensible Stylesheet Language (XSL) 1.0</dt>
    <dd><a href="http://www.w3.org/TR/2001/REC-xsl-20011015/">Extensible
      Stylesheet Language 1.0</a>, Sharon Adler, Anders Berglund, Jeff
      Caruso, Stephen Deach, Tony Graham, Paul Grosso, Eduardo Gutentag, Alex
      Milowski, Scott Parnel, Jeremy Richman, Steve Zilles, October 2001.
      Recommendation available at
    http://www.w3.org/TR/2001/REC-xsl-20011015/</dd>
  <dt><a name="refHLink"></a>HLink</dt>
    <dd><a href="http://www.w3.org/TR/2002/WD-hlink-20020913/"><i>Link
      recognition for the XHTML Family</i></a>, Steven Pemberton, Masayasu
      Ishikawa, Sept 2002. W3C Working Draft available at
      http://www.w3.org/TR/2002/WD-hlink-20020913/</dd>
  <dt><a name="refMediaQueries"></a>Media Queries</dt>
    <dd><a
      href="http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708/"><i>Media
      Queries</i></a>, Håkon Wium Lie, Tantek Celik, Daniel Glazman, July
      2002. W3C Candidate Recommendation available at
      http://www.w3.org/TR/2002/CR-css3-mediaqueries-20020708/ (Status: CR
      phase ended 31 Jan 2003)</dd>
  <dt><a name="refNewsML"></a>NewsML</dt>
    <dd><i><a href="http://www.newsml.org/">News Markup Language</a></i> of
      the International Press Telecommunications Council, version 1.1, Oct
      2002. Details at http://www.newsml.org/</dd>
  <dt><a name="refSMIL"></a>SMIL 2.0</dt>
    <dd><a href="http://www.w3.org/TR/smil20/"><i>Synchronized Multimedia
      Integration Language</i></a>, J Ayars, D Bulterman, A Cohen, K Day, E
      Hodge, P Hoschka, E Hyche, M Jourdan, M Kim, K Kubota, R Lanphier, N
      Layaïda, T Michel, D Newman, J van Ossenbruggen, L Rutledge, B
      Saccocio, P Schmitz, W ten Kate, August 2001. W3C Recommendation
      available at: http://www.w3.org/TR/smil20/</dd>
  <dt class="label"><a name="refW3CDIA"></a>W3C-DIA</dt>
    <dd><i><a href="http://www.w3.org/2001/di/">W3C Device Independence
      Activity</a></i>. Details available at: http://www.w3.org/2001/DI/</dd>
  <dt class="label"><a name="refW3CDIACh"></a>W3C-DIA-Ch</dt>
    <dd><i><a
      href="http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html">W3C
      Device Independence Activity charter</a></i>. Details available at:
      http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html</dd>
  <dt class="label"><a name="refWAP"></a>WAP 2.0 Specifications</dt>
    <dd><a href="http://www.wapforum.org/what/technical.htm"><cite>WAP 2.0
      Specifications</cite></a>, Open Mobile Association specifications
      available at: http://www.wapforum.org/what/technical.htm</dd>
  <dt class="label"><a name="refXForms"></a>XForms 1.0</dt>
    <dd><a href="http://www.w3.org/TR/xforms/"><cite>XForms 1.0</cite></a>,
      Micah Dubinko, Josef Dietl, Andrew Layman, Leigh L. Klotz, Jr., Roland
      Merrick, T. V. Raman, 2002. W3C Working Draft available at
      http://www.w3.org/TR/xforms/</dd>
  <dt class="label"><a name="refXHTML"></a> XHTML<sup>®</sup> 1.0: The
  Extensible HyperText Markup Language</dt>
    <dd><a
      href="http://www.w3.org/TR/xhtml1/"><cite>XHTML</cite></a><sup>®</sup>
      1.0: The Extensible Hypertext Markup Language, Steven Pemberton, Murray
      Altheim, Daniel Austin, Frank Boumphrey, John Burger, Andrew W. Donoho,
      Sam Dooley, Klaus Hofrichter, Philipp Hoschka, Masayasu Ishikawa,
      Warner ten Kate, Peter King, Paula Klante, Shin'ichi Matsui, Shane
      McCarron, Ann Navarro, Zach Nies, Dave Raggett, Patrick Schmitz,
      Sebastian Schnitzenbaumer, Peter Stark, Chris Wilson, Ted Wugofski, Dan
      Zigmond, 2000 W3C Recommendation available at
      http://www.w3.org/TR/xhtml1</dd>
  <dt class="label"><a name="refXHTMLBasic"></a>XHTML<sup>®</sup> Basic</dt>
    <dd><a
      href="http://www.w3.org/TR/xhtml-basic/"><cite>XHTML</cite></a><sup>®</sup>
      Basic, Mark Baker, Masayasu Ishikawa, Shinichi Matsui, Peter Stark, Ted
      Wugofski,Toshihiko Yamakami, 2000. W3C Recommendation available at
      http://www.w3.org/TR/xhtml-basic/</dd>
  <dt><a name="refXLink"></a>XLink</dt>
    <dd><a href="http://www.w3.org/TR/xlink/">XML Linking Language, Version
      1.0</a>, Steve DeRose, Eve Maler, David Orchard, 2001. W3C
      Recommendation available at http://www.w3.org/TR/xlink/</dd>
  <dt class="label"><a name="refXInclude"></a>XML Inclusions (XInclude)</dt>
    <dd><a href="http://www.w3.org/TR/xinclude/"><cite>XML Inclusions
      (XInclude) Version 1.0</cite></a>, Jonathan Marsh, David Orchard, 2002.
      W3C Candidate Recommendation available at
    http://www.w3.org/TR/xinclude/</dd>
  <dt><a name="refXPATH"></a>XPath</dt>
    <dd><i><a href="http://www.w3.org/TR/xpath">XML Path Language, Version
      1.0</a></i>, James Clark, Steve DeRose, 1999. W3C Recommendation
      available at http://www.w3.org/TR/xpath<br>
      <i><a href="http://www.w3.org/TR/xpath20/">XML Path Language, Version
      2.0</a></i>, Anders Berglund, Scott Boag, Don Chamberlin, Mary F.
      Fernandez, Michael Kay, Jonathan Robie, Jérôme Siméon, 2003. W3C
      Working Draft available at http://www.w3.org/TR/xpath20/</dd>
  <dt><a name="refXPointer"></a>XPointer</dt>
    <dd><a href="http://www.w3.org/TR/xptr/">XML Pointer Language, Version
      1.0</a>, Steven DeRose, Ron Daniel Jr., Paul Grosso, Eve Maler,
      Jonathan Marsh, Norman Walsh, 2002. W3C Working Draft available at
      http://www.w3.org/TR/xptr/</dd>
  <dt><a name="refXQuery"></a>XQuery</dt>
    <dd><a href="http://www.w3.org/XML/Query">XML Query Language, Version
      1.0</a>, Scott Boag, Don Chamberlin, Mary F. Fernandez, Daniela
      Florescu, Jonathan Robie, Jérôme Siméon, 2003. W3C Working Draft
      available at http://www.w3.org/TR/xquery/</dd>
  <dt class="label"><a name="refXSLT"></a>XSL Transformations (XSLT)</dt>
    <dd><a href="http://www.w3.org/TR/xslt"><cite>XSL Transformations
      (XSLT)</cite></a>, James Clark, 1999. W3C Recommendation available at
      http://www.w3.org/TR/xslt</dd>
    <dd><a href="http://www.w3.org/TR/xslt20/"><cite>XSL Transformations
      (XSLT) Version 2.0</cite></a>, Michael Kay, 2002. W3C Working Draft
      available at http://www.w3.org/TR/xslt20/</dd>
  <dt>&nbsp;</dt>
</dl>

<h2 class="indent2"><a name="appAdaptationTechniques"></a>B Adaptation
Techniques</h2>

<p class="indent2">This appendix covers the adaptation techniques upon which
the various authoring techniques rely. An authoring technique may employ one
or more adaptation techniques, and each adaptation technique may be employed
by one or more authoring techniques. The details of adaptation techniques
presented in this appendix are incomplete, yet representative of the current
state of the art.</p>

<h3 class="indent3"><a name="sec1AdaptationProcesses"></a>B.1 Adaptation
Processes</h3>

<p class="indent3">This subsection considers several established processes
that adapt content to its context. Where relevant, other characteristics of
the processes are described, including: efficiency, complexity, security and
position within the delivery path.</p>

<h4 class="indent4"><a name="sec11SelectAndRemove"></a>B.1.1
Select/Remove</h4>

<p class="indent4">A simple adaptation mechanism can be achieved using only
the ability to select (subsets of) available content, or to exclude subsets
of content, on the basis of a decision mechanism. Typically, decisions are
represented within the original content for execution at the time of
delivery. The authoring tools must provide the means for the author to
express such decisions.</p>

<h5 class="indent5"><a name="urlRedirection"></a>B.1.1.1 Selection via URL
Redirection</h5>

<p class="indent5">In URL redirection, the server takes an original URL (a
Web Page Identifier) as requested by the client and supplies an alternative
URL for the client to use. The server may instruct the client to make a new
request with the new URL, or the server may make the request on behalf of the
client. In the latter case, the server is acting as a redirecting proxy. In
all cases, the end-user perceives only the initial URL as a common entry
point, and in this manner the content is adhering to DIP-2. The target of the
redirection is determined by the server through an evaluation of the context
(e.g. the type of device). URL redirection is very easy to implement (and is
the normal behavior of proxy servers) but it is insufficient as a long-term
solution to Device Independence.</p>

<p class="indent5">Typically the advertiser of the page will require a
memorable and/or short URL, so that it is easy for humans to remember and to
enter into their browser. Translation of this "mnemonic" URL can involve
several steps. For example, many sites use "www" as the local name of the
server but do not advertise the "www." part of the FQDN, and thus the first
part of the translation is performed by the DNS server that responds with the
IP number of the machine named "www". As another example, a server may
respond with a "HTTP redirect" that is nothing more than a "Location" header
whose value is determined by the device context. However, redirecting a
client introduces a second request that delays the eventual delivery of the
content and is particularly noticed in mobile environments.</p>

<p class="indent5">URL redirection also causes problems for bookmarking. If
the user can create the bookmark directly, the user would likely use the
mnemonic version. If the browser has a bookmarking feature, it will likely
bookmark the redirection target and not the mnemonic, which means that the
bookmark would not be device independent.</p>

<p class="indent5">The following example shows a meta tag recognized by many
browsers. If received by the browser, it will use the information in the meta
tag to generate another request to the indicated URL after a delay of 10
seconds</p>
<a name="sampleMetaTag"></a>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent5">
  <tbody>
    <tr>
      <td><pre>&lt;meta http-equiv="refresh" content="10;url=http://other.location.xyz"&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 7 : Meta tag redirection</p>

<h5 class="indent5"><a name="inDocDecisions"></a>B.1.1.2 In-document Decision
Tags</h5>

<p class="indent5">An in-document decision tag is one that wraps content to
be included or excluded according to contextual information. The author must
supply expressions that are evaluated to determine if the wrapped content is
selected. There are several variants:</p>
<dl class="indent5">
  <dt><b>Conditional Selection</b></dt>
    <dd><b></b>A single expression is evaluated, and if true then the wrapped
      content is selected.</dd>
  <dt><b>Switch Selection</b></dt>
    <dd>A list of "Conditional Selection" fragments is evaluated in sequence
      until one of them is selected. To provide a default selection, the last
      expression in the list can be fixed at "true".</dd>
  <dt><b>Non-deterministic Switch Selection</b></dt>
    <dd>Like the "Switch Selection" but the order of evaluation is not
      predetermined.</dd>
</dl>

<h5 class="indent5"><a name="layoutConditions"></a>B.1.1.3 Layout-based
Conditions</h5>

<p class="indent5">A layout, selected on the basis of the delivery context
(such as the size of the viewable area), may subsequently determine which
content resources are included in the final presentation.</p>

<h5 class="indent5"><a name="styleDecisions"></a>B.1.1.4 Style-based
Decisions</h5>

<p class="indent5">The decision to present content, and the manner of its
presentation, can be determined on the basis of style. As an example, CSS
Media Queries [<a href="#refMediaQueries">Media Queries</a>] permits the
author to select one or more stylesheets on the basis of device
class/characteristics. The selected styles may in turn determine if and how
the styled content will be displayed. However, this is not always sufficient
because all of the content must be delivered to the device in advance,
despite the possibility of some of the content not being presented to the end
user. A server-side styling adaptation technique may be employed in this
case, where the styles are selected and applied prior to delivery to the
device. This requires that the adaptation processor has at least the same
contextual information as would be available to the client-side styling
process.</p>

<h5 class="indent5"><a name="relevanceOfContent"></a>B.1.1.5 Relevance of
Content</h5>

<p class="indent5"><a
href="http://www.w3.org/TR/xforms/slice6.html#model-prop-relevant">Relevance</a>
is an XForms concept that describes the suitability of content on the basis
of contextual information. It incorporates an expression language so that
relevance can be expressed as a Boolean. The concept of relevance may be
incorporated into content markup, as the following sample suggests:</p>
<a name="sampleRelevance"></a>

<table width="95%" border="1" cellspacing="0" cellpadding="0" class="indent5">
  <tbody>
    <tr>
      <td><pre class="indent5"> 
&lt;xhtml&gt;
  &lt;img src="aaa" alt="bbb" DI:relevant="Context('colorDepth') &amp;lt; 257" /&gt;
  &lt;div DI:relevant="Context('display') = 'none'"&gt;...&lt;/div&gt;
&lt;/xhtml&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p class="samplefooter">Sample 8 : A method of incorporating "relevance" into
content markup</p>

<p class="indent5">If DI:relevant evaluates to true, content is included; if
it evaluates to false, content is not included. A number of presenters at the
Device Independent Authoring Techniques workshop [<a
href="#refDIATW">DIATW</a>] demonstrated similar approaches, where a decision
expression can be embedded into the source content. On the client-side, one
can use CSS Media Queries to achieve similar results, and it is technically
possible to execute Media Queries at any point in the delivery path.</p>

<h4 class="indent4"><a name="sec12NavigationGeneration"></a>B.1.2 Navigation
Generation</h4>

<p class="indent4">Navigation generation is the process of creating a
navigation structure from the available content and/or information provided
by the author. It is particularly useful where the content is complex or
dynamic. The main influence on navigation generation is the target content,
since the purpose of the generated navigation structure is to assist the
end-user in getting to (parts of) the content. Other influences include the
intentions of the author, the relative priorities of parts of the content,
the ability of the browsing device to render navigation features, and many
other contextual influences.</p>

<p class="indent4">It is possible, in some cases, to generate the navigation
features automatically, such as creating a table of contents from the
headings in a document, or a sitemap generated from the links between
documents. In other cases the navigation features must be created directly by
the author due to the absence of information in the content that would
determine the appropriate navigation paths. An authoring solution must
provide the author with the means to influence any automated navigation, and
the means to provide specific navigation information. It is expected that
this author-provided or derived information will be used by adaptation
processes to provide a variety of navigation features that, to the best of
the device's ability (and suitability to other contextual constraints) will
best represent the navigation paths intended by the author.</p>

<p class="indent4">The dominant navigation structures are tables (lists) and
menus (hierarchies), which are explored in more depth below.</p>

<h5 class="indent5"><a name="navGenTOC"></a>B.1.2.1 Table of Contents</h5>

<p class="indent5">A "table of contents" is an ordered list of headings,
possibly structured according to relative importance. The table includes the
headings and a means of navigating to the referenced portions of the content.
The order of the headings corresponds to the order of occurrence within the
content, assuming the content has an inherent order. In the absence of an
inherent order, an alternative order may be imposed (e.g. alphabetic). Where
an alternative ordering has been imposed, the table would be called an
"index".</p>

<h5 class="indent5"><a name="navGenMenus"></a>B.1.2.2 Navigation Menus</h5>

<p class="indent5">A navigation menu is a list of links to other content. The
links may be within the current content, the current site or external. The
presentation of the menu may be fixed or dynamic (e.g. drop-down form
elements). The size and complexity of a menu is normally adapted to the
characteristics of the device. Small devices will require smaller menus.
Static menus impose less processing overheads, and are suitable for certain
mobile devices. The order of items within a menu may also be tailored to the
device, to the user preferences or even the past behavior of the user.</p>

<p class="indent5">An author may construct one or more menus to suit the
categories of device, or may leave the construction of menus to an adaptation
process. Where adaptation is used, the author may need to indicate the
suitability of candidate links to different categories of device.</p>

<h6 class="indent6"><a name="navGenNearest"></a>B.1.2.2.1 Nearest Neighbor
and Home</h6>

<p class="indent6">A navigation menu that indicates contextually relevant
documents in the current site, and a suitable "home page" for the site. This
form of navigation is suitable for users who will normally navigate through a
site (i.e. will probably have a long path). This form of navigation is also
suitable when the size of the navigation aid must be kept small.</p>

<p class="indent6">Determination of the nearest neighbor can be done by the
author, or may be derived from a hierarchy representing the entire site. If a
hierarchy is used, the nearest neighbors would be the parent node and all of
the children nodes (and possibly the root node).</p>

<h6 class="indent6"><a name="navGenFullSite"></a>B.1.2.2.2 Full Site
Representation</h6>

<p class="indent6">A full site representation is a navigation aid that is not
contextually sensitive. Instead it represents the entire site regardless of
the current page that the user is viewing. This is OK for small sites or for
devices that can display large complex representations, possibly dynamically
such as collapsible navigation trees.</p>

<h5 class="indent5"><a name="navGenNextPrevious"></a>B.1.2.3 Next and
Previous links</h5>

<table width="95%" border="0" class="indent5">
  <tbody>
    <tr valign="top">
      <td height="164"><img src="next.png" width="188" height="161"
        alt="A hierarchy of pages with one node indicating that next could mean the root, a parent or another node at the same level"></td>
      <td height="164"><p>The purpose of Next and Previous links it to
        facilitate linear navigation to adjacent content. Subtle differences
        in navigation can be introduced by different definitions of
        <i>adjacent</i>.</p>

        <p>The concept of "next" is usually determined by the author, while
        the concept of "previous" has various interpretations.</p>
      </td>
    </tr>
  </tbody>
</table>

<h6 class="indent6"><a name="relToCurrent"></a>B.1.2.3.1 Relative to Current
Path</h6>

<p class="indent6">As an end-user navigates through a site, a path is
created. The concepts of Next and Previous can be relative to this path.
'Previous' always refers to the page (possibly a URL) that the user was
viewing prior to the current page. 'Next' applies when the user has used
'Previous' to return to a page, so that 'Next' will advance the user along
the established path.</p>

<h6 class="indent6"><a name="relToSite"></a>B.1.2.3.2 Relative to Site
Structure</h6>

<p class="indent6">The concepts of Next and Previous can be defined by the
author, or derived from suitably structured documents (e.g. slide
presentations). For example, the author may structure the site according to
chapters, such that if the user is viewing Chapter N then 'Next' refers to
Chapter N+1 and 'Previous' refers to Chapter N-1. This is regardless of the
path that the user has used to reach Chapter N. For example, if a user
navigates from Chapter 6 to Chapter 3, then 'Previous' means Chapter 4 and
not Chapter 6.</p>

<h5 class="indent5"><a name="navGenNextBack"></a>B.1.2.4 Next and Back
Links</h5>

<p class="indent5">In a Next and Back system, the 'Next' page is determined
by the author while the 'Back' page is determined by the path the end user
has used to reach the current page, and refers to the page that the end user
was viewing prior to the current page.</p>

<h4 class="indent4"><a name="sec13AdaptationViaSubstitution"></a>B.1.3
Adaptation via Substitution</h4>

<p class="indent4">To avoid unnecessary repetition or to reduce text, some
content could be substituted by a reference to the full content (either at
the end or on a separate page). For example, instead of a complete copyright
notice appearing on each page, this can be substituted for a link to a
separate page containing the notice.</p>

<p class="indent4">Note: automation of such a process can produce unwanted
results. Consider the headline: "President eats astronaut food during visit
to launch site." used as a link to the complete news item. A substitution
process may use ellipsis to shorten the link, which becomes "President eats
astronaut ...". This highlights the need to control substitutions to avoid
semantic changes.</p>

<p class="indent4">Some devices do not support a full range of character
entities, such as currency symbols. Although the markup may support such
entities, in order to render them on the device they must be substituted. For
example, if the pound symbol is unsupported, a graphic could be substituted,
or the text "GBP".</p>

<h4 class="indent4"><a name="sec14AdaptationViaTransformation"></a>B.1.4
Adaptation via Transformation</h4>

<p class="indent4">Adaptation that involves conversion from one format or
markup into another by web intermediaries is known as "transformation".
Technologies include XSLT and DOM manipulators (for markup transcoding) and
image filters.</p>

<h3 class="indent3"><a name="sec2AdaptationProcessors"></a>B.2 Adaptation
Processors</h3>

<p class="indent3">An adaptation processor is a mechanism that takes one form
of content as input and produces an alternative form as output. Adaptation
processors would normally be expressed in software, although hardware-based
processors are also possible.</p>

<p class="indent3">Adaptation may be as simple as minor alterations to markup
to work around minor browser differences, or they may be as complex as moving
from one modality (e.g. text with markup for visual presentation) to another
(e.g. voice synthesis and recognition). The complexity of the adaptation
depends on the difference between the authored/available content formats and
the supported/preferred content formats.</p>

<p class="indent3">This subsection considers different levels where the
process of content adaptation could take place. Three locations are
identified on the end-to-end path from the server to the target device: the
server side, the client side and the intermediate systems. Adaptation
processors could cooperate and thus the final adapted content could be the
result of more than one adaptation task applied at different levels. The
author of the content can exploit these possible adaptations and apply
necessary techniques that make the content more adaptable and negotiable.</p>

<h4 class="indent4"><a name="sec21ServerSideAdaptation"></a>B.2.1 Server-side
Adaptation</h4>

<p class="indent4">Content adaptation can be performed at the server side if
the target client presents some limitations (processing power, access method,
screen size, storage capabilities, etc.) and it is not capable of receiving
or adapting the original content itself. Server-side adaptation can also be
applied to respect the delivery context of the content, for instance to
optimize the use of the network resources (e.g. if the bandwidth is limited)
or in order to reduce the delivery latency and to avoid unnecessary download
delays. The adaptation scenario can depend on the communication protocol used
in the content delivery. In some situations, especially in stateful
protocols, the server requires client feedback in order to perform the
adaptation efficiently (such as in RTP and RTCP protocols). This happens less
in stateless protocols such as HTTP where the server adaptation depends on
one client/server interaction.</p>

<h5 class="indent5"><a name="ssaVariantSelection"></a>B.2.1.1 Variant
Selection</h5>

<p class="indent5">This adaptation mechanism consists of choosing the best
version that exists on the server on behalf the user agent. The selection is
applied on the available set of variants. It should be based on the variants
characteristics that can be extracted directly from the alternative resource
or provided by the author who can specify some attributes concerning the
delivery context of that resource. SMIL represents an example where the
author can associate a variant with a particular context inside the Switch
element or anywhere in the document using the in-line test attributes.
Selection parameters are based on the delivery context and could concern the
language, the media type, the char-set, and other constraints. Different ways
of variant selection can be followed. A variant can be selected if it
satisfies all the specified assertions regarding the delivery context (as it
is applied in the evaluation algorithm of SMIL Switch) or if it has an
acceptable presentation value calculated using some algorithms based on the
quality values that are associated with the negotiation dimensions (as it is
applied in some implementations of HTTP/1.1 content negotiation) Instead of
storing and providing multiple variants, each matching the characteristics of
a target device (or a class of devices), the author can provide only one
variant and rely on the adaptation mechanisms to deliver the content in the
appropriate form at the destination. As we can see in the following, the
server adaptation can be applied at the structure or the media level of the
content.</p>

<h5 class="indent5"><a name="ssaTransformation"></a>B.2.1.2
Transformation</h5>

<p class="indent5">This process concerns adaptations applied on the global
document structure. An example of such applications: transforming HTML to
WML, filtering HTML documents, transforming XML to SVG, etc. XSLT is one of
the efficient technologies that can be used to reach this objective. A
structural transformation can either keep media resources used inside the
original document (images, videos, etc.), filter them or use an external
transcoding method in order to adapt the media for the target context.
Structural transformations are widely related to the characteristics of the
authored markup. In order to enable advanced transformation, such as semantic
one (content summarization, etc.), the authored markup should be enriched by
some elements and information related to the semantic of the content and not
to its presentation.</p>

<h5 class="indent5"><a name="ssaMediaAdatation"></a>B.2.1.3 Media
Adaptation</h5>

<p class="indent5">This kind of adaptation covers all the transformation
applied on media resources like image and video adaptation (color reduction,
resizing, etc.), media transcoding, and other methods that operate directly
at the media encoding level. The application of this process at the server
side helps to avoid sending media formats that are not accepted by the target
user agent (using format conversions, e.g. JPEG to WBMP) and also to apply
further adaptations that consider the client limitations: media resizing for
small screen devices, media compression to speed up the download time, etc.
The real-time media adaptation process should be avoided if the author
provides an alternative that satisfies the delivery context.</p>

<h5 class="indent5"><a name="ssaMediaInfo"></a>B.2.1.4 Using
Meta-information</h5>

<p class="indent5">The server can tailor some meta-information related to the
expiration of requested resources in order to avoid frequent document
prefetching or prevalidating by clients in a poor network connection. The
server can provide some added information (for example via headers) so that
intermediaries used in poor connection networks can increase the freshness
interval for resources and apply efficient caching policies.</p>

<h5 class="indent5"><a name="adaptViaDecomposition"></a>B.2.1.5
Decomposition</h5>

<p class="indent5">Device Independence Principles [<a href="#refDIP">DIP</a>]
defines the terms Delivery Unit (DU) and Presentation Unit (PU) that are of
particular relevance to the subject of <i>Decomposition</i>.</p>

<p class="indent5">There are two primary reasons that some form of
decomposition takes place:</p>
<ul>
  <li>To overcome physical limitations of the device, for example the WML
    deck size constraint associated with WAP devices.</li>
  <li>To give the user a more pleasing experience on a particular class of
    device.</li>
</ul>

<p class="indent5">An adaptation system can make use of either or both of the
following two decomposition techniques:</p>
<dl class="indent5">
  <dt>Decomposition into DUs</dt>
    <dd>Using WML 1.x as an example, it is possible to overcome the
      limitation on deck size by splitting a WML resource into a number of
      <i>Delivery Units</i> (DU) such that each DU is less than the device
      limit and by inserting navigation between the DUs.</dd>
  <dt>Decomposition into PUs</dt>
    <dd>On some classes of device scrolling through content that is too large
      to fit on the display is cumbersome, and in some cases unacceptable. In
      these cases it is necessary to split the resource into a number of
      smaller <i>Presentation Units</i> (PU), which are presented to the user
      in a manner that is appropriate to the device. It will also be
      necessary to facilitate navigation between the PUs</dd>
</dl>

<p class="indent5">Continuing with WML as an example, it is possible to use a
deck of &lt;card&gt;s to implement a collection of Pus A similar approach
could be adopted with HTML where the adaptation process uses regions
identified by &lt;div&gt; to define each PU and then manipulates the set of
PUs such that only one is visible at a time.</p>

<p class="indent5">Decomposition processors may use information provided by
the author (such as the &lt;div&gt; delineated regions) and/or contextual
information (e.g. available memory in the client) to determine the boundaries
of the generated DU/PUs</p>

<h4 class="indent4"><a name="sec22ClientSideAdaptation"></a>B.2.2 Client-side
Adaptation</h4>

<p class="indent4">To avoid sending large amount of device and user profiles
information to a proxy or a server for content adaptation, the author can
exploit client-side adaptation. The author can apply all or partial
adaptation techniques on the client-side depending on properties of the
client, such as memory size and processing speed.</p>

<h5 class="indent5"><a name="csaImage"></a>B.2.2.1 Image Resizing</h5>

<table width="95%" border="0" class="indent5">
  <tbody>
    <tr>
      <td valign="top"><img src="shrinkmap.png"
        alt="To the left is a large geographical map with a city, a river and a bridge with a name. To the right a smaller version of the map but without the bridge name because there is no space for it."></td>
      <td valign="top">Image resizing is useful when the author needs to fit
        an image into a limited space. The author can scale down/up the image
        using existing technologies such as SVG, or employ image versioning.
        Scaling of image components need not be applied uniformly. For
        example, when shrinking a map it may be necessary to scale the text
        within the image at a different rate, or possibly remove some of it.
        With image versioning, the author may create or generate a discrete
        set of alternative images with various sizes and formats. At content
        request time, the appropriate image would be selected based on the
        client's capabilities.</td>
    </tr>
  </tbody>
</table>

<h5 class="indent5"><a name="csaFont"></a>B.2.2.2 Font Substitution</h5>

<table width="95%" border="0" class="indent5">
  <tbody>
    <tr valign="top">
      <td><img src="fontsubs.png"
        alt="Two pages on the left showing many different fonts. They are mapped to a sans-serif font and a Times font, illustrating a reducting in the number of fonts based on this categorisation."></td>
      <td><p>Not all fonts will be supported by all devices; so many devices
        will substitute a similar font. This assumes that font categorization
        is being used. The author should be able to influence the
        substitution mechanism by offering a prioritized set of options.</p>

        <p>Presenting information to the user that relies on being able to
        distinguish between fonts is not advisable because the actual fonts
        used may not be distinguishable.</p>
      </td>
    </tr>
  </tbody>
</table>

<h5 class="indent5"><a name="csaTranscode"></a>B.2.2.3 Transcoding</h5>

<p class="indent5">Some clients are capable of content transcoding, for
example by processing XSLT client-side. This process tailors text, images,
audio, and videos based on the clients' capabilities. The transcoding process
may include content translation/conversion, content filtering, content
summarization, and content selection. To exploit transcoding, the author may
provide a set of transcoding policies such as the rules in XSLT and JSP, and
sufficient content semantics to describe the pre-transcoded content.</p>

<h5 class="indent5"><a name="csaRenderer"></a>B.2.2.4 Dedicated Rendering</h5>

<p class="indent5">Dedicated rendering is the process of displaying
additional content types, typically those that are not normally native to the
browser. A client-side process would receive the specialized content and map
it to a suitable presentation. Browser plug-ins are a common mechanism for
providing dedicated renderers for specialized content such as Portable
Document Format (PDF), Virtual Reality Markup Language (VRML) and Flash. Even
XHTML modules (e.g. SVG) can be supported via dedicated client-side rendering
plug-ins. These client-side renderers are dedicated to a specific content
type and therefore do not need to be as powerful as generic browsers.
However, the author must consider the possibility of the absence of such
renderers when creating content. Alternatively, a server-side adaptation
system could select/create an alternative to the specialized content.</p>

<h5 class="indent5"><a name="csaFormResize"></a>B.2.2.5 Form Resizing</h5>

<p class="indent5">A form needs to be resized when it cannot fit into a
limited space. The adaptation process can resize the form by reducing the
visualization of form controls (widgets), repositioning form controls,
transforming form controls, and/or splitting (decomposing) the form.</p>

<p class="indent5">The adaptation process can reduce a form control's size by
reducing the font size and/or by clipping extra whitespace from text-related
form controls. When reducing the font size, the adaptation process should
choose a size that is human-readable on the client device. When clipping
extra whitespace from form controls such as &lt;TEXTAREA&gt; and
&lt;TEXTFIELD&gt;, one should ensure that the controls are long enough for
the user to view and input text.</p>

<p class="indent5">When repositioning form controls, the adaptation process
should provide enough semantics such as relationships and proximities between
controls, so that controls can be repositioned sensibly and functionally. The
repositioned form controls should not confuse the users.</p>

<p class="indent5">The adaptation process can also apply form control
transformation. Figure 1 shows a form control transformation from a set of
radio buttons to a drop-down box, and Figure 2) shows a form control
transformation from a set of label-textfield pairs to a list-textfield pair.
Not all form controls can be applied transformation (e.g., a label) and not
all form controls can reduce its size by a transformation rule (e.g., the
"list to drop-down box" rule can reduce the list's size, but the "list to
radio buttons" rule may not reduce the size). The adaptation process should
prioritize and select form controls and transformation rules that give the
best size reduction. After form control transformation, one should ensure
that the transformed form controls are fully functional and are recognizable
by users.</p>

<p class="indent5">In general, form splitting is used when no other form
resizing techniques are applicable. Before splitting a form, the adaptation
process should group related controls and provide enough semantics about each
(group of) control including relationships, proximities, relative size,
priorities, etc. The form can be split based on the semantics of each control
group. After splitting a form, the adaptation process should provide
navigation among the split forms. The adaptation process should also ensure
that the split forms are fully functional.</p>

<p align="center"><a name="figureRadioToDrop"></a><img src="radio-shrink.png"
alt="Left, a box with three radio buttons, one selected. Right, a smaller box with a dropdown indicating the current selection."></p>

<p class="figurefooter">Figure 1 : Control transformation from radio buttons
to a drop-down box</p>

<p align="center"><a name="figureLableToList"></a><img
src="textbox-shrink.png"
alt="Left, a large box with several titled textboxes. Right, a small box with one textbox whose title is selected by a scrollable list."
width="60%"></p>

<p class="figurefooter">Figure 2 : Control transformation from
label-textfield pairs to a list-textfield pair</p>

<h5 class="indent5"><a name="contextualSelection"></a>B.2.2.6 Contextual
Selection</h5>

<p class="indent5">Several client-side markup solutions provide selection
mechanisms that support complex expressions involving contextual data. The
client must retrieve the entire markup before evaluating the expressions to
determine which (if any) of the enclosed markup will be selected. The
enclosed markup may in turn refer to external resources, which are then
retrieved. SMIL provides such a feature for selecting markup subsets, and CSS
Media Queries provides a similar feature for selecting appropriate styles.</p>

<h4 class="indent4"><a name="sec23IntermediateAdaptation"></a>B.2.3
Intermediate Adaptation</h4>

<p class="indent4">Intermediate adaptations are generally applied in a
proxy-based architecture. Such architecture (Figure 3) consists of adding a
third entity between the server(s) and the client(s). The proxy can be seen
as an intermediate processor that acts on behalf of a client by receiving
content from a content source, processing the content and then relaying it to
the client. This kind of architecture represents a good approach to address
the heterogeneity problem of clients and servers. Indeed, in a proxy-based
architecture the network platform is not modified and the environment
characteristics that already exist are preserved. Proxy-based architectures
can be very complex by including several intermediaries dedicated to specific
tasks such as image and video transcoding, video broadcasts, firewalls
security, etc.</p>

<p align="center"><a name="figureIntermediateAdaptArch"></a><img
src="intermediate-adapt.png" width="604" height="161"
alt="A content server on the left, interacting with an adapting proxy in the center, which interacts with a client on the right."></p>

<p class="figurefooter">Figure 3 : Intermediate Adaptation Architecture</p>

<h5 class="indent5"><a name="iaContentAdaptation"></a>B.2.3.1 Content
Adaptation</h5>

<p class="indent5">In the context of content adaptation, the proxy is the
entity responsible for retrieving client requests and contexts and performing
possible adaptation on the content received from the server. The adapted
content is then sent to the client with respect to its characteristics. The
proxy can transform the content if no alternatives are available. All the
proxy processes are designed to behave transparently to clients and content
servers. Adaptation techniques discussed in Appendix B<span
class="hilite"></span> can be applied within the proxy. Note that the
"alternatives" selection technique is more complex in the proxy case. Indeed,
variants are not stored in the proxy side so the proxy has limited control
regarding the knowledge of existing alternatives and the extraction of
variant characteristics. This can be achieved using further message exchange
between the proxy and the origin server, which can increase the content
delivery time.</p>

<h5 class="indent5"><a name="iaSelectingServer"></a>B.2.3.2 Selecting a
Server</h5>

<table width="95%" border="0" class="indent5">
  <tbody>
    <tr valign="top">
      <td><img src="redir-mirror.png" width="235" height="164"
        alt="A picture of the world. A client in one continent interacts with a local mirror. A client in another continent contacts the same server but is redirected to a separate local mirror, which is closer to the second client."></td>
      <td>One kind of adaptation that can be performed at the proxy level is
        the selection and the redirection to the best server mirror (cache)
        that can reply to the client request. Some content servers have a
        large collection of mirrors where the content may be stored and
        delivered in different ways. The proxy selection could be based on
        the client connectivity, the client capabilities and preferences, the
        mirror location, etc. Once the selection is done, the proxy should
        apply a mapping between request URI and specific resources.</td>
    </tr>
  </tbody>
</table>

<h5 class="indent5"><a name="iaDeliveryAndProtocol"></a>B.2.3.3 Delivery and
Protocol Adaptation</h5>

<table width="95%" border="0" class="indent5">
  <tbody>
    <tr valign="top">
      <td><img src="protocol-adapt.png" width="248" height="149"
        alt="An illustration showing a network protocol to the left being communicated by a physical system (in this case a wireless link) and being translated to a different protocol by the receiver."></td>
      <td>Proxy adaptation can also concern the protocol used in delivering
        the adapted content. After a particular adaptation, e.g. transforming
        HTML to WML, the proxy can still control the content delivery using
        another protocol different than the original proxy/server exchange
        protocol. This kind of proxies is called 'protocol proxies' and can
        work at the network, the transport or the middleware layer. The proxy
        can also control the delivery by applying compression algorithms to
        reduce the size of the delivered content or by bundling embedded
        objects into a single resource to avoid multiple rounds of
      requests.</td>
    </tr>
  </tbody>
</table>

<h2><a name="appToS"></a>C Types of Structure</h2>

<p class="indent2">A document may be stored, constructed, presented or
dissected, according to a predefined structure. This section considers the
form and application of structures comprised of pages of content and the
relationships between these pages. For the purpose of this task, pages will
be those content objects that are accessible to the end-user via URIs, and
relationships shall include hyperlinks (e.g. href attributes in HTML
anchors), frame-based adjacency (i.e. mentioned in the same frameset) and
pages reachable via an input from the end-user (e.g. via a form).</p>

<p class="indent2">Several well-known structures are frequently found in
authored content. These are explained below, with special emphasis on how
these structures influence content navigation.</p>

<h3 class="indent3"><a name="tosLinear"></a>C.1 Linear</h3>

<p align="center"><a name="figureLinearStructure"></a><img src="linear-2.png"
alt="A sequence of boxes with arrows joining them to show a natural order to the structure"
width="60%"></p>

<p class="figurefooter">Figure 4 : Linear structure based on navigation from
page to page</p>

<p class="indent3">A linear structure has one start point and one end point,
and a single path from one to the other. The delivery closely matches oral
(verbal) communication where the content represents a narrative. Significant
parts of the content may be highlighted, and parts of the content may be
repeated (to avoid having to review previous parts).</p>

<p class="indent3">The author of a linear structure must take into account
the fact that the reader may not have access to the whole document at any
point in time. For example, if the document is being delivered via voice
synthesis, the listener will only have knowledge of the document up to the
current point in the reading, Thus forward references may present problems.
Furthermore, backward references will rely on the reader's memory, which (in
the case of most humans) is unreliable, especially with large documents.
Repetition instead of references will alleviate this problem, at the expense
of increased document size and longer delivery times.</p>

<h3 class="indent3"><a name="tosHierarchy"></a>C.2 Hierarchy</h3>

<p align="center"><a name="figureHierarchy"></a><img src="hierarchy-3.png"
alt="A tree-like collection of boxes connected by lines and an entry point at the root"
width="60%"></p>

<p class="figurefooter">Figure 5 : A hierarchy of pages</p>

<p class="indent3">A content hierarchy is a recursive/nested structure
represented by a node, where a node comprises an ordered collection of one or
more items. An item may be a piece of content or a node.</p>

<p class="indent3">There are many variations on this definition. In some, the
node has a title and this title may be considered as a piece of content. In
others, the node is purely abstract and has no content other than that
contained in its collection of items. Writing conventions suggest that the
former definition is more useful, since it agrees with the concept of
"heading".</p>

<p class="indent3">It is also a convention that the development of the
concept/information represented by the document (the root node) follows the
order of the collection of nodes, and that the deeper nested nodes represent
greater levels of detail.</p>

<p class="indent3">HTML incorporates the concept of the hierarchy in its six
heading tags, &lt;h1&gt; to &lt;h6&gt;. One expects that any rendering of the
markup will reflect the importance of the headings through suitable
formatting, highlighting or similar styles.</p>

<p class="indent3">A reader may choose to read the document in a linear
fashion. This may mean selecting a particular level of the hierarchy and
reading only the pages at that level (ignoring nested pages). A reading of
the entire document might involve a traversal of the hierarchy, typically
depth first (strictly: following links as they occur in the pages, and
returning to the parent at the end of each page).</p>

<p class="indent3">Alternatively, the reader may navigate (quickly) to a
specific level of detail via repeated selection of sub-nodes. A "table of
contents" derived from the node titles is often used to assist such
navigation. This kind of navigation is typical when the reader explores or
has foreknowledge of the document (from a previous reading, or from
experience of a similar version) and already has some idea of which item must
be locat<span class="indent4"><span class="indent3">ed.</span></span></p>

<h3 class="indent3"><a name="tosMesh"></a>C.3 Mesh</h3>

<p align="center"><a name="figureMesh"></a><img src="mesh-3.png"
alt="A random collection of boxes with arrows connecting them at random, with several entry/exit points"
width="492" height="340"></p>

<p class="figurefooter">Figure 6 : A mesh of pages</p>

<p class="indent3">A mesh is a (potentially unordered) collection of content
containing links between the items of content in the collection. It does not
require a specific entry point. It does not require any specific reading
order (traversal). It is necessary that for each piece of content within the
collection there is at least one path from a potential entry point to the
piece of content. This ensures that all of the content is accessible.</p>

<p class="indent3">A mesh may be random, where no traversal has preference. A
mesh may have order, such as a collection of content that can be traversed in
more than one dimension. As an example, consider a collection of poetry that
may be navigated in chronological order, in alphabetical order (according to
author's name, or title) or in any of a number of other possible orderings.
Such collections could be represented as pieces of content where each piece
can be retrieved via some unique key. In effect, the mesh is a database of
content items, and the keys represent the access and/or links to these
items.</p>

<p class="indent3">An author of a mesh must have a means of creating the
content item and identifying the key(s) to associate with it.</p>

<h3 class="indent3"><a name="tosGeospatial"></a>C.4 Other Geospatial
Structures</h3>

<p class="indent3">There are other structures that may be used to represent
content and its interrelationships. These have limited or narrow application,
and are listed here only for completeness.</p>
<dl class="indent3">
  <dt>Fractal</dt>
    <dd>A structure exhibiting self-similarity. A search page that provides a
      "search within current results" feature will exhibit fractal-like
      properties, at least from a human perspective. The similarity of the
      "shape" of pages is often a result of the use of templates.<font
      color="#FF0000"> </font>Fractal structures are generally the result of
      generated presentations rather than the result of (human)
    authoring.</dd>
  <dt>Heap</dt>
    <dd>A contiguous collection of variable-sized content objects. The deck
      of cards model used in WAP could be viewed as a heap, and would also be
      perceived as such by the end user. There is an implied relationship
      between adjacent content objects without the necessity for explicit
      links. If the implied relationship is not supported by the device, the
      relationships must be made explicit (e.g. by introducing links to
      neighboring content objects).</dd>
  <dt>Tessellation</dt>
    <dd>A collection of content objects that completely fill a space. This
      structure is particularly important for rendering, and the author
      requires the ability to control the tessellation, typically through
      defining adjacency and proximity of content objects. The set of frames
      that fill a window in a frame-capable browser is a tessellation. A
      layout in a portal page is another tessellation, whether or not frames
      are used. This is a presentation-only structure and does not have a
      server-side equivalent. An important feature of this structure is the
      adjacency of edges to related frames/panes, where this relationship is
      held in a separate frames/layout definition. Tessellations lead to
      device independence problems when the characteristics of the device
      limit the possibilities for representing adjacency</dd>
</dl>

<h2><a name="appDIAI"></a>D Device Independence Authoring Implications</h2>

<p>Below is a brief summary of the challenges identified in the Authoring
Challenges document. They are paraphrased for brevity. It is these challenges
that the various authoring and adaptation techniques described in this Note
hope to address. For a detailed explanation, consult the AC document.</p>
<ul>
  <li>DIAS:I-3.1: Application Scope<br>
    <i>Should be able to offer all existing web applications to all
    devices.</i></li>
  <li>DIAS:I-3.2: Extensible Capabilities<br>
    <i>Be able to extend authoring to encompass new technologies.</i></li>
  <li>DIAS:I-3.3: Affordability<br>
    <i>Preferably low effort and low costs.</i></li>
  <li>DIAS:I-3.4: Simplicity<br>
    <i>Should be easy to build simple applications, and scale up
    accordingly.</i></li>
  <li>DIAS:I-3.5: Navigation Support<br>
    <i>Minimal effort to support varied navigation methods.</i></li>
  <li>DIAS:I-3.6: Organization<br>
    <i>Be able to select and restructure content as necessary.</i></li>
  <li>DIAS:I-3.7: Media Variety<br>
    <i>Support different version of deliverable media.</i></li>
  <li>DIAS:I-3.8: Interaction Abstraction<br>
    <i>Be able to devise abstractions of interaction to avoid device specific
    issues.</i></li>
  <li>DIAS:I-3.9: Interaction Abstraction Scope<br>
    <i>Cover interaction issues such as data entry, data selection, control
    functions and navigation.</i></li>
  <li>DIAS:I-3.10: Interaction Organization<br>
    <i>Control and selection of content material should include interaction
    elements.</i></li>
  <li>DIAS:I-3.11: Simple Content<br>
    <i>Be able to author using the most simple forms of content.</i></li>
  <li>DIAS:I-3.12: Text Content Variety<br>
    <i>Be able to use different versions of text, appropriate to the
    device.</i></li>
  <li>DIAS:I-3.13: Media Resource Variety<br>
    <i>Be able to use a variety of media formats.</i></li>
  <li>DIAS:I-3.14: Media Resource Specification<br>
    <i>Author should be able to specify which media resources are to be used
    according to context.</i></li>
  <li>DIAS:I-3.15: Media Resource Selection<br>
    <i>Support the ability to select a resource from a set of
    possibilities.</i></li>
  <li>DIAS:I-3.16: Media Resource Conversion<br>
    <i>Be able to generate alternative versions of a media resource.</i></li>
  <li>DIAS:I-3.17: Author Control of Media Resource Use<br>
    <i>Provide the author with the ability to control which forms of a media
    resource are used.</i></li>
  <li>DIAS:I-3.18: Application Data Integration<br>
    <i>Tools should assist the author in combining data with presentation
    resources, according to device limitations.</i></li>
  <li>DIAS:I-3.19 Integrating Device Independent Content<br>
    <i>Should be able to integrate external DI content into existing
    content.</i></li>
  <li>DIAS:I-3.20: Integrating Device Dependent Content<br>
    <i>Should be able to integrate external device-specific content into
    existing content (where possible).</i></li>
  <li>DIAS:I-3.21: Integrating Non-Presentation Markup<br>
    <i>Should not prevent the integration of non-presentation markup.</i></li>
  <li>DIAS:I-3.22: Dynamic Media Resource Specification<br>
    <i>Should be able to dynamically specify the media resources to be
    used.</i></li>
  <li>DIAS:I-3.23: Use of Client-Side Function<br>
    <i>Be able to take advantage of client-side functions
  (processing).</i></li>
  <li>DIAS:I-3.24: Abstraction of Client-Side Function<br>
    <i>Be able to exploit client-side functions without having to code
    explicitly for such devices.</i></li>
  <li>DIAS:I-3.25: Independence from Client-Side Function<br>
    <i>Be able to offer equivalent features (possibly server-side) in the
    absence of client-side functions.</i></li>
  <li>DIAS:I-3.26: Explicit Use of Client-Side Function<br>
    <i>Be able to customize for particular client-side functions.</i></li>
  <li>DIAS:I-3.27: Rich Media Interaction<br>
    <i>Should have abstractions of rich media interaction that hide the
    device-specific features.</i></li>
  <li>DIAS:I-3.28: Range of Complexity<br>
    <i>Should be able to support simple and complex interactions.</i></li>
  <li>DIAS:I-3.29: Scalability of Complexity<br>
    <i>Authoring techniques should scale smoothly with increasing application
    complexity.</i></li>
  <li>DIAS:I-3.30: Aggregation<br>
    <i>Should support aggregation operations to bring authoring units
    together into a presentation.</i></li>
  <li>DIAS:I-3.31: Fragmentation<br>
    <i>Should permit author to control fragmentation of a presentation into
    smaller parts.</i></li>
  <li>DIAS:I-3.32: Abstract Relationships<br>
    <i>Should support relationships between authoring units from which
    navigation structure may be derived.</i></li>
  <li>DIAS:I-4.1: Device Capability<br>
    <i>Be able to exploit the growing number of device capabilities.</i></li>
  <li>DIAS:I-4.2: Capability Abstraction<br>
    <i>Be able to describe desired presentations while abstracting the device
    capabilities.</i></li>
  <li>DIAS:I-4.3: Layout<br>
    <i>Be able to define a variety of layouts and their association with
    various devices.</i></li>
  <li>DIAS:I-4.4: Presentation Usability<br>
    <i>Be able to create presentations where the usability is appropriate to
    the device.</i></li>
  <li>DIAS:I-5.1: Presentation Personalization<br>
    <i>Permit user preferences to influence the creation of a
    presentation.</i></li>
  <li>DIAS:I-5.2: Modality<br>
    <i>Take into account the (input) modality of the device.</i></li>
  <li>DIAS:I-5.3: Language-Dependent Presentation<br>
    <i>Permit the (natural) language to influence the creation of the
    presentation.</i></li>
  <li>DIAS:I-5.4: Influence of Language on Presentation<br>
    <i>Permit language to influence the selection, structure, layout and
    other aspects of the presentation.</i></li>
  <li>DIAS:I-5.5: Influence of Language on Media Resources<br>
    <i>Permit language to influence the selection, structure, layout and
    other aspects of media resources.</i></li>
  <li>DIAS:I-6.1: Presentation Markup<br>
    <i>Presentation markup should be based on XHTML.</i></li>
  <li>DIAS:I-6.2: Interaction Markup<br>
    <i>Interaction markup should be based on XForms.</i></li>
  <li>DIAS:I-6.3: Non-Presentation Markup<br>
    <i>Non-presentation markup should be based on XML.</i></li>
  <li>DIAS:I-6.4: Transformation of Markup<br>
    <i>Transformation should be between XML languages and executable via
    XSLT.</i></li>
  <li>DIAS:I-6.5: Minimization of Effort<br>
    <i>Authoring effort should be minimized. Device diversity should be an
    advantage, not a burden.</i></li>
  <li>DIAS:I-6.6: Abstraction of Device Knowledge<br>
    <i>Authors should not require detailed knowledge of the target
    devices.</i></li>
  <li>DIAS:I-6.7: Functional Presentation<br>
    <i>Functional presentations should not require excessive effort.</i></li>
  <li>DIAS:I-6.8: Customized Presentation<br>
    <i>Authors should be able to customize for particular devices.</i></li>
  <li>DIAS:I-6.9: Exploitation of Device Capability<br>
    <i>Customizations should be able to exploit specific device
    capabilities.</i></li>
  <li>DIAS:I-6.10: Scalability of Effort<br>
    <i>The quality of a presentation should be directly proportional to the
    effort an author expends.</i></li>
  <li>DIAS:I-6.11: Future Device Capabilities<br>
    <i>New devices introduced after content is authored should still be able
    to access the content.</i></li>
  <li>DIAS:I-6.12: Reuse<br>
    <i>Authoring tools should permit significant reuse of materials.</i></li>
  <li>DIAS:I-6.13: Separation<br>
    <i>Reuse should be encouraged by separating device independent material
    from device dependent material.</i></li>
  <li>DIAS:I-6.14: Reuse of Functional Presentation<br>
    <i>Functional presentations should be accessible to new devices not
    considered during authoring.</i></li>
</ul>

<p></p>

<h2><a name="appAcknowledgements">E Acknowledgements</a></h2>

<p>This document was produced by members of the Device Independence Working
Group. With respect to this document, the role of participating members is
noted below:</p>
<ul class="simple">
  <li>Rotan Hanrahan, MobileAware (<i>Editor and Principal Author</i>)</li>
  <li>Roland Merrick, IBM (<i>Author and Co-editor</i>)</li>
  <li>Candy Wong, NTT DoCoMo (<i>Contributing Author</i>)</li>
  <li>Michael Wasmund, IBM (<i>Contributing Author</i>)</li>
  <li>Rhys Lewis, Volantis Systems (<i>Contributing Author</i>)</li>
  <li>Tayeb Lemlouma, INRIA (<i>Contributing Author</i>)</li>
  <li>Shlomit Ritz Finkelstein (<i>Contributor</i>)</li>
</ul>

<p>The principal and active members of the Device Independence Working Group
at the time of original publication are shown below.</p>
<ul class="simple">
  <li>Stephane Boyera, W3C</li>
  <li>Steve Farowich, Boeing Company</li>
  <li>Roger Gimson, HP (<i>Chair</i>)</li>
  <li>Yoshihisa Gonno, Sony Corporation</li>
  <li>Guido Grassel, Nokia Corporation</li>
  <li>Rotan Hanrahan, MobileAware Ltd</li>
  <li>Kazuhiro Kitagawa, W3C</li>
  <li>Markus Lauff, SAP AG</li>
  <li>Tayeb Lemlouma, INRIA</li>
  <li>Rhys Lewis, Volantis Systems Ltd</li>
  <li>Roland Merrick, IBM Corporation</li>
  <li>Franklin Reynolds, Nokia Corporation</li>
  <li>Andreas Schade, IBM Corporation</li>
  <li>Shahid Shoaib, NTT DoCoMo</li>
  <li>Luu Tran, Sun Microsystems, Inc.</li>
  <li>Cedric Ulmer, SAP AG</li>
  <li>Michael Wasmund, IBM Corporation</li>
  <li>Jason White, University of Melbourne</li>
  <li>Candy Wong, NTT DoCoMo</li>
  <li>Amy Yu, SAP AG</li>
</ul>

<p><i>Last modified: $Date: 2004/02/13 15:26:59 $</i></p>
</body>
</html>