discontinued / server · Files

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

<body lang="en">

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

<h1>Composite Capability/Preference Profiles (CC/PP): Structure and
Vocabularies 1.0</h1>

<h2>W3C Recommendation 15 January 2004</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/">http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/</a></dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/CCPP-struct-vocab/">http://www.w3.org/TR/CCPP-struct-vocab/</a></dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/">http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/</a></dd>
  <dt>Editors:</dt>
    <dd>Graham Klyne, <a href="mailto:GK@acm.org">GK@acm.org</a>, Nine by
    Nine</dd>
    <dd>Franklin Reynolds, <a
      href="mailto:franklin.reynolds@nokia.com">franklin.reynolds@nokia.com</a>,
      Nokia Research Center</dd>
    <dd>Chris Woodrow, <a
      href="mailto:woodroc@metaphoria.net">woodroc@metaphoria.net</a>,
      Information Architects</dd>
    <dd>Hidetaka Ohto, <a href="mailto:ohto@w3.org">ohto@w3.org</a>, W3C
      (through March 2002) / Panasonic</dd>
    <dd>Johan Hjelm, <a
      href="mailto:johan.hjelm@ericsson.com">Johan.hjelm@ericsson.com</a>,
      Ericsson</dd>
    <dd>Mark H. Butler, <a
      href="mailto:mark-h_butler@hp.com">mark-h_butler@hp.com</a>,
      Hewlett-Packard</dd>
    <dd>Luu Tran, <a href="mailto:luu.tran@sun.com">luu.tran@sun.com</a>, Sun
      Microsystems</dd>
</dl>

<p>Please refer to the <a
href="/2003/07/ccpp-SV-PR/errata/"><strong>errata</strong></a> for this
document, which may include some normative corrections.</p>

<p>The English version of this specification is the only normative version.
Non-normative <a href="/2003/07/ccpp-SV-PR/translation/">translations</a> may
also be available.  </p>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;©&nbsp;2004&nbsp;
<a href="http://www.w3.org/"><abbr
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
href="http://www.lcs.mit.edu/"><abbr
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
href="http://www.ercim.org/"><abbr
title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></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>
<hr title="Separator for header">
</div>

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

<p>This document describes CC/PP (Composite Capabilities/Preference Profiles)
structure and vocabularies. A CC/PP profile is a description of device
capabilities and user preferences. This is often referred to as a device's
delivery context and can be used to guide the adaptation of content presented
to that device.</p>

<p>The Resource Description Framework (RDF) is used to create profiles that
describe user agent capabilities and preferences. The structure of a profile
is discussed. Topics include:</p>
<ul>
  <li>structure of client capability and preference descriptions, AND</li>
  <li>use of RDF classes to distinguish different elements of a profile, so
    that a schema-aware RDF processor can handle CC/PP profiles embedded in
    other XML document types.</li>
</ul>

<p>CC/PP vocabulary is identifiers (URIs) used to refer to specific
capabilities and preferences, and covers:</p>
<ul>
  <li>the types of values to which CC/PP attributes may refer,</li>
  <li>an appendix describing how to introduce new vocabularies,</li>
  <li>an appendix giving an example small client vocabulary covering print
    and display capabilities, and</li>
  <li>an appendix providing a survey of existing work from which new
    vocabularies may be derived.</li>
</ul>

<h2><a name="DocumentStatus"></a>Status of this document</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 Recommendation of the W3C. It has been reviewed by W3C
Members and other interested parties, and has been endorsed by the Director
as a W3C Recommendation. It is a stable document and may be used as reference
material or cited as a normative reference from another document.</p>

<p>W3C's role in making the Recommendation is to draw attention to the
specification and to promote its widespread deployment. This enhances the
functionality and interoperability of the Web. A <a
href="http://www.w3.org/2003/07/ccpp-SV-PR/test-suite-20030827/">test
suite</a> for has been developed, along with an <a
href="http://www.w3.org/2003/07/ccpp-SV-PR/test-suite-20030827/implementation-report.html">implementation
report</a>.</p>

<p>This document has been produced by the W3C Device Independence Working
Group as part of the <a href="/2001/di/Activity">Device Independence
Activity</a> within the <a href="http://www.w3.org/Interaction/">W3C
Interaction Domain</a>.  Continued status of the work is reported on the <a
href="/2001/di/Group/">Device Independence Working Group Home Page</a> (<a
href="http://cgi.w3.org/MemberAccess/AccessRequest">Member-only link</a>).</p>

<p>The public is invited to send comments or reports errors to the editors at
<a href="mailto:www-mobile@w3.org">www-mobile@w3.org</a>, the public forum
for discussion of W3C's work on Mobile Web Access. An archive is available at
<a
href="http://lists.w3.org/Archives/Public/www-mobile/">http://lists.w3.org/Archives/Public/www-mobile/</a>.</p>

<p>Patent disclosures relevant to this specification may be found on the
CC/PP Working Group's <a href="/Mobile/CCPP/disclosures.html">patent
disclosure page</a> in conformance with W3C policy.</p>

<h2><a name="TableOfContents"></a>Table of contents</h2>
<ul>
  <li><a href="#Introduction"><strong>1. Introduction</strong></a>
    <ul>
      <li><a href="#ScopeOfDocument">1.1 Scope and normative elements</a></li>
      <li><a href="#StructureOfDoc">1.2 Structure of this document</a></li>
      <li><a href="#DocumentConventions">1.3 Document conventions</a>
        <ul>
          <li><a href="#TerminologyConventions">1.3.1 Terminology</a></li>
          <li><a href="#RDFGraphNotation">1.3.2 RDF graph notation</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#CCPPArchitecture"><strong>2. CC/PP architecture</strong></a>
    <ul>
      <li><a href="#CCPPProfileStructOverview">2.1 CC/PP profile structure</a>
        <ul>
          <li><a href="#xtocid-33666512">2.1.1 Profile components</a></li>
          <li><a href="#xtocid-33666513">2.1.2 Component attributes</a></li>
          <li><a href="#xtocid-33666514">2.1.3 Defaults</a></li>
        </ul>
      </li>
      <li><a href="#ExtensibilityNamespaces">2.2 Extensibility and
        namespaces</a></li>
    </ul>
  </li>
  <li><a href="#CCPPStructure"><strong>3. CC/PP structure</strong></a>
    <ul>
      <li><a href="#ProfileComponents">3.1 Components</a></li>
      <li><a href="#ProfileAttributes">3.2 Attributes</a></li>
      <li><a href="#ProfileDefaults">3.3 Defaults</a></li>
      <li><a href="#DistinguishStructAttrib">3.4 Distinguishing profile
        structure from attributes</a></li>
      <li><a href="#RDFUsage">3.5 Notes on RDF usage</a></li>
      <li><a href="#xtocid-58647528">3.6 RDF graph composition</a></li>
    </ul>
  </li>
  <li><a href="#AttributeVocabularies"><strong>4. Attribute
    vocabularies</strong></a>
    <ul>
      <li><a href="#AttributeData">4.1 Attribute data</a>
        <ul>
          <li><a href="#SimpleAttribute">4.1.1 Simple CC/PP attribute data</a>
            <ul>
              <li><a href="#xtocid-33666539">4.1.1.1 Strings</a></li>
              <li><a href="#xtocid-33666543">4.1.1.2 Integer numbers</a></li>
              <li><a href="#xtocid-33666544">4.1.1.3 Rational numbers</a></li>
            </ul>
          </li>
          <li><a href="#ComplexAttribute">4.1.2 Complex CC/PP attribute
            data</a>
            <ul>
              <li><a href="#4.1.2.1">4.1.2.1 Set of values</a></li>
              <li><a href="#4.1.2.2">4.1.2.2 Sequence of values</a></li>
            </ul>
          </li>
        </ul>
      </li>
      <li><a href="#xtocid-33666547">4.2 Attribute identifiers</a></li>
      <li><a href="#xtocid-33666548">4.3 RDF vocabulary schema</a></li>
    </ul>
  </li>
  <li><a href="#Conformance"><strong>5. Conformance</strong></a>
    <ul>
      <li><a href="#ConformanceDocument">5.1 CC/PP Document
      Conformance</a></li>
      <li><a href="#ConformanceProducer">5.2 CC/PP Producer
      Conformance</a></li>
      <li><a href="#ConformanceConsumer">5.3 CC/PP Consumer
      Conformance</a></li>
      <li><a href="#ConformanceClaims">5.4 Conformance Claims</a>
        <ul>
          <li><a href="#ConformanceClaimsValidity">5.4.1 Validity</a></li>
          <li><a href="#ConformanceClaimsWellformed">5.4.2
          Well-formed</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#Acknowledgements"><strong>6. Acknowledgments</strong></a></li>
  <li><a href="#xtocid-33666550"><strong>7. References</strong></a>
    <ul>
      <li><a href="#norm_refs">7.1 Normative References</a></li>
      <li><a href="#inform_refs">7.2 Informative References</a></li>
    </ul>
  </li>
  <li><a href="#Appendix_A"><strong>Appendix A: Terminology and
    abbreviations</strong></a>
    <ul>
      <li><a href="#Terminology">A.1 Terminology</a></li>
      <li><a href="#Abbreviations">A.2 Abbreviations</a></li>
    </ul>
  </li>
  <li><a href="#Appendix_B"><strong>Appendix B: RDF schema for
    structure</strong></a>
    <ul>
      <li><a href="#xtocid-33666555">B.1 Summary of CC/PP class
      hierarchy</a></li>
      <li><a href="#xtocid-33666556">B.2 Summary of CC/PP properties</a>
        <ul>
          <li><a href="#xtocid-33666557">Structural properties (instances of
            <tt>ccpp:Property</tt>)</a></li>
        </ul>
      </li>
      <li><a href="#xtocid-33666558">B.3 RDF Schema</a>
        <ul>
          <li><a href="#xtocid-33666559">CC/PP core and class
          structure:</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#Appendix_C"><strong>Appendix C: CC/PP attribute vocabulary
    for print and display</strong></a>
    <ul>
      <li><a href="#xtocid-33666562">Client attribute properties (instances
        of <tt>ccpp:Attribute</tt>)</a></li>
      <li><a href="#xtocid-62790564">Schema for client vocabulary</a></li>
    </ul>
  </li>
  <li><a href="#Appendix_D"><strong>Appendix D: Recommendations for creating
    a vocabulary</strong></a>
    <ul>
      <li><a href="#Basic">D.1 Basic format for all vocabulary items</a></li>
      <li><a href="#namespaces">D.2 Use of XML namespaces</a></li>
      <li><a href="#Principles">D.3 Principles for defining new attributes</a>
        <ul>
          <li><a href="#xtocid-33666567">D.3.1 If possible, reuse existing
            vocabularies</a></li>
          <li><a href="#3.3.2">D.3.2 Attribute value type and
            interpretation</a></li>
          <li><a href="#3.3.3">D.3.3 Interpretation not dependent on other
            attribute values</a></li>
          <li><a href="#3.3.4">D.3.4 Attribute naming conventions</a></li>
          <li><a href="#AttributeApplicability">D.3.5 Attributes should have
            specific applicability</a></li>
        </ul>
      </li>
      <li><a href="#ProtocolInteractions">D.4 Protocol interactions</a></li>
    </ul>
  </li>
  <li><a href="#Appendix_E"><strong>Appendix E: Review of applicable
    vocabularies</strong></a>
    <ul>
      <li><a href="#IETF">E.1 IETF media feature registration
      (CONNEG)</a></li>
      <li><a href="#UAPROF">E.2 WAP UAProf</a></li>
      <li><a href="#TIFF">E.3 TIFF</a></li>
      <li><a href="#WAVE">E.4 WAVE</a></li>
      <li><a href="#MPEG-4">E.5 MPEG-4</a></li>
      <li><a href="#MPEG-7">E.6 MPEG-7</a></li>
      <li><a href="#PWG">E.7 PWG</a></li>
      <li><a href="#Salutation">E.8 Salutation</a></li>
    </ul>
  </li>
  <li><a href="#Appendix_F"><strong>Appendix F: CC/PP
    applications</strong></a>
    <ul>
      <li><a href="#Outline">F.1 Outline of request processing in
      HTTP</a></li>
      <li><a href="#ProtocolAssumptions">F.2 Protocol assumptions for proxy
        behavior</a></li>
    </ul>
  </li>
  <li><a href="#Appendix_G"><strong>Appendix G: RDF Compatibility</strong></a>
    <ul>
      <li><a href="#RDFImplicitDatatyping">G.1 Implicit datatyping</a></li>
      <li><a href="#RDFExplicitDatatyping">G.2 Explicit datatyping</a></li>
    </ul>
  </li>
  <li><a href="#RevisionHistory"><strong>Appendix W: Revision
    history</strong></a></li>
</ul>

<h2><a name="Introduction"></a>1. Introduction</h2>

<p>This document describes CC/PP (Composite Capabilities/Preference Profiles)
structure and vocabularies. A CC/PP profile is a description of device
capabilities and user preferences that can be used to guide the adaptation of
content presented to that device. Here profile does not refer to a subset of
a particular specification, for example the CSS Mobile profile, but refers to
the document(s) exchanged between devices that describe the capabilities of a
device.</p>

<p>As the number and variety of devices connected to the Internet grows,
there is a corresponding increase in the need to deliver content that is
tailored to the capabilities of different devices. Some limited techniques,
such as HTTP '<code>accept</code>' headers and HTML '<code>alt=</code>'
attributes, already exist. As part of a framework for content adaptation and
contextualization, a general purpose profile format is required that can
describe the capabilities of a user agent and preferences of its user. CC/PP
is designed to be such a format.</p>

<p>CC/PP is based on RDF, the Resource Description Framework, which was
designed by the W3C as a general purpose metadata description language. RDF
provides the framework with the basic tools for both vocabulary
extensibility, via XML namespaces <a href="#2">[XMLNAMESPACES]</a>, and
interoperability. There is a specification that describes how to encode RDF
using XML <a href="#3">[RDF]</a>, and another that defines an RDF schema
description language using RDF <a href="#4">[RDFSCHEMA]</a>. RDF was designed
to describe the metadata or machine understandable properties of the Web. RDF
is a natural choice for the CC/PP framework since user agent profiles are
metadata intended primarily for communication between user agents and
resource data providers. For an introduction to RDF, see <a
href="#rdfprimer">[RDFPRIMER]</a>. Note that the <a
href="#rdfprimer">[RDFPRIMER]</a> document describes a more recent revision
of the RDF specifications than the ones on which this specification is
based.</p>

<p>A CC/PP profile contains a number of CC/PP attribute names and associated
values that are used by a server to determine the most appropriate form of a
resource to deliver to a client. It is structured to allow a client to
describe its capabilities by reference to a standard profile, accessible to
an origin server or other sender of resource data, and a smaller set of
features that are in addition to or different than the standard profile. A
set of CC/PP attribute names, permissible values and associated meanings
constitute a CC/PP vocabulary.</p>

<p>Some information contained in a profile may be sensitive, and adequate
trust and security mechanisms must be deployed to protect users' privacy. As
a part of a wider application, CC/PP cannot fully cover such issues, but is
intended to be used in conjunction with appropriate mechanisms. This topic is
covered in <a href="#Appendix_F">Appendix F</a>, (CC/PP applications).</p>

<p>It is anticipated that different applications will use different
vocabularies; indeed this is needed if application-specific properties are to
be represented within the CC/PP framework. But for different applications to
work together, some common vocabulary, or a method to convert between
different vocabularies, is needed. (XML namespaces can ensure that different
applications' names do not clash, but does not provide a common basis for
exchanging information between different applications.) Any vocabulary that
relates to the structure of a CC/PP profile must follow this specification.
The appendices introduce a simple CC/PP attribute vocabulary that may be used
to improve cross-application exchange of capability information, partly based
on some earlier IETF work.</p>

<p>CC/PP is designed to be broadly compatible with the earlier UAProf
specification <a href="#9">[UAPROF]</a> from the WAP Forum. That is, we have
attempted to accomodate existing UAProf profiles.</p>

<p>CC/PP is compatible with IETF media feature sets (CONNEG) <a
href="#6">[RFC2533]</a> in the sense that all media feature tags and values
can be expressed in CC/PP. However, not all CC/PP profiles can be expressed
as media feature tags and values, and CC/PP does not attempt to express
relationships between attributes.</p>

<p>Although the examples and use to date have been focused on device
capabilities, CC/PP can also convey information about user preferences that,
used sensibly, should be allow web servers to improve the accessibility of
web sites. A fuller discussion of web site accessibility can be found in the
Web Content Accessibility Guidelines <a href="#37">[WAI]</a>.</p>

<h3><a name="ScopeOfDocument"></a>1.1 Scope and normative elements</h3>

<p>CC/PP Structure and Vocabularies (abbreviated to CC/PP in the rest of this
document) defines a client profile data format, and a framework for
incorporating application- and operating environment-specific features. It
does not define how the profile is transferred, nor does it specify what
CC/PP attributes must be generated or recognized. CC/PP is designed for use
as part of a wider application framework. As such, the specification of CC/PP
elements that must be supported and those which may be omitted is a matter
for a specific application.</p>

<p>There are few protocol assumptions built into the design of CC/PP.
Although it is intended to be largely protocol independent, particular
consideration has been given to use of CC/PP with HTTP for retrieving Web
resources. <a href="#Appendix_F">Appendix F</a> contains some further
discussion of CC/PP applications.</p>

<p>This document describes a number of features of CC/PP. Some features form
part of the essential structure of CC/PP, for which conformance is REQUIRED
(see section <a href="#Conformance">5</a>). Others are features whose use is
RECOMMENDED or OPTIONAL. There is also discussion of how new vocabularies
should be introduced, directed to CC/PP application designers rather than
implementers.</p>

<p>The architecture <a href="#CCPPArchitecture">section</a> does not describe
specific features, but indicates general principles that underlie the design
of CC/PP. It is not normative but does contain information that should be
understood for proper implementation of CC/PP.</p>

<p>The section on <a href="#CCPPStructure">CC/PP structure</a> covers two
main areas:</p>
<ul>
  <li>CC/PP profile components: support for these is REQUIRED.</li>
  <li>CC/PP profile defaults: support for these is REQUIRED.</li>
</ul>

<p>The <a href="#AttributeVocabularies">section</a> on CC/PP attribute
vocabularies describes some general features of CC/PP attributes and their
values. Support for the described formats for simple attribute values is
RECOMMENDED -- the actual syntax for any simple CC/PP value is defined by the
corresponding attribute specification; such specifications may reference the
information provided here. Support for the structured CC/PP attribute formats
described, where relevant, is REQUIRED.</p>

<p>Support is not required for any specific vocabulary, but application
designers are strongly encouraged to re-use existing vocabularies where
possible.</p>

<p>CC/PP applications are not required to support features described in the
appendices, but any new attribute vocabularies defined MUST be based on RDF
classes and properties defined by the RDF schema in <a
href="#Appendix_B">Appendix B</a> (new CC/PP attributes are instances of
<code><i>ccpp</i>:Attribute</code>, new component classes are subclasses of
<code><i>ccpp</i>:Component</code>, etc.).</p>

<blockquote>
  <p><b><i>NOTE:</i></b> The reason for requiring new vocabularies to be
  based on the CC/PP schema is so that schema-aware applications can include
  CC/PP profile data along with other RDF data. Having new vocabulary terms
  based on the CC/PP schema means that they are clearly identifiable as part
  of a CC/PP profile when RDF data from multiple sources is combined. This
  requirement does not affect stand-alone CC/PP profile processors, but the
  real value of using RDF here will be in the longer term, allowing data from
  multiple sources (e.g. document, security and privacy related information)
  to be combined and processed by more general purpose handlers.</p>
</blockquote>

<h3><a name="StructureOfDoc"></a>1.2 Structure of this document</h3>

<p>The remainder of this section covers terminology, conventions and
notations used in this document.</p>

<p>Section 2, <a href="#CCPPArchitecture"><strong>CC/PP
architecture</strong></a>, provides an overview of the CC/PP profile
structure and use of XML namespaces.</p>

<p>Section 3, <a href="#CCPPStructure"><strong>CC/PP structure</strong></a>,
describes the structure of a CC/PP profile, and introduces the RDF elements
that are used to create the essential CC/PP elements.</p>

<p>Section 4, <a href="#AttributeVocabularies"><strong>Attribute
vocabularies</strong></a>, describes how attributes are used in a CC/PP
profile, and presents the recommended structure of CC/PP elements used to
describe specific features.</p>

<p>The appendices contain additional supporting material that is not
essential to construct a valid CC/PP profile, but which provides additional
background information useful for understanding CC/PP, its relationship with
RDF, or defining attribute vocabularies for specific applications.</p>

<h3><a name="DocumentConventions"></a>1.3 Document conventions</h3>

<h4><a name="TerminologyConventions"></a>1.3.1 Terminology</h4>

<p>See <cite>CC/PP terminology and abbreviations</cite> in <a
href="#Appendix_A">Appendix A</a> of this document.</p>

<p>The term "<dfn>CC/PP attribute</dfn>" is used here to refer to a specific
capability or characteristic of a client (or other system) that appears in a
CC/PP profile. The term "<dfn>feature</dfn>" refers to a client capability or
characteristic that may or may not be the basis of a CC/PP attribute. The
term "<dfn>attribute name</dfn>" is used to indicate an RDF property name
used to identify a CC/PP attribute.</p>

<p>The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", "MAY
NOT", "REQUIRED", "RECOMMENDED" and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 <a href="#25">[RFC2119]</a>.</p>

<h4><a name="RDFGraphNotation"></a>1.3.2 RDF graph notation</h4>

<p>The underlying structure of RDF is a directed labeled graph. For
communication between computer systems, RDF uses a serialization in XML to
represent these graphs. This XML notation is rather bulky and difficult for
human discourse, so a more visual notation is used here for describing RDF
graph structures:</p>

<table summary="Figure 1-1" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 1-1: RDF graph notation</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[<i>Subject-resource</i>] --<i>propertyName</i>--&gt; [<i>Object-resource</i>]</pre>

        <blockquote>
          Indicates a graph edge labeled '<i>propertyName</i>' from an RDF
          resource named 'Subject-resource' to another RDF resource named
          '<i>Object-resource</i>'.</blockquote>
        <pre>[<i>Subject-resource</i>] --<i>propertyName</i>--&gt; "<i>Property value</i>"</pre>

        <blockquote>
          Indicates a graph edge labeled 'propertyName' from an RDF resource
          named 'Subject-resource' to a literal string containing the
          indicated value.</blockquote>
        <pre>[<i>Subject-resource</i>] --<i>propertyName</i>--&gt; { "<i>Val1</i>", "<i>Val2</i>", ... }</pre>

        <blockquote>
          This is a shorthand for a property whose value is an
          <tt>rdf:Bag</tt> resource containing the indicated values (see
          section <a href="#4.1.2.1">4.1.2.1</a>).</blockquote>
        <pre>[&lt;<i>Subject-type</i>&gt;] --<i>propertyName</i>--&gt; [&lt;<i>Object-type</i>&gt;]</pre>

        <blockquote>
          Names in angle brackets are used to indicate an RDF resource of the
          indicated type (i.e. having the indicated <tt>rdf:Type</tt>
          property value), without indicating a specific name for the
          resource. This is useful for showing the RDF classes that may be
          linked by a property.</blockquote>
        <pre>[<i>Subject-resource</i>] --<i>propertyName</i>--&gt; [<i>Object-resource</i>]
                                      |
       -------------------------------
      |
      +--<i>property1</i>--&gt; <i>(val1)</i>
      +--<i>property2</i>--&gt; <i>(val2)</i>
      :
     (etc.)</pre>

        <blockquote>
          Property arcs can be chained, and multiple arcs drawn from a
          subject resource.</blockquote>
      </td>
    </tr>
  </tbody>
</table>

<p>Here are some XML examples of the RDF graph structures described above:</p>

<table summary="Figure 1-2" border="1" width="0%" bgcolor="#CCFFCC">
  <caption align="bottom">Figure 1-2: RDF graph example in XML</caption>
  <tbody>
    <tr>
      <td><pre>&lt;?xml version="1.0"?&gt;
&lt;!-- Any RDF graph is an RDF element
  --&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns="http://www.example.com/schema#"&gt;

  &lt;!--  [<i>Subject-resource</i>] -<i>propertyName</i>-&gt; [<i>Object-resource</i>]
    --&gt;
  &lt;rdf:Description
      rdf:about="<i>http://www.example.com/profile#Subject-resource</i>"&gt;
    &lt;<i>propertyName</i>&gt;
      &lt;rdf:Description
          rdf:about="<i>http://www.example.com/profile#Object-resource</i>" /&gt;
    &lt;/<i>propertyName</i>&gt;
  &lt;/rdf:Description&gt;

  &lt;!--  [<i>Subject-resource</i>] -<i>propertyName</i>-&gt; [<i>Object-resource</i>]
     -  (Alternative format)
    --&gt;
  &lt;rdf:Description
      rdf:about="<i>http://www.example.com/profile#Subject-resource</i>"&gt;
    &lt;<i>propertyName</i>
        rdf:resource="<i>http://www.example.com/schema#Object-resource</i>" /&gt;
  &lt;/rdf:Description&gt;

  &lt;!--  [<i>Subject-resource</i>] -<i>propertyName</i>-&gt; "<i>property value</i>"
    --&gt;
  &lt;rdf:Description
      rdf:about="<i>http://www.example.com/profile#Subject-resource</i>"&gt;
    &lt;<i>propertyName</i>&gt;<i>property value</i>&lt;/<i>propertyName</i>&gt;
  &lt;/rdf:Description&gt;

  &lt;!--  [<i>Subject-resource</i>] -<i>propertyName</i>-&gt; { "<i>Val1</i>", "<i>Val2</i>", ... }
    --&gt;
  &lt;rdf:Description
      rdf:about="<i>http://www.example.com/profile#Subject-resource</i>"&gt;
    &lt;<i>propertyName</i>&gt;
      &lt;rdf:Description&gt;
        &lt;rdf:type
            rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" /&gt;
        &lt;rdf:li&gt;<i>Val1</i>&lt;/rdf:li&gt;
        &lt;rdf:li&gt;<i>Val1</i>&lt;/rdf:li&gt;

        &lt;!-- ...etc... --&gt;

      &lt;/rdf:Description&gt;
    &lt;/<i>propertyName</i>&gt;
  &lt;/rdf:Description&gt;

  &lt;!--  [<i>Subject-resource</i>] -<i>propertyName</i>-&gt; { "<i>Val1</i>", "<i>Val2</i>", ... }
     -  (Alternative format)
    --&gt;
  &lt;rdf:Description
      rdf:about="<i>http://www.example.com/profile#Subject-resource</i>"&gt;
    &lt;<i>propertyName</i>&gt;
      &lt;rdf:Bag&gt;
        &lt;rdf:li&gt;<i>Val1</i>&lt;/rdf:li&gt;
        &lt;rdf:li&gt;<i>Val1</i>&lt;/rdf:li&gt;

        &lt;!-- ...etc... --&gt;

      &lt;/rdf:Bag&gt;
    &lt;/<i>propertyName</i>&gt;
  &lt;/rdf:Description&gt;

  &lt;!--  [&lt;<i>Subject-type</i>&gt;] -<i>propertyName</i>-&gt; [&lt;<i>Object-type</i>&gt;]
    --&gt;
  &lt;rdf:Description&gt;
    &lt;rdf:type
        rdf:resource="<i>http://www.example.com/schema#Subject-type</i>" /&gt;
    &lt;<i>propertyName</i>&gt;
      &lt;rdf:Description&gt;
        &lt;rdf:type
            rdf:resource="<i>http://www.example.com/schema#Object-type</i>" /&gt;
      &lt;/rdf:Description&gt;
    &lt;/<i>propertyName</i>&gt;
  &lt;/rdf:Description&gt;</pre>
        <pre>  &lt;!--  [<i>Subject-resource</i>] -<i>propertyName</i>-&gt; [<i>Object-resource</i>]
     -                                      |
     -                                      +-<i>property1</i>-&gt; <i>(val1)</i>
     -                                      +-<i>property2</i>-&gt; <i>(val2)</i>
     -                                      :
    --&gt;
  &lt;rdf:Description
      rdf:about="<i>http://www.example.com/profile#Subject-resource</i>"&gt;
    &lt;<i>propertyName</i>&gt;
      &lt;rdf:Description
          rdf:about="<i>http://www.example.com/profile#Object-resource</i>" &gt;
      &lt;<i>property1</i>&gt;<i>val1</i>&lt;/<i>property1</i>&gt;
      &lt;<i>property2</i>&gt;<i>val2</i>&lt;/<i>property2</i>&gt;

      &lt;!-- ...etc... --&gt;

      &lt;/rdf:Description&gt;
    &lt;/<i>propertyName</i>&gt;
  &lt;/rdf:Description&gt;

&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<h2><a name="CCPPArchitecture"></a>2. CC/PP architecture</h2>

<p>This section is not normative, but provides an overview of the features of
CC/PP.</p>

<h3><a name="CCPPProfileStructOverview"></a>2.1 CC/PP profile structure</h3>

<p>A CC/PP profile is broadly constructed as a 2-level hierarchy:</p>
<ul>
  <li>a profile having at least one or more <dfn>components</dfn>, and</li>
  <li>each component having at least one or more <dfn>attributes</dfn>.</li>
</ul>

<h4><a name="xtocid-33666512">2.1.1 Profile components</a></h4>

<p>The initial branches of the CC/PP profile tree describe major components
of the client. Examples of major components are:</p>
<ul>
  <li>the hardware platform upon which software is executing,</li>
  <li>the software platform upon which all applications are hosted, or</li>
  <li>an individual application, such as a browser.</li>
</ul>

<p>A simple, graphical representation of the bottom of a CC/PP tree based on
three components (<code>TerminalHardware</code>,
<code>TerminalSoftware</code> and <code>TerminalBrowser</code>) would be:</p>

<table summary="Figure 2-1a" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 2-1a: CC/PP profile components</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[<i>example</i>:MyProfile]
 |
 +--<i>ccpp</i>:component--&gt;[<i>example</i>:TerminalHardware]
 +--<i>ccpp</i>:component--&gt;[<i>example</i>:TerminalSoftware]
 +--<i>ccpp</i>:component--&gt;[<i>example</i>:TerminalBrowser]</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>The corresponding XML might look like this:</p>

<table summary="Figure 2-1b" border="1" width="0%" bgcolor="#CCFFCC">
  <caption align="bottom">Figure 2-1b: CC/PP profile components in
  XML</caption>
  <tbody>
    <tr>
      <td><pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
         xmlns:example="http://www.example.com/schema#"&gt;

  &lt;rdf:Description rdf:about="http://www.example.com/profile#MyProfile"&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalHardware"&gt;
        &lt;!--  TerminalHardware properties here  --&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalSoftware"&gt;
        &lt;!--  TerminalSoftware properties here  --&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalBrowser"&gt;
        &lt;!--  TerminalBrowser properties here  --&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<h4><a name="xtocid-33666513">2.1.2 Component attributes</a></h4>

<p>A CC/PP profile describes client capabilities and preferences in terms of
a number of "CC/PP attributes" for each component.</p>

<p>The description of each component is a sub-tree whose branches are the
capabilities or preferences associated with that component. Though RDF makes
modeling a wide range of data structures possible, including arbitrary
graphs, complex data models are usually best avoided for profile attribute
values. A capability can often be described using a small number of CC/PP
attributes, each having a simple, atomic value. Where more complex values are
needed, these can be constructed as RDF subgraphs. One useful case for
complex attribute values is to represent alternative values; e.g. a browser
may support multiple versions of HTML. A hypothetical profile might look like
this:</p>

<table summary="Figure 2-2a" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 2-2a: Complete CC/PP profile
  example</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[<i>ex</i>:MyProfile]
 |
 +--<i>ccpp</i>:component--&gt;[<i>ex</i>:TerminalHardware]
 |                    |
 |                    +--<i>rdf</i>:type----&gt; [<i>ex</i>:HardwarePlatform]
 |                    +--<i>ex</i>:displayWidth--&gt; "320"
 |                    +--<i>ex</i>:displayHeight--&gt; "200"
 |
 +--<i>ccpp</i>:component--&gt;[<i>ex</i>:TerminalSoftware]
 |                    |
 |                    +--<i>rdf</i>:type----&gt; [<i>ex</i>:SoftwarePlatform]
 |                    +--<i>ex</i>:name-----&gt; "EPOC"
 |                    +--<i>ex</i>:version--&gt; "2.0"
 |                    +--<i>ex</i>:vendor---&gt; "Symbian"
 |
 +--<i>ccpp</i>:component--&gt;[<i>ex</i>:TerminalBrowser]
                      |
                      +--<i>rdf</i>:type----&gt; [<i>ex</i>:BrowserUA]
                      +--<i>ex</i>:name-----&gt; "Mozilla"
                      +--<i>ex</i>:version--&gt; "5.0"
                      +--<i>ex</i>:vendor---&gt; "Symbian"
                      +--<i>ex</i>:htmlVersionsSupported--&gt; [ ]
                                                      |
                          ----------------------------
                         |
                         +--<i>rdf</i>:type---&gt; [<i>rdf</i>:Bag]
                         +--<i>rdf</i>:_1-----&gt; "3.2"
                         +--<i>rdf</i>:_2-----&gt; "4.0"</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>The corresponding XML might look like this:</p>

<table summary="Figure 2-2b" border="1" width="0%" bgcolor="#CCFFCC">
  <caption align="bottom">Figure 2-2b: Complete CC/PP profile example in
  XML</caption>
  <tbody>
    <tr>
      <td><pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
         xmlns:ex="http://www.example.com/schema#"&gt;

  &lt;rdf:Description
      rdf:about="http://www.example.com/profile#MyProfile"&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalHardware"&gt;
        &lt;rdf:type
            rdf:resource="http://www.example.com/schema#HardwarePlatform" /&gt;
        &lt;ex:displayWidth&gt;320&lt;/ex:displayWidth&gt;
        &lt;ex:displayHeight&gt;200&lt;/ex:displayHeight&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalSoftware"&gt;
        &lt;rdf:type
            rdf:resource="http://www.example.com/schema#SoftwarePlatform" /&gt;
        &lt;ex:name&gt;EPOC&lt;/ex:name&gt;
        &lt;ex:version&gt;2.0&lt;/ex:version&gt;
        &lt;ex:vendor&gt;Symbian&lt;/ex:vendor&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalBrowser"&gt;
        &lt;rdf:type
            rdf:resource="http://www.example.com/schema#BrowserUA" /&gt;
        &lt;ex:name&gt;Mozilla&lt;/ex:name&gt;
        &lt;ex:version&gt;5.0&lt;/ex:version&gt;
        &lt;ex:vendor&gt;Symbian&lt;/ex:vendor&gt;
        &lt;ex:htmlVersionsSupported&gt;
          &lt;rdf:Bag&gt;
            &lt;rdf:li&gt;3.2&lt;/rdf:li&gt;
            &lt;rdf:li&gt;4.0&lt;/rdf:li&gt;
          &lt;/rdf:Bag&gt;
        &lt;/ex:htmlVersionsSupported&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<h4><a name="xtocid-33666514">2.1.3 Defaults</a></h4>

<p>The attributes of a component can be included directly, as in the previous
example, or may be specified by reference to a default profile, which may be
stored separately and accessed using its specified URI.</p>

<p>This use of an externally defined default profile is somewhat similar to
the idea of dynamic inheritance. It makes possible some important
optimizations. As a separate document, it can reside at a separate location
and it can be separately cached. This is particularly useful in wireless
environments such as cellular networks, where the profiles may be large and
the client link slow and expensive. Using default values, only a small part
of the overall profile is sent over the wireless network.</p>

<p>Default values for a component of a CC/PP profile are indicated by a
<code><i>ccpp</i>:defaults</code> arc from the component concerned to a
component that describes the default values.</p>

<table summary="Figure 2-3a" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 2-3a: CC/PP profile using defaults</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[<i>ex</i>:MyProfile]

 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalHardware]
 |                     |
 |                     +--<i>rdf</i>:type-------&gt; [<i>ex</i>:HardwarePlatform]
 |                     +--<i>ccpp</i>:defaults--&gt; [<i>ex</i>:HWDefault]
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalSoftware]
 |                     |
 |                     +--<i>rdf</i>:type-------&gt; [<i>ex</i>:SoftwarePlatform]
 |                     +--<i>ccpp</i>:defaults--&gt; [<i>ex</i>:SWDefault]
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalBrowser]
                       |
                       +--<i>rdf</i>:type-------&gt; [<i>ex</i>:BrowserUA]
                       +--<i>ccpp</i>:defaults--&gt; [<i>ex</i>:UADefault]

[<i>ex</i>:HWDefault]
 |
 +--<i>rdf</i>:type----&gt; [<i>ex</i>:HardwarePlatform]
 +--<i>ex</i>:displayWidth--&gt; "320"
 +--<i>ex</i>:displayHeight--&gt; "200"

[<i>ex</i>:SWDefault]
 |
 +--<i>rdf</i>:type----&gt; [<i>ex</i>:SoftwarePlatform]
 +--<i>ex</i>:name-----&gt; "EPOC"
 +--<i>ex</i>:version--&gt; "2.0"
 +--<i>ex</i>:vendor---&gt; "Symbian"

[<i>ex</i>:UADefault]
 |
 +--<i>rdf</i>:type----&gt; [<i>ex</i>:BrowserUA]
 +--<i>ex</i>:name-----&gt; "Mozilla"
 +--<i>ex</i>:version--&gt; "5.0"
 +--<i>ex</i>:vendor---&gt; "Symbian"
 +--<i>ex</i>:htmlVersionsSupported--&gt; [ ]
                                 |
                                 +--<i>rdf</i>:type---&gt; [<i>rdf</i>:Bag]
                                 +--<i>rdf</i>:_1-----&gt; "3.2"
                                 +--<i>rdf</i>:_2-----&gt; "4.0"</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>The corresponding XML might look like this:</p>

<table summary="Figure 2-3b" border="1" width="0%" bgcolor="#CCFFCC"
cellpadding="3">
  <caption align="bottom">Figure 2-3b: CC/PP profile using defaults in
  XML</caption>
  <tbody>
    <tr>
      <td><b>Device profile referencing defaults:</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
         xmlns:ex="http://www.example.com/schema#"&gt;

  &lt;rdf:Description
      rdf:about="http://www.example.com/profile#MyProfile"&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalHardware"&gt;
        &lt;rdf:type
            rdf:resource="http://www.example.com/schema#HardwarePlatform" /&gt;
        &lt;ccpp:defaults
            rdf:resource="http://www.example.com/hardwareProfile#HWDefault" /&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalSoftware"&gt;
        &lt;rdf:type
            rdf:resource="http://www.example.com/schema#SoftwarePlatform" /&gt;
        &lt;ccpp:defaults
            rdf:resource="http://www.example.com/softwareProfile#SWDefault" /&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalBrowser"&gt;
        &lt;rdf:type
            rdf:resource="http://www.example.com/schema#BrowserUA" /&gt;
        &lt;ccpp:defaults
            rdf:resource="http://www.example.com/terminalProfile#UADefault" /&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
        <b>Defaults for HardwarePlatform:</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#"&gt;
  &lt;rdf:Description
      rdf:about="http://www.example.com/hardwareProfile#HWDefault"&gt;
    &lt;rdf:type
        rdf:resource="http://www.example.com/schema#HardwarePlatform" /&gt;
    &lt;ex:displayWidth&gt;320&lt;/ex:displayWidth&gt;
    &lt;ex:displayHeight&gt;200&lt;/ex:displayHeight&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
        <b>Defaults for SoftwarePlatform:</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#"&gt;
  &lt;rdf:Description
      rdf:about="http://www.example.com/softwareProfile#SWDefault"&gt;
    &lt;rdf:type
        rdf:resource="http://www.example.com/schema#SoftwarePlatform" /&gt;
    &lt;ex:name&gt;EPOC&lt;/ex:name&gt;
    &lt;ex:version&gt;2.0&lt;/ex:version&gt;
    &lt;ex:vendor&gt;Symbian&lt;/ex:vendor&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
        <b>Defaults for BrowserUA:</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#"&gt;
  &lt;rdf:Description
      rdf:about="http://www.example.com/terminalProfile#UADefault"&gt;
    &lt;rdf:type
        rdf:resource="http://www.example.com/schema#BrowserUA" /&gt;
    &lt;ex:name&gt;Mozilla&lt;/ex:name&gt;
    &lt;ex:version&gt;5.0&lt;/ex:version&gt;
    &lt;ex:vendor&gt;Symbian&lt;/ex:vendor&gt;
    &lt;ex:htmlVersionsSupported&gt;
      &lt;rdf:Bag&gt;
        &lt;rdf:li&gt;3.2&lt;/rdf:li&gt;
        &lt;rdf:li&gt;4.0&lt;/rdf:li&gt;
      &lt;/rdf:Bag&gt;
    &lt;/ex:htmlVersionsSupported&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>If a given attribute value is applied directly to a component resource,
and also appears on a resource referenced by the
<i><code>ccpp</code></i><code>:defaults</code> property, the directly applied
value takes precedence:</p>

<table summary="Figure 2-4a" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 2-4a: Overriding a default value</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[<i>ex</i>:MyProfile]
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalHardware]
                       |
                       +--<i>rdf</i>:type--------&gt; [<i>ex</i>:HardwarePlatform]
                       +--<i>ccpp</i>:defaults---&gt; [<i>ex</i>:HWDefault]
                       +--<i>ex</i>:memoryMb-------&gt; "32"

[<i>ex</i>:HWDefault]
 |
 +--<i>rdf</i>:type----&gt; [<i>ex</i>:HardwarePlatform]
 +--ex:displayWidth--&gt; "320"
 +--ex:displayHeight--&gt; "200"
 +--<i>ex</i>:memoryMb---&gt; "16"</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>In this example, the default component indicates 16 Mb of memory, but this
value is overridden by the <code>memoryMb</code> property applied directly to
the profile component. Thus, in this profile, the <code>memoryMb</code>
attribute has a value of 32.</p>

<p>The corresponding XML might look like this:</p>

<table summary="Figure 2-4b" border="1" width="0%" bgcolor="#CCFFCC"
cellpadding="3">
  <caption align="bottom">Figure 2-4b: Overriding a default value in
  XML</caption>
  <tbody>
    <tr>
      <td><b>Device profile referencing defaults:</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
         xmlns:ex="http://www.example.com/schema#"&gt;

  &lt;rdf:Description
      rdf:about="http://www.example.com/profile#MyProfile"&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description
          rdf:about="http://www.example.com/profile#TerminalHardware"&gt;
        &lt;rdf:type
            rdf:resource="http://www.example.com/schema#HardwarePlatform" /&gt;
        &lt;ccpp:defaults
            rdf:resource="http://www.example.com/hardwareProfile#HWDefault" /&gt;
        &lt;ex:memoryMb&gt;32&lt;/ex:memoryMb&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
        <b>Defaults for HardwarePlatform:</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#"&gt;
  &lt;rdf:Description
      rdf:about="http://www.example.com/hardwareProfile#HWDefault"&gt;
    &lt;rdf:type
        rdf:resource="http://www.example.com/schema#HardwarePlatform" /&gt;
    &lt;ex:displayWidth&gt;320&lt;/ex:displayWidth&gt;
    &lt;ex:displayHeight&gt;200&lt;/ex:displayHeight&gt;
    &lt;ex:memoryMb&gt;16&lt;/ex:memoryMb&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>A resource indicated by a default property may appear in a separate
document, in which case an absolute URI reference should be specified for the
default resource. In such cases, the URI part of the default resource
identifier (i.e. not including the fragment identifier part) is used to
retrieve an RDF document containing the default resource description. Thus,
if the default resource is named
<code>http://example.com/DeviceProfile#HardwarePlatform</code>, the URI
<code>http://example.com/DeviceProfile</code> is used to retrieve an RDF
document, and a resource within that document having the local identifier
<code>#HardwarePlatform</code> is taken as the default resource. (Such a
resource might be defined within the target document using
"<code>about='http://example.com/DeviceProfile#HardwarePlatform'</code>" or
"<code>ID='HardwarePlatform'</code>". See also section <a
href="#RDFUsage">3.5.</a>)</p>

<blockquote>
  <p><i><b>NOTE</b></i>: Individual applications may allow relative URIs to
  be used. Those that do should specify exactly how the corresponding RDF
  document is located.</p>
</blockquote>

<h3><a name="ExtensibilityNamespaces"></a>2.2 Extensibility and
namespaces</h3>

<p>CC/PP is extended primarily through the introduction of new attribute
vocabularies.</p>

<p>Any application or operational environment that uses CC/PP may define its
own vocabulary, but wider interoperability is enhanced if vocabularies are
defined that can be used more generally; e.g. a standard extension vocabulary
for imaging devices, or voice messaging devices, or wireless access devices,
etc. Accordingly, this specification defines a small core vocabulary of
features that are applicable to range of print and display agents whose use,
where appropriate, is strongly recommended. This core vocabulary is based on
IETF specification RFC2534 <a href="#8">[RFC2534]</a>, and serves as an
example of how CC/PP attribute vocabularies may be defined. Another such
example is the WAP Forum UAProf specification <a href="#9">[UAPROF]</a>.</p>

<p>Any CC/PP expression can use terms drawn from an arbitrary number of
different vocabularies, so there is no restriction caused by re-using terms
from an existing vocabulary rather then defining new names to identify the
same information. Each vocabulary is associated with an XML namespace, as are
the names that describe the underlying RDF and CC/PP structures.</p>

<p>XML namespaces <a href="#2">[XMLNAMESPACES]</a> define a notation for
associating convenient name forms with arbitrary URIs. The RDF graph syntax
does not specifically employ namespaces, but XML serializations of an RDF
graph do. We also use namespace prefixes when presenting RDF in the graph
notation described above.</p>

<p>The CC/PP framework uses the XML namespace mechanism to create identifying
URIs for RDF core elements, CC/PP structural elements and CC/PP attribute
vocabularies. Consider the following namespace declaration example:</p>

<table summary="Figure 2-7" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 2-7: Example namespace declarations</caption>
  <tbody>
    <tr bgcolor="#CCFFCC">
      <td><pre>&lt;?xml version="1.0"?&gt;
&lt;RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
     xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#"&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>The first namespace declaration is for RDF usage. The second declaration
names the CC/PP core structural vocabulary, which includes
"<code>component</code>", "<code>defaults</code>" and other properties that
are intrinsic to the CC/PP framework. The third namespace declaration names a
component CC/PP properties vocabulary.</p>

<blockquote>
  <p><b><i>NOTE:</i></b> Remember that the namespace prefixes are quite
  arbitrary: applications MUST NOT assume that the prefix <code>rdf:</code>
  refers to the RDF vocabulary, or that <code>ccpp:</code> refers to the
  intrinsic CC/PP vocabulary, etc. It is the URI to which a namespace prefix
  is bound that matters.</p>
</blockquote>

<blockquote>
  <p><b><i>NOTE:</i></b> Although namespace names are identified by URI
  references, there is no requirement that a schema be available at that URI.
  In the above example, the UAProf namespace name is
  "<code>http://www.wapforum.org/UAPROF/ccppschema-20000405#</code>" yet
  there is no schema at that URI. It is generally preferred practice that a
  corresponding schema exists at the URL used to identify a namespace, but
  this is not a requirement and CC/PP applications MUST NOT assume that such
  a schema will exist.</p>
</blockquote>

<p>The use of multiple component property vocabularies is allowed and
encouraged. Different user communities and application domains (WAP Forum,
ETSI, MExE, IETF CONNEG, etc.) may define their own property vocabularies.
This is an important mechanism for providing support for the needs of those
communities.</p>

<p>The following namespaces are introduced by the CC/PP framework:</p>

<p><b><a
href="/2002/11/08-ccpp-schema">http://www.w3.org/2002/11/08-ccpp-schema</a></b>#</p>

<blockquote>
  Normative RDF schema defining class declarations for CC/PP, and core
  structural properties (listed in <a href="#xtocid-33666558">Appendix
  B.3</a>).</blockquote>
<b><a
href="/2002/11/08-ccpp-client">http://www.w3.org/2002/11/08-ccpp-client</a></b>#

<blockquote>
  Example but non-normative vocabulary for describing simple client
  capabilities, with particular relevance to print and display clients
  (listed in <a href="#Appendix_C">Appendix C</a>).</blockquote>

<blockquote>
  <p><b><i>NOTE:</i></b> To retrieve these schemas it is necessary for your
  browser to add the header <code>Accept:text/xml</code> in the request.
  Browsers that do not add this accept header or use the header
  <code>Accept:*/*</code> or variants thereof will receive a HTML page that
  notes these are namespaces reserved for the CC/PP Schemas.</p>
</blockquote>

<h2><a name="CCPPStructure"></a>3. CC/PP structure</h2>

<p>The general structure of a CC/PP client profile is a two-level tree:
components and attributes, with provision for each component to reference an
externally defined set of default attribute values.</p>

<h3><a name="ProfileComponents"></a>3.1 Components</h3>

<p>A CC/PP profile contains one or more <dfn>components</dfn>, and each
component contains one or more attributes. Each component is represented by a
resource of type <code><i>ccpp</i>:Component</code> (or some RDFS subclass
thereof), and related to the client profile resource by a
<code><i>ccpp</i>:component</code> property. Here, the
<code><i>ccpp</i></code> namespace is
http://www.w3.org/2002/11/08-ccpp-schema#. For compatibility with UAProf, the
namespace used to qualify <code>component</code> MAY be a UAProf
namespace.</p>

<p>The object of a <code><i>ccpp</i>:Component</code> resource MAY have an
<code><i>rdf</i>:type</code> property (or equivalent RDF structure)
indicating what kind of client component it describes. The example in figure
2-2b is of a profile with an explicit indication of component subtype.
However, CC/PP processors MUST be able to handle profiles that do not contain
component type indicators. As long as the CC/PP attributes used are all
specific to a given component type, a processor will have sufficient
information to interpret them properly. No more than one instance of a
component type should be present for any given profile resource.</p>

<p>If a CC/PP profile uses any attribute that can appear on different
component types, then the type of any component on which such an attribute
appears MUST be indicated by an <code><i>rdf</i>:type</code> property, or
equivalent RDF. A CC/PP processor MUST be able to use this type information
to disambiguate application of any attribute used.</p>

<h3><a name="ProfileAttributes"></a>3.2 Attributes</h3>

<p>CC/PP profiles are constructed using RDF <a href="#3">[RDF]</a>. The RDF
data model represents CC/PP attributes as named <i>properties</i> linking a
<i>subject</i> resource to an associated <i>object</i> resource or RDF
literal value.</p>

<p>To describe client capabilities and preferences, the client being
described is a resource whose features are described by labeled graph edges
from that resource to corresponding object values. The graph edge labels
identify the client feature (CC/PP attribute) being described, and the
corresponding object values are the feature values.</p>

<table summary="Figure 3-1" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 3-1: RDF statement describing a client
  attribute</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[Client component resource] --attributeName--&gt; (Attribute-value)</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>CC/PP attribute labels are represented by XML name values (per XML
specification <a href="#1">[XML]</a>, section 2.3), which may include a
namespace prefix (i.e. a <i>qualified name</i>, per XML namespaces <a
href="#2">[XMLNAMESPACES]</a>, section 3). When combined with the
corresponding namespace or default namespace declaration, each label MUST be
mapped to a URI. Thus, CC/PP attribute names are URIs, with XML namespace
syntax used to avoid some of the RDF expressions becoming too cumbersome.</p>

<p>Attribute values may be of simple or structured data types.</p>

<p>Simple data types are discussed in the section <a
href="#SimpleAttribute">4.1.1</a>. Each basic data type may support a range
of tests that can be used in the process of determining the suitability of
different resource variants for presentation by a client; e.g. equality,
compatibility, less-than, greater-than, etc.</p>

<p>Structured data types are supported through the use of specific RDF
properties that join simple RDF literal values into composites. Specific
CC/PP semantics for RDF properties used in this way are discussed in the
section <a href="#ComplexAttribute">4.1.2</a>.</p>

<h3><a name="ProfileDefaults"></a>3.3 Defaults</h3>

<p>Each component of a client profile may indicate a single separate resource
that in turn indicates a subordinate collection of default attribute values.
This collection of default values can be a separate RDF document that is
named via a URI, or can appear in the same document as the client profile
(though, in practice, there is probably little value in defaults in the same
document). If an attribute in the collection of defaults is also present in
the main part of the client profile, the non-default value takes precedence.
The intent is that a hardware vendor or system supplier may provide default
values that are common to a number of systems in a place easily accessible to
an origin server, and then use the client profile to specify variations from
the common profile. The owner of the product or system operator may be able
to add or change options, such as additional memory, that add new
capabilities or change the values of some original capabilities.</p>

<p>Default values are referenced by the property
<i><code>ccpp</code></i><code>:defaults</code>. This name conforms to the
name format recommendations of the RDF model and syntax specification <a
href="#3">[RDF]</a>, Appendix C.1. However, for compatibility with earlier
versions of CC/PP used with UAProf, CC/PP processors SHOULD recognize the
property name <code><i>ccpp</i>:Defaults</code> (i.e. with capital "D") as
equivalent. Here, the <code><i>ccpp</i></code> namespace is
http://www.w3.org/2002/11/08-ccpp-schema#. For compatibility with UAProf, the
namespace used to qualify <code>defaults</code> or <code>Defaults</code> MAY
be a UAProf namespace.</p>

<p>Defaults can be encoded inline or as separate documents referred to via
URI. Defaults can not be encoded both inline and as a separate document. It
is the responsibility of any server interpreting a CC/PP to combine profiles
with any externally referenced defaults in such a way as to be able to
correctly interpret the profile. A profile with defaults in the same document
is logically equivalent to a profile with the same non-default data and
referenced external document(s) containing the default values. Here is a
simple profile graph using default values:</p>

<table summary="Figure 3-2a" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 3-2a: CC/PP profile using defaults</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[<i>ex</i>:MyProfile]
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalHardware]
 |                     |
 |                     +--<i>rdf</i>:type-------&gt; [<i>ex</i>:HardwarePlatform]
 |                     +--<i>ccpp</i>:defaults--&gt; [<i>ex</i>:HWDefault]
 |                     +--<i>ex</i>:displayWidth--&gt; "640"
 |                     +--<i>ex</i>:displayHeight-&gt; "400"
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalSoftware]
 |                     |
 |                     +--<i>rdf</i>:type-------&gt; [<i>ex</i>:SoftwarePlatform]
 |                     +--<i>ccpp</i>:defaults--&gt; [<i>ex</i>:SWDefault]
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalBrowser]
                       |
           ------------
          |
          +--<i>rdf</i>:type-------&gt; [<i>ex</i>:BrowserUA]
          +--<i>ccpp</i>:defaults--&gt; [<i>ex</i>:UADefault]
          +--<i>ex</i>:htmlVersionsSupported--&gt; { "2.0", "3.2", "4.0" }

[<i>ex</i>:HWDefault]
 |
 +--<i>rdf</i>:type----&gt; [<i>ex</i>:HardwarePlatform]
 +--<i>ex</i>:cpu------&gt; "PPC"
 +--<i>ex</i>:displayWidth--&gt; "320"
 +--<i>ex</i>:displayHeight--&gt; "200"

[<i>ex</i>:SWDefault]
 |
 +--<i>rdf</i>:type----&gt; [<i>ex</i>:SoftwarePlatform]
 +--<i>ex</i>:name-----&gt; "EPOC"
 +--<i>ex</i>:version--&gt; "2.0"
 +--<i>ex</i>:vendor---&gt; "Symbian"

[<i>ex</i>:UADefault]
 |
 +--<i>rdf</i>:type----&gt; [<i>ex</i>:BrowserUA]
 +--<i>ex</i>:name-----&gt; "Mozilla"
 +--<i>ex</i>:version--&gt; "5.0"
 +--<i>ex</i>:vendor---&gt; "Symbian"
 +--<i>ex</i>:htmlVersionsSupported--&gt; { "3.2", "4.0" }</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>If a component referenced by <code><i>ccpp</i>:defaults</code> contains an
attribute that is not present on the referencing profile component, then the
effect is as if the attribute value in the default component is applied
directly to the profile component. For example the profile in Figure 3-2a
should be interpreted as describing the same capabilities as shown in Figure
3-2b.</p>

<table summary="Figure 3-2b" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 3-2b: Resolving a CC/PP profile using
  defaults</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[<i>ex</i>:MyProfile]
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalHardware]
 |                     |
 |                     +--<i>rdf</i>:type-------&gt; [<i>ex</i>:HardwarePlatform]
 |                     +--<i>ex</i>:displayWidth--&gt; "640"
 |                     +--<i>ex</i>:displayHeight-&gt; "400"
 |                     +--<i>ex</i>:cpu------&gt; "PPC"
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalSoftware]
 |                     |
 |                     +--<i>rdf</i>:type-------&gt; [<i>ex</i>:SoftwarePlatform]
 |                     +--<i>ex</i>:name-----&gt; "EPOC"
 |                     +--<i>ex</i>:version--&gt; "2.0"
 |                     +--<i>ex</i>:vendor---&gt; "Symbian"
 |
 +--<i>ccpp</i>:component--&gt; [<i>ex</i>:TerminalBrowser]
                       |
           ------------
          |
          +--<i>rdf</i>:type-------&gt; [<i>ex</i>:BrowserUA]
          +--<i>ex</i>:htmlVersionsSupported--&gt; { "2.0", "3.2", "4.0" }
          +--<i>ex</i>:name-----&gt; "Mozilla"
          +--<i>ex</i>:version--&gt; "5.0"
          +--<i>ex</i>:vendor---&gt; "Symbian"</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>And here is the corresponding XML serialization, with the default resource
descriptions coded inline in the client profile description. Note that this
example uses a default namespace for RDF elements, but still must use
explicit namespace prefixes for RDF attributes.</p>

<table summary="Figure 3-2c" border="1" width="0%" bgcolor="#CCFFCC">
  <caption align="bottom">Figure 3-2c: CC/PP profile using inline defaults,
  in XML</caption>
  <tbody>
    <tr>
      <td><pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
         xmlns:prf="http://example.com/Schema#"&gt;

  &lt;rdf:Description rdf:about="http://example.com/MyProfile"&gt;
    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/TerminalHardware"&gt;
        &lt;rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/&gt;
        &lt;ccpp:defaults&gt;
          &lt;rdf:Description rdf:about="http://example.com/HWDefault"&gt;
            &lt;rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/&gt;
            &lt;prf:cpu&gt;PPC&lt;/prf:cpu&gt;
            &lt;prf:displayWidth&gt;320&lt;/prf:displayWidth&gt;
            &lt;prf:displayHeight&gt;200&lt;/prf:displayHeight&gt;
          &lt;/rdf:Description&gt;
        &lt;/ccpp:defaults&gt;
        &lt;prf:displayHeight&gt;640&lt;/prf:displayHeight&gt;
        &lt;prf:displayWidth&gt;400&lt;/prf:displayWidth&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/TerminalSoftware"&gt;
        &lt;rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform" /&gt;
        &lt;ccpp:defaults&gt;
          &lt;rdf:Description rdf:about="http://example.com/SWDefault"&gt;
            &lt;rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform"/&gt;
            &lt;prf:name&gt;EPOC&lt;/prf:name&gt;
            &lt;prf:vendor&gt;Symbian&lt;/prf:vendor&gt;
            &lt;prf:version&gt;2.0&lt;/prf:version&gt;
          &lt;/rdf:Description&gt;
        &lt;/ccpp:defaults&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/Browser"&gt;
        &lt;rdf:type rdf:resource="http://example.com/Schema#BrowserUA" /&gt;
        &lt;ccpp:defaults&gt;
          &lt;rdf:Description rdf:about="http://example.com/UADefault"&gt;
            &lt;rdf:type rdf:resource="http://example.com/Schema#BrowserUA"/&gt;
            &lt;prf:name&gt;Mozilla&lt;/prf:name&gt;
            &lt;prf:vendor&gt;Symbian&lt;/prf:vendor&gt;
            &lt;prf:version&gt;5.0&lt;/prf:version&gt;
            &lt;prf:htmlVersionsSupported&gt;
              &lt;rdf:Bag&gt;
                &lt;rdf:li&gt;3.2&lt;/rdf:li&gt;
                &lt;rdf:li&gt;4.0&lt;/rdf:li&gt;
              &lt;/rdf:Bag&gt;
            &lt;/prf:htmlVersionsSupported&gt;
          &lt;/rdf:Description&gt;
        &lt;/ccpp:defaults&gt;
        &lt;prf:htmlVersionsSupported&gt;
          &lt;rdf:Bag&gt;
            &lt;rdf:li&gt;2.0&lt;/rdf:li&gt;
            &lt;rdf:li&gt;3.2&lt;/rdf:li&gt;
            &lt;rdf:li&gt;4.0&lt;/rdf:li&gt;
          &lt;/rdf:Bag&gt;
        &lt;/prf:htmlVersionsSupported&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>Inline defaults are logically equivalent to defaults contained in an
external referenced document, and such external documents would be a normal
way of providing default values. The following is the XML serialization of
the same profile with references to externally defined defaults:</p>

<table summary="Figure 3-3" border="1" width="0%" bgcolor="#CCFFCC">
  <caption align="bottom">Figure 3-3: CC/PP profile referencing externally
  defined defaults, in XML</caption>
  <tbody>
    <tr>
      <td><pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
         xmlns:prf="http://example.com/Schema#"&gt;

  &lt;rdf:Description rdf:about="http://example.com/MyProfile"&gt;
    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/TerminalHardware"&gt;
        &lt;rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/&gt;
        &lt;ccpp:defaults rdf:resource="http://example.com/HWDefault"/&gt;
        &lt;prf:displayWidth&gt;640&lt;/prf:displayWidth&gt;
        &lt;prf:displayHeight&gt;400&lt;/prf:displayHeight&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/TerminalSoftware"&gt;
        &lt;rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform" /&gt;
        &lt;ccpp:defaults rdf:resource="http://example.com/SWDefault"/&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/Browser"&gt;
        &lt;rdf:type rdf:resource="http://example.com/Schema#BrowserUA" /&gt;
        &lt;ccpp:defaults rdf:resource="http://example.com/UADefault"/&gt;
        &lt;prf:htmlVersionsSupported&gt;
          &lt;rdf:Bag&gt;
            &lt;rdf:li&gt;2.0&lt;/rdf:li&gt;
            &lt;rdf:li&gt;3.2&lt;/rdf:li&gt;
            &lt;rdf:li&gt;4.0&lt;/rdf:li&gt;
          &lt;/rdf:Bag&gt;
        &lt;/prf:htmlVersionsSupported&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>Each external defaults resource is a separate RDF document referenced by a
URI.</p>

<blockquote>
  <p><em><b>NOTE</b>:</em> A default document uses a
  <code>&lt;<i>rdf</i>:Description&gt;</code> element as its root node. The
  <code>&lt;<i>rdf</i>:Description&gt;</code> is named using an
  <code><i>rdf</i>:about</code> whose value is a URI. This URI MUST
  correspond to the value of the <code><i>rdf</i>:resource</code> XML
  attribute in the <code>&lt;<i>ccpp</i>:defaults&gt;</code> element in the
  referencing document. (The default component does not need to be identified
  when it occurs inline, as in the first example above.) In the examples of
  default documents below, the URLs of the external default values documents
  are used. However the default resource URI does not have to be the document
  URL, as long as the URI is uniquely identified, the same URI is used in
  both the source document and the external default values document, and
  there is some way for the processing software to locate and retrieve the
  document containing the default resource.</p>
</blockquote>

<p>Examples of default documents referenced by the previous example are as
follows:</p>

<table summary="Figure 3-4" border="1" width="0%" bgcolor="#CCFFCC"
cellpadding="3">
  <caption align="bottom">Figure 3-4: External HardwarePlatform default
  values</caption>
  <tbody>
    <tr>
      <td><b>Document: http://example.com/HWDefault</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://example.com/Schema#"&gt;
   &lt;rdf:Description rdf:about="http://example.com/HWDefault"&gt;
     &lt;rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/&gt;
     &lt;prf:cpu&gt;PPC&lt;/prf:cpu&gt;
     &lt;prf:displayWidth&gt;320&lt;/prf:displayWidth&gt;
     &lt;prf:displayHeight&gt;200&lt;/prf:displayHeight&gt;
   &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>&nbsp;</p>

<table summary="Figure 3-5" border="1" width="0%" bgcolor="#CCFFCC"
cellpadding="3">
  <caption align="bottom">Figure 3-5: External SoftwarePlatform default
  values</caption>
  <tbody>
    <tr>
      <td><b>Document: http://example.com/SWDefault</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://example.com/Schema#"&gt;
   &lt;rdf:Description rdf:about="http://example.com/SWDefault"&gt;
     &lt;rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform"/&gt;
     &lt;prf:name&gt;EPOC&lt;/prf:name&gt;
     &lt;prf:vendor&gt;Symbian&lt;/prf:vendor&gt;
     &lt;prf:version&gt;2.0&lt;/prf:version&gt;
   &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>&nbsp;</p>

<table summary="Figure 3-6" border="1" width="0%" bgcolor="#CCFFCC"
cellpadding="3">
  <caption align="bottom">Figure 3-6: External BrowseUA default
  values</caption>
  <tbody>
    <tr>
      <td><b>Document: http://example.com/UADefault</b>
        <pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://example.com/Schema#"&gt;
  &lt;rdf:Description rdf:about="http://example.com/UADefault"&gt;
    &lt;rdf:type rdf:resource="http://example.com/Schema#BrowserUA"/&gt;
    &lt;prf:name&gt;Mozilla&lt;/prf:name&gt;
    &lt;prf:vendor&gt;Symbian&lt;/prf:vendor&gt;
    &lt;prf:version&gt;5.0&lt;/prf:version&gt;
    &lt;prf:htmlVersionsSupported&gt;
      &lt;rdf:Bag&gt;
        &lt;rdf:li&gt;3.2&lt;/rdf:li&gt;
        &lt;rdf:li&gt;4.0&lt;/rdf:li&gt;
      &lt;/rdf:Bag&gt;
    &lt;/prf:htmlVersionsSupported&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<h3><a name="DistinguishStructAttrib"></a>3.4 Distinguishing profile
structure from attributes</h3>

<p>CC/PP uses namespaces to distinguish the vocabulary associated with the
structure (e.g. <code><i>ccpp</i>:component</code>) from vocabularies
associated with applications (e.g. TerminalHardware, display).</p>

<p>In this example we use the namespace
"<code>http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#</code>",
associated with prefix "<code>prf:</code>", to describe properties that are
not defined in the CC/PP or RDF namespaces:</p>

<table summary="Figure 3-7" border="1" width="0%" bgcolor="#CCFFCC">
  <caption align="bottom">Figure 3-7: XML serialization of CC/PP profile,
  with namespaces</caption>
  <tbody>
    <tr>
      <td><pre>&lt;?xml version="1.0"?&gt;
&lt;rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp-schema#"
         xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#"&gt;

  &lt;rdf:Description rdf:about="http://example.com/MyProfile"&gt;
    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/TerminalHardware"&gt;
        &lt;rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#HardwarePlatform" /&gt;
        &lt;prf:CPU&gt;PPC&lt;/prf:CPU&gt;
        &lt;prf:ScreenSize&gt;320x200&lt;/prf:ScreenSize&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/TerminalSoftware"&gt;
        &lt;rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#SoftwarePlatform" /&gt;
        &lt;prf:OSName&gt;EPOC&lt;/prf:OSName&gt;
        &lt;prf:OSVendor&gt;Symbian&lt;/prf:OSVendor&gt;
        &lt;prf:OSVersion&gt;2.0&lt;/prf:OSVersion&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;

    &lt;ccpp:component&gt;
      &lt;rdf:Description rdf:about="http://example.com/Browser"&gt;
        &lt;rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#BrowserUA" /&gt;
        &lt;prf:BrowserName&gt;Mozilla&lt;/prf:BrowserName&gt;
        &lt;prf:BrowserVersion&gt;5.0&lt;/prf:BrowserVersion&gt;
        &lt;prf:HtmlVersion&gt;
          &lt;rdf:Bag&gt;
            &lt;rdf:li&gt;3.2&lt;/rdf:li&gt;
            &lt;rdf:li&gt;4.0&lt;/rdf:li&gt;
          &lt;/rdf:Bag&gt;
        &lt;/prf:HtmlVersion&gt;
      &lt;/rdf:Description&gt;
    &lt;/ccpp:component&gt;
  &lt;/rdf:Description&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>All RDF resources that relate to the overall structure of CC/PP are
defined in the <i><code>ccpp</code></i><code>:</code> namespace, and have
associated schema properties that allow them to be distinguished from
attribute vocabulary or other RDF statements by a schema-aware processor.</p>

<h3><a name="RDFUsage"></a>3.5 Notes on RDF usage</h3>

<p>This specification uses "<code>rdf:about</code>" to specify the URIs of
resources in examples. This was a deliberate choice to ensure that such URIs
are absolutely and unambiguously specified. This is also different to UAProf,
which uses both "<code>rdf:about</code>" and "<code>rdf:ID</code>".</p>

<p>CC/PP allows "<code>rdf:ID</code>" attributes or "<code>rdf:about</code>"
attributes. However, the values of "<code>rdf:ID</code>" attributes represent
URIs which are relative to the base URI of the document <a
href="#34">[RDFFRAGMENT]</a>. When a document is moved to another location on
the web the meaning of the value of an "<code>rdf:ID</code>" attribute
changes. The meaning is undefined when the RDF is contained in a document
with no base URI, e.g. when encapsulated in a message. The RDFCore WG have a
Working Draft <a href="#36">[RDFXML]</a> that proposes that RDF should
support "<code>xml:base</code>" attributes. If this addition to RDF achieves
recommendation status, then it would be appropriate to use
"<code>rdf:ID</code>" attributes in conjunction with an
"<code>xml:base</code>" attribute instead of "<code>rdf:about</code>"
attributes. For now we recommend that CC/PP profiles SHOULD use
"<code>rdf:about</code>" and that the URIs of resources are fully
specified.</p>

<p>The component resources in a profile are instances of components
identified in the corresponding schema, which in turn MUST be subclasses of
<i><code>ccpp</code></i><code>:Component</code>. They may usefully be
identified as such, by means of the <i><code>rdf</code></i><code>:type</code>
property whose value matches the name of the component type in the schema.
(Sometimes this type indication MUST be present: see <a
href="#ProfileComponents">section 3.1, Components</a>.)</p>

<h3><a name="xtocid-58647528">3.6 RDF graph composition</a></h3>

<p>The RDF statements that make up an RDF graph do not necessarily occur in a
single document. For CC/PP, the profile delivered may contain references to
RDF subgraphs that are transferred separately, or are retrieved from
designated Web resources.</p>

<p>When an external sub-graph is referenced in this way, the effect is
equivalent to taking the sets of RDF statement "triples" described by the
referencing document and the referenced document, and constructing a new
document that describes the union of these sets. (<i><b>NOTE:</b></i>
implementations are <strong>not</strong> required to actually construct such
a document, just to interpret the RDF statements as they would from a single
document.)</p>

<p>This composition of multiple RDF documents presumes that the content of
the referenced document is trusted to accurately represent the capabilities
that are presented to the sender of some resource data. Accordingly, such
composition is restricted to documents describing resources referenced by
properties whose intended interpretation embodies such a notion of trust;
<i>viz.</i> <code><i>ccpp</i>:defaults</code>.</p>

<h2><a name="AttributeVocabularies"></a>4. Attribute vocabularies</h2>

<h3><a name="AttributeData"></a>4.1 Attribute data</h3>

<p>This section describes the basic data types and data structuring options
that are available for the values associated with a CCPP attribute.</p>

<p>All CC/PP attributes should be defined with values that can be treated as
one of the simple or complex data types discussed later. Support for the
described formats for attribute values is RECOMMENDED; this specification
does not prohibit the use of other valid RDF forms, but provides no guidance
for their interpretation. (See also section <a
href="#ScopeOfDocument">1.1</a> and <a href="#Appendix_F">Appendix F</a>.)</p>

<h4><a name="SimpleAttribute">4.1.1 Simple CC/PP attribute data</a></h4>

<p>All simple CC/PP attribute values are represented as RDF plain literal
values. In RDF/XML these may appear as character sequences either in XML
elements or as XML attributes.</p>

<p>The acceptable plain literal values for an attribute may be constrained to
the lexical space associated with a specific application data type. This
section introduces some specific data types that may be associated with
simple CC/PP attributes.</p>

<p>Base CC/PP usage defined here leaves any further interpretation of the
values used to the processing application. Future versions of CC/PP may
introduce additional structures that provide for standardized matching of
client profiles with other resource metadata. To allow such developments, and
to ease interworking with IETF media feature descriptions, it is RECOMMENDED
that any simple attribute values should be defined in terms of one of the
data types described below.</p>

<p>All attribute values are ultimately sequences of UCS (Unicode) characters.
It is assumed that character coding issues in specific serializations of the
RDF data are defined by the enclosing XML representation.</p>

<blockquote>
  <p><i><b>NOTE</b></i>: Attribute comparison is beyond the scope of this
  document, as are specific mechanisms for determining the simple type
  corresponding to a given attribute value. Applications are presumed to know
  how to deal with any CC/PP attribute that they handle.</p>
</blockquote>

<p>Where given, formal syntax expressions use the notation presented in
Section 6 of the XML specification <a href="#1">[XML]</a>.</p>

<h5><a name="xtocid-33666539">4.1.1.1 Strings</a></h5>

<p>The data type of a CC/PP attribute value may be defined to be a case
sensitive text string.</p>

<p>The RDF literal value is constrained to the lexical space defined in the
"string" XML schema datatype <a href="#14">[XMLSCHEMA-2]</a>. Any 'lang' tag
is ignored.</p>

<p>In general, such values may be compared for equality or inequality. When
comparing text values, every character must match exactly for equality to be
declared.</p>

<p>Some examples:</p>
<ul>
  <li>Browser name: "Mozilla"</li>
  <li>Browser version: "5.0"</li>
</ul>

<h5><a name="xtocid-33666543">4.1.1.2 Integer numbers</a></h5>

<p>The data type of a CC/PP attribute value may be defined to be an integer
number.</p>

<p>The RDF literal value is constrained to the lexical space defined in the
"int" XML schema datatype <a href="#14">[XMLSCHEMA-2]</a>. Any 'lang' tag is
ignored.</p>

<p>Integer numbers may be positive, zero or negative. They are represented by
a string containing a sequence of decimal digits, optionally preceded by a
'<tt>+</tt>' or '<tt>-</tt>' sign. Leading zeros are permitted and are
ignored. The number value is always interpreted as decimal (radix 10). It is
RECOMMENDED that implementations generate and support integer values in the
range -2147483648 to +2147483647, or -(2^31) to (2^31-1); i.e. integers whose
absolute value can be expressed as a 31-bit unsigned binary number.</p>

<table summary="Figure 4-2" border="1" cellspacing="2" cellpadding="2"
width="44%">
  <caption align="bottom">Figure 4-2: Syntax for integer numbers</caption>
  <tbody>
    <tr bgcolor="#CCCCFF">
      <td width="100%"><pre>Signed-integer ::= ( '+' | '-' )? Unsigned-integer


Unsigned-integer ::= Digit (Digit)*</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>Some examples:</p>
<ul>
  <li>0</li>
  <li>1</li>
  <li>+0768</li>
  <li>-256
    <p><b><i>NOTE</i></b>: The choice of RECOMMENDED number range support was
    based on support from Java and other programming languages widely used
    for the Web.</p>
  </li>
</ul>

<h5><a name="xtocid-33666544">4.1.1.3 Rational numbers</a></h5>

<p>The data type of a CC/PP attribute value may be defined to be a rational
number.</p>

<p>In other words, the RDF literal value is constrained to the lexical space
defined below. Any 'lang' tag is ignored.</p>

<p>A rational number is expressed as a ratio of two integer numbers. Two
positive integers are separated by a '<tt>/</tt>', and optionally preceded by
a '<tt>+</tt>' or '<tt>-</tt>' sign.</p>

<p>It is RECOMMENDED that implementations generate and support numerators of
a rational number (the first number, before the '<tt>/</tt>') in the range 0
to 2147483647 (2^31-1), and denominators (after the '<tt>/</tt>') in the
range 1 to 2147483647.</p>

<table summary="Figure 4-3" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 4-3: Syntax for rational numbers</caption>
  <tbody>
    <tr bgcolor="#CCCCFF">
      <td><pre>Rational-number ::= Signed-integer ( '/' Unsigned-integer )?</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>If the denominator is omitted, a value '<tt>1</tt>' is assumed; i.e. treat
value as an Integer.</p>

<p>Some examples:</p>
<ul>
  <li>1/2</li>
  <li>768/1024</li>
  <li>-254/100</li>
  <li>+2000/65536</li>
</ul>

<blockquote>
  <p><b><i>NOTE</i></b>: The rational number schema described above may be
  defined in XML-Schema <a href="#12">[XMLSCHEMA-0]</a> as follows:</p>

  <table summary="Figure 4-4" border="1" width="0%">
    <caption align="bottom">Figure 4-4: Possible XML-Schema for rational
    numbers</caption>
    <tbody>
      <tr bgcolor="#CCFFCC">
        <td><pre>&lt;xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030728/"&gt;
    &lt;xs:simpleType name="rational"&gt;
      &lt;xs:annotation&gt;
        &lt;xs:documentation&gt;
          The canonical lexical representation of any value 
          will be the form of the value reduced to its lowest 
          common denominator, and with '1' in the denominator 
          if applicable.
        &lt;/xs:documentation&gt;
      &lt;/xs:annotation&gt;
    &lt;xs:restriction base="xs:string"&gt;
      &lt;xs:pattern value="[-+]?[0-9]+(/0*[1-9][0-9]*)?"/&gt;
    &lt;/xs:restriction&gt;
  &lt;/xs:simpleType&gt;
&lt;/xs:schema&gt;</pre>
        </td>
      </tr>
    </tbody>
  </table>

  <p>Note that while the pattern above provides a lexical definition, it does
  so imperfectly: it strictly disallows any whitespace at all. Further, the
  simple type definition above does not define a numeric value space;
  ordering, equality, and implied support for arithmetic operations are not
  defined as some users of the type might expect -- processors need only
  recognize the definition as a string. Because of these deficiencies, use of
  rational numbers as defined here may be harmful to interoperability. (The
  XML-Schema Working Group may define a workable rational data type in the
  future.)</p>
</blockquote>

<h4><a name="ComplexAttribute"></a>4.1.2 Complex CC/PP attribute data</h4>
In addition to the simple values described above, a CC/PP attribute may have
a complex value expressed in the form of a resource with its own collection
of RDF properties and associated values. Specific data types represented in
this way are:
<ul>
  <li>Set of values</li>
  <li>Sequence of values</li>
</ul>

<p>A profile MUST NOT have multiple occurrences of a single attribute within
a single component. CC/PP attributes that need to have multiple values should
use sets or sequences. Other complex CC/PP attribute values may be
represented by arbitrary RDF resources. A definition of the interpretation of
such values is beyond the scope of this specification.</p>

<h5><a name="4.1.2.1">4.1.2.1 Set of values</a></h5>
A set consists of zero, one or more values, all different and whose order is
not significant.

<p>Set values are useful for representing certain types of device
characteristics; e.g. the range of typefaces that can be supported by a
client, or the HTML versions supported by a browser.</p>

<p>A set is represented as an '<tt><i>rdf</i>:Bag</tt>', with each member of
the set corresponding to a property of that resource named
'<tt><i>rdf</i>:_1</tt>', '<tt><i>rdf</i>:_2</tt>', etc. This construct is
described in section 3 of the RDF Model and Syntax specification <a
href="#3">[RDF]</a>.</p>

<table summary="Figure 4-4" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 4-4: RDF representation of set values in
  CC/PP</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[(Client-resource)]
  +--(attributeName)--&gt; [&lt;rdf:Bag&gt;]
                          +--rdf:_1--&gt; (set-member-value-1)
                          +--rdf:_2--&gt; (set-member-value-2)
                          :
                          +--rdf:_n--&gt; (set-member-value-n)</pre>
      </td>
    </tr>
  </tbody>
</table>

<blockquote>
  <p><strong><em>NOTE</em></strong><b>:</b> The '<tt>rdf:Bag</tt>' construct
  does not require that every contained value be unique. A set cannot contain
  duplicate values, so every property of an '<tt>rdf:Bag</tt>' used to
  represent a set must have a distinct value.</p>
</blockquote>

<p>There is a clear distinction drawn between an attribute that has a single
value, and an attribute whose value is a set with zero, one or more
elements:</p>

<table summary="Figure 4-5" border="1" cellspacing="2" cellpadding="2"
width="55%">
  <caption align="bottom">Figure 4-5: Attribute with set value containing a
  single member</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[(Client-resource)]
  +--(attributeName)--&gt; [&lt;rdf:Bag&gt;] --rdf:_1--&gt; (set-member-value)</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>Compare the above attribute value, which is a set containing one element,
with the following, which is a simple value:</p>

<table summary="Figure 4-6" border="1" cellspacing="2" cellpadding="2"
width="55%">
  <caption align="bottom">Figure 4-6: Attribute with a simple value</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[(Client-resource)]
  +--(attributeName)--&gt; (attribute-value)</pre>
      </td>
    </tr>
  </tbody>
</table>

<h5><a name="4.1.2.2">4.1.2.2 Sequence of values</a></h5>
A sequence consists of zero, one or more values, whose order is significant
in some way.

<p>Sequence values are useful for a range of client features that may be
ordered or ranked in some way; e.g. a list of preferences in some order of
preference. This specification does not define the significance of the
ordering of values. A vocabulary that defines a sequence-valued CC/PP
attribute should also define the significance of the ordering of within the
sequence.</p>

<p>A sequence is represented as an '<tt><i>rdf</i>:Seq</tt>', with each
member of the set corresponding to a property of that resource named
'<tt><i>rdf</i>:_1</tt>', '<tt><i>rdf</i>:_2</tt>', etc. This construct is
described in section 3 of the RDF Model and Syntax specification <a
href="#3">[RDF]</a>.</p>

<table summary="Figure 4-7" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure 4-7: RDF representation of sequence values
  in CC/PP</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[(Client-resource)]
  +--(attributeName)--&gt; [&lt;rdf:Seq&gt;]
                          +--rdf:_1--&gt; (sequence-value-1)
                          +--rdf:_2--&gt; (sequence-value-2)
                          :
                          +--rdf:_n--&gt; (sequence-value-n)</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>There is a clear distinction drawn between an attribute that has a single
value, and an attribute whose value is a sequence with zero, one or more
elements:</p>

<table summary="Figure 4-8" border="1" cellspacing="2" cellpadding="2"
width="55%">
  <caption align="bottom">Figure 4-8: Attribute with sequence value
  containing a single member</caption>
  <tbody>
    <tr bgcolor="#FFFFCC">
      <td><pre>[(Client-resource)]
  +--(attributeName)--&gt; [&lt;rdf:Seq&gt;] --rdf:_1--&gt; (sequence-value)</pre>
      </td>
    </tr>
  </tbody>
</table>

<p>Compare the above attribute value, which is a sequence containing one
element, with the simple value as shown in figure 4-6 above.</p>

<h3><a name="xtocid-33666547">4.2 Attribute identifiers</a></h3>

<p>CC/PP attribute names are in the form of a URI. Any CC/PP vocabulary is
associated with an XML namespace, which combines a base URI with a local XML
element name (or XML attribute name) to yield a URI corresponding to an
attribute name. E.g. the namespace URI:</p>

<blockquote>
  <pre>http://www.w3.org/2002/11/08-ccpp-client#</pre>
</blockquote>

<p>and the core vocabulary name:</p>

<blockquote>
  <pre>type</pre>
</blockquote>

<p>are combined to yield the attribute name URI reference:</p>

<blockquote>
  <pre>http://www.w3.org/2002/11/08-ccpp-client#type</pre>
</blockquote>

<p>Anyone can define and publish a CC/PP vocabulary extension (assuming
administrative control or allocation of a URI for an XML namespace). For such
a vocabulary to be useful, it must be interpreted in the same way by
communicating entities. Thus, use of an existing extension vocabulary is
encouraged wherever possible; failing this, publication of a new vocabulary
definition containing detailed descriptions of the new CC/PP attributes.</p>

<p>Many extension vocabularies will be drawn from existing applications and
protocols; e.g. WAP UAProf, IETF media feature registrations, etc. <a
href="#Appendix_E">Appendix E</a> surveys some possible sources of additional
CC/PP vocabularies.</p>

<h3><a name="xtocid-33666548">4.3 RDF vocabulary schema</a></h3>

<p>Attribute names are defined, and associated with an XML namespace, using
an RDF schema.</p>

<p><a href="#Appendix_B">Appendix B</a> to this document contains an RDF
schema describing terms for use in CC/PP profiles. <a
href="#Appendix_C">Appendix C</a> contains an example Schema describing a
CC/PP vocabulary. <a href="#Appendix_D">Appendix D</a> contains
recommendations for creating a new vocabulary.</p>

<p>A CC/PP processor is not required to understand and process RDF Schema
definitions; it merely needs to understand enough about the CC/PP profile
structure and vocabulary used to perform its job. (A schema-aware processor
may be able to handle CC/PP profiles in other ways, or in combination with
other RDF information, but such behavior is beyond the scope of this
specification.)</p>

<h2><a name="Conformance"></a>5. Conformance</h2>

<p>This section explains how to make a <a href="#ConformanceClaims">valid
claim</a> that a product conforms to this specification. Anyone may make a
claim (e.g., vendors about their own products, third parties about those
products, journalists about products, etc.). Claims may be published anywhere
(e.g., on the Web or in product documentation). Claimants are solely
responsible for their claims. If the subject of the claim (e.g., the
software) changes after the date of the claim, the claimant is responsible
for updating the claim. Claimants are expected to modify or retract a claim
if it may be demonstrated that the claim is not valid. Claimants are
encouraged to conform to the most recent specification available.</p>

<p>There are three classes of products of CC/PP:</p>
<ol>
  <li>documents (e.g. a web resource)</li>
  <li>producers (e.g. a web client)</li>
  <li>consumers (e.g. a web server)</li>
</ol>

<h3><a name="ConformanceDocument"></a>5.1 CC/PP Document Conformance</h3>

<p>Documents may exist as resources accessible via a URL, or may be
transmitted as data in a message. A document is CC/PP conformant when it
meets the following criteria:</p>
<ol>
  <li>The document MUST be <a href="/RDF/Validator/">valid RDF</a> serialized
    in XML, and be based on one or more vocabularies derived from the RDF
    Schema in <a href="#Appendix_B">Appendix B</a>. See <a
    href="#Introduction">section 1</a>.</li>
  <li>The document MUST use valid syntax for namespace declarations. See <a
    href="#ExtensibilityNamespaces">section 2.2</a>.</li>
  <li>The profile element MUST contain one or more components. See <a
    href="#CCPPProfileStructOverview">section 2.1</a>.</li>
  <li>Each component in the profile MUST contain one or more attributes. See
    <a href="#CCPPProfileStructOverview">section 2.1</a>.</li>
  <li>The component names MAY be in rdf:about or rdf:ID attributes. See <a
    href="#ProfileComponents">section 3.1</a>.</li>
  <li>Components MUST be indicated using a ccpp:component property where the
    namespace used to qualify component is the CC/PP namespace or a UAProf
    namespace. See <a href="#ProfileComponents">section 3.1</a>.</li>
  <li>Component names, component types, and attribute names must all refer to
    different URIs within a profile. See <a href="#CCPPStructure">section
    3</a>.</li>
  <li>If a component type is given as an element name and as an rdf:type
    element, they MUST refer to the same URI. See <a
    href="#ProfileComponents">section 3.1</a>.</li>
  <li>Default references MUST be valid URLs. See <a
    href="#ProfileDefaults">section 3.3</a>.</li>
  <li>Defaults MAY be written as ccpp:defaults or ccpp:Defaults. See <a
    href="#ProfileDefaults">section 3.3</a>.</li>
  <li>Defaults MUST be indicated using a ccpp:defaults or ccpp:Defaults
    property where the namespace used to qualify defaults or Defaults is the
    CC/PP namespace or a UAProf namespace. See <a
    href="#ProfileDefaults">section 3.3</a>.</li>
  <li>Component attributes MAY contain both a default value and a directly
    applied value, with the directly applied value taking precedence. See <a
    href="#ProfileDefaults">section 3.3</a>.</li>
  <li>Components MAY contain inline defaults. See <a
    href="#ProfileDefaults">section 3.3</a>.</li>
  <li>Components MUST NOT contain both inline and referenced defaults. See <a
    href="#ProfileDefaults">section 3.3</a>.</li>
  <li>Components MAY reference a default document which does not have an
    rdf:type. See <a href="#ProfileDefaults">section 3.3</a>.</li>
  <li>Attributes MAY have sets of values (Bags). See <a
    href="#4.1.2.1">section 4.1.2.1</a>.</li>
  <li>Attributes MAY have sequences of values (Seq). See <a
    href="#4.1.2.2">section 4.1.2.2</a>.</li>
  <li>Attributes MAY have string values. See <a
    href="#xtocid-33666539">section 4.1.1.2</a>.</li>
  <li>Attributes MAY have Integer number values. See <a
    href="#xtocid-33666543">section 4.1.1.3</a>.</li>
  <li>Attributes MAY have Rational number values. See <a
    href="#xtocid-33666544">section 4.1.1.4</a>.</li>
  <li>A component MUST NOT contain more than one attribute with the same
    name. See <a href="#ProfileAttributes">section 3.2</a>.</li>
  <li>Attributes of the same name MAY be in different components. See <a
    href="#ProfileComponents">section 3.1</a>.</li>
  <li>Profiles MAY use multiple namespaces for attributes. See <a
    href="#ExtensibilityNamespaces">section 2.2</a>.<br>
  </li>
</ol>

<h3><a name="ConformanceProducer"></a>5.2 CC/PP Producer Conformance</h3>

<p>A producer is CC/PP conformant when any CC/PP profile document generated
by the producer is a CC/PP conformant document.</p>

<h3><a name="ConformanceConsumer"></a>5.3 CC/PP Consumer Conformance</h3>

<p>A consumer is CC/PP conformant when the consumer accepts any CC/PP
conformant document and extracts CC/PP information. Schema-aware processing
is not required, and therefore, support for the RDF Schema in <a
href="#Appendix_B">Appendix B</a> by CC/PP consumers is OPTIONAL (see <a
href="#xtocid-33666548">section 4.3</a>).</p>

<p>There are two categories of conformance for CC/PP consumers:</p>
<ol>
  <li><b>Conformant</b>: a CC/PP consumer can claim to be a <i>"CC/PP 1.0
    conformant consumer"</i> if it accepts any valid CC/PP profile and
    extracts information from it.</li>
  <li><b>Validating</b>: a CC/PP consumer can claim to be a <i>"CC/PP 1.0
    conformant validating consumer"</i> if it is conformant and if it rejects
    all invalid CC/PP profiles.</li>
</ol>

<div style="margin-left: 40px;">
<p><span style="font-weight: bold; font-style: italic;">NOTE</span>: A
consumer implementation may be configurable to act as either a conformant
consumer or a conformant validating consumer at different times.</p>
</div>

<h3><a name="ConformanceClaims"></a>5.4 Conformance Claims</h3>

<h4><a name="ConformanceClaimsValidity"></a>5.4.1 Validity</h4>

<p>A conformance claim is valid if it is <a
href="#ConformanceClaimsWellformed">well formed</a> and meets the appropriate
conformance criteria for the applicable product class as given above.</p>

<h4><a name="ConformanceClaimsWellformed"></a>5.4.2 Well-formed</h4>

<p>A conformance claim is well-formed if it includes the following
information:</p>
<ol>
  <li>the date of the claim</li>
  <li>the product class (document, producer, or consumer)</li>
  <li>the consumer category (conformant or conformant validating) if
    applicable</li>
  <li>the title and dated URI of this document</li>
  <li>the product name (identity), including a version, date, or other
    identifier that uniquely identifies the product</li>
</ol>

<h2><a name="Acknowledgements"></a>6. Acknowledgments</h2>

<p>This document is a distillation of many discussions of the W3C CC/PP
Working Group, with final amendments introduced by the W3C Device
Independence Working Group. The following were CC/PP Working Group members
for some or most of the period of preparation of this specification, and its
predecessors:</p>
<ul>
  <li>Mikael Nilsson, Ericsson Infotech</li>
  <li>Ulrich Kauschke, T-Mobil</li>
  <li>Ann Navarro, HTML Writers Guild</li>
  <li>Brad Topol, IBM</li>
  <li>Franklin Reynolds, Nokia</li>
  <li>Graham Klyne, Baltimore Technologies</li>
  <li>Noboru Iwayama, Fujitsu Laboratories LTD</li>
  <li>Takashi Nishigaya, Fujitsu Laboratories LTD</li>
  <li>Lalitha Surayanrayana, SBC Technology Resources</li>
  <li>Hidetaka Ohto, W3C (through March 2002) / Panasonic</li>
  <li>Simon McBride, DSTC Pty Ltd</li>
  <li>Varuni Witana, DSTC Pty Ltd</li>
  <li>Chris Woodrow, Information Architects</li>
  <li>Johan Hjelm, Ericsson</li>
  <li>Barry Briggs, Interleaf</li>
  <li>Gerd Hoelzing, SAP</li>
  <li>Ted Hardie, Equinix</li>
  <li>Serge Rigori, Sun</li>
  <li>Ted Wugofski, Phone.com</li>
  <li>Kynn Bartlett, HTML Writers Guild</li>
  <li>Sandeep Singhal, IBM</li>
  <li>Thorsten Kassing, T-Mobil</li>
  <li>Larry Masinter, Adobe</li>
</ul>

<p>During the period when the CC/PP WG was developing the specification,
useful revisions and clarifications were suggested by Yuichi Koike, Stuart
Williams, Sean Palmer and Toni Penttinen. Special thanks are due to Aaron
Swartz for a very thorough and revealing review of the first last call
draft.</p>

<p>Following the handing over of the work to the DI WG, special thanks are
also due to David Ezell (XML Schema WG), Brian McBride (RDF Core WG),
Masayasu Ishikawa (HTML WG), and Lynne Rosenthal (QA WG) for their help in
completing the specification.</p>

<p>The following members of the DI WG also provided assistance in completing
the specification: Stephane Boyera, Roger Gimson, Kazuhiro Kitagawa, Andreas
Schade.</p>

<h2><a name="xtocid-33666550">7. References</a></h2>

<h3><a name="norm_refs">7.1.</a> Normative References</h3>
<dl>
  <dt><a name="1"></a>[XML]</dt>
    <dd>Extensible Markup Language (XML) 1.0 (Second Edition); Tim Bray, Jean
      Paoli, C. M. Sperberg-McQueen, Eve Maler; World Wide Web Consortium
      Recommendation 6 October 2000: <a
      href="/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</a>
      As amended by: XML 1.0 Second Edition Specification Errata; <a
      href="/XML/xml-V10-2e-errata">http://www.w3.org/XML/xml-V10-2e-errata</a>,
      specifically <a
      href="/XML/xml-V10-2e-errata#E26">http://www.w3.org/XML/xml-V10-2e-errata#E26</a>.</dd>
  <dt><a name="2"></a>[XMLNAMESPACES]</dt>
    <dd>Namespaces in XML; Tim Bray, Dave Hollander, Andrew Layman; World
      Wide Web Consortium Recommendation 14 January 1999: <a
      href="/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a></dd>
  <dt><a name="3"></a>[RDF]</dt>
    <dd>Resource Description Framework (RDF) Model and Syntax Specification;
      Ora Lassila, Ralph Swick; World Wide Web Consortium Recommendation 22
      February 1999: <a
      href="/TR/1999/REC-rdf-syntax-19990222/">http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/</a></dd>
  <dt><a name="4"></a>[RDFSCHEMA]</dt>
    <dd>Resource Description Framework (RDF) Schema Specification; Dan
      Brickley, R. V. Guha; World Wide Web Consortium Candidate
      Recommendation 27 March 2000: <a
      href="/TR/2000/CR-rdf-schema-20000327/">http://www.w3.org/TR/2000/CR-rdf-schema-20000327/</a></dd>
  <dt><a name="36"></a>[RDFXML]</dt>
    <dd>RDF/XML Syntax Specification; Dave Beckett; World Wide Web Consortium
      Working Draft: <a
      href="/TR/2003/WD-rdf-syntax-grammar-20030123/">http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/</a></dd>
</dl>

<h3><a name="inform_refs">7.2.</a> Informative References</h3>
<dl>
  <dt><a name="5"></a>[RFC2506]</dt>
    <dd>RFC 2506: Media Feature Tag Registration Procedure; K. Holtman, A.
      Mutz, T. Hardie; IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2506.txt">ftp://ftp.isi.edu/in-notes/rfc2506.txt</a></dd>
  <dt><a name="6"></a>[RFC2533]</dt>
    <dd>RFC 2533: A Syntax for Describing Media Feature Sets; G. Klyne; IETF
      Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2533.txt">ftp://ftp.isi.edu/in-notes/rfc2533.txt</a></dd>
  <dt><a name="7"></a>[CONNEGMATCH]</dt>
    <dd>A revised media feature set matching algorithm; G. Klyne;
      Internet-Draft, work in progress: <a
      href="http://lists.w3.org/Archives/Public/www-archive/2003Apr/0047.html">
      draft-klyne-conneg-feature-match-02.txt</a></dd>
  <dt><a name="8"></a>[RFC2534]</dt>
    <dd>RFC 2534: Media Features for Display, Print, and Fax; L. Masinter, D.
      Wing, A. Mutz, K. Holtman; IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2534.txt">ftp://ftp.isi.edu/in-notes/rfc2534.txt</a></dd>
  <dt><a name="9"></a>[UAPROF]</dt>
    <dd>WAP-174: <a
      href="http://www.wapforum.org/what/technical/SPEC-UAProf-19991110.pdf">UAProf
      User Agent Profiling Specification (1999)</a> as amended by WAP-174_100
      User Agent Profiling Specification Information Note (2001) Wireless
      Application Protocol Forum available at <a
      href="http://www.wapforum.org/what/technical_1_2.htm">http://www.wapforum.org/what/technical_1_2.htm</a>
      <p>Also see WAP-248-UAProf Version 20-Oct-2001 available at <a
      href="http://www.wapforum.org/what/technical.htm">http://www.wapforum.org/what/technical.htm</a></p>
    </dd>
  <dt><a name="11"></a>[DATASTRUCTURE]</dt>
    <dd>Notes on Data Structuring; C. A. R. Hoare; in Structured Programming,
      Academic Press, 1972. ISBN 0-12-2000556-2.</dd>
  <dt><a name="12"></a>[XMLSCHEMA-0]</dt>
    <dd>XML Schema. Part 0: Primer; David C. Fallside; World Wide Web
      Consortium Recommendation 2 May 2001: <a
      href="/TR/2001/REC-xmlschema-0-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/</a></dd>
  <dt><a name="13"></a>[XMLSCHEMA-1]</dt>
    <dd>XML Schema. Part 1: Structures; Henry S. Thompson, David Beech,
      Murray Maloney, Noah Mendelsohn; World Wide Web Consortium
      Recommendation 2 May 2001: <a
      href="/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/</a></dd>
  <dt><a name="14"></a>[XMLSCHEMA-2]</dt>
    <dd>XML Schema. Part 2: Datatypes; Paul V. Biron, Ashok Malhotra; World
      Wide Web Consortium Recommendation 2 May 2001: <a
      href="/TR/2001/REC-xmlschema-2-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a></dd>
  <dt><a name="15"></a>[SEMANTICTOOLBOX]</dt>
    <dd>The Semantic Toolbox: Building Semantics on top of XML-RDF; Tim
      Berners-Lee; <a
      href="/DesignIssues/Toolbox.html">http://www.w3.org/DesignIssues/Toolbox.html</a></dd>
  <dt><a name="16"></a>[RFC2531]</dt>
    <dd>RFC 2531: Content Feature Schema for Internet Fax; G. Klyne, L.
      McIntyre; IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2531.txt">ftp://ftp.isi.edu/in-notes/rfc2531.txt</a></dd>
  <dt><a name="17"></a>[TIFF]</dt>
    <dd>TIFF (Tagged Image File Format) 6.0 Specification; Adobe Systems
      Inc.; <a
      href="http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf">http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf</a></dd>
  <dt><a name="18"></a>[RFC2301]</dt>
    <dd>RFC 2301: File Format for Internet Fax; L. McIntyre, S. Zilles, R.
      Buckley, D. Venable, G. Parsons, J. Rafferty; IETF Request for
      Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2301.txt">ftp://ftp.isi.edu/in-notes/rfc2301.txt</a></dd>
  <dt><a name="19"></a>[MULTIMEDIA]</dt>
    <dd>Multimedia Programming Interface and Data Specifications 1.0
      (contains WAVE file format); IBM Corporation and Microsoft Corporation;
      &lt;riffspec.txt&gt;</dd>
  <dt><a name="20"></a>[RFC2361]</dt>
    <dd>RFC 2361: WAVE and AVI Codec Registries; E. Fleischman; IETF Request
      for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2361.txt">ftp://ftp.isi.edu/in-notes/rfc2361.txt</a></dd>
  <dt><a name="21"></a>[MPEG]</dt>
    <dd>MPEG-4 Overview - (V.14 - Geneva Version), ISO/IEC JTC1/SC29/WG11
      N3444 Rob Koenen Overview of the MPEG-4 Standard: <a
      href="http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm"></a></dd>
  <dt><a name="22"></a>[PWG]</dt>
    <dd>Printer Working Group; <a
      href="http://www.pwg.org/">http://www.pwg.org</a></dd>
  <dt><a name="23"></a>[RFC2566]</dt>
    <dd>RFC 2566: Internet Printing Protocol/1.0: Model and Semantics; R.
      deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell; IETF Request
      for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2566.txt</a></dd>
  <dt><a name="24"></a>[SALUTATION]</dt>
    <dd>Salutation Consortium Specification; <a
      href="http://www.salutation.org/">http://www.salutation.org/</a></dd>
  <dt><a name="25"></a>[RFC2119]</dt>
    <dd>RFC 2119: Key words for use in RFCs to Indicate Requirement Levels;
      S. Bradner; IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">ftp://ftp.isi.edu/in-notes/rfc2119.txt</a>.</dd>
  <dt><a name="26"></a>[MPEG-7]</dt>
    <dd>MPEG-7 Overview (version 8.0), ISO/IEC JTC1/SC29/WG11 N3445 Jos矍.
      Mart쭥z (UPM-GTI, ES) Overview of the MPEG-7 Standard: <a
      href="http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm">http://mpeg.telecomitalialab.com/standards/mpeg-7/mpeg-7.htm</a></dd>
  <dt><a name="27"></a>[RFC2277]</dt>
    <dd>RFC 2277: IETF Policy on Character Sets and Languages; H. Alvestrand;
      IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2277.txt</a></dd>
  <dt><a name="28"></a>[RFC2396]</dt>
    <dd>RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax; T.
      Berners-Lee, R. Fielding, L. Masinter; IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2396.txt</a></dd>
  <dt><a name="29"></a>[RFC2278]</dt>
    <dd>RFC 2278: IANA Charset Registration Procedures; N. Freed, J. Postel;
      IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2278.txt</a></dd>
  <dt><a name="30"></a>[CCPPARCH]</dt>
    <dd>Composite Capabilities/Preference Profiles: Requirements and
      Architecture; Mikael Nilsson, Johan Hjelm, Hidetaka Ohto; World Wide
      Web Consortium Working Draft 21 July 2000: <a
      href="/TR/2000/WD-CCPP-ra-20000721/">http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/</a></dd>
  <dt><a name="31"></a>[RFC2616]</dt>
    <dd>RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1; R. Fielding, J.
      Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee;
      IETF Request for Comments: <a
      href="ftp://ftp.isi.edu/in-notes/rfc2616.txt">ftp://ftp.isi.edu/in-notes/rfc2616.txt</a></dd>
  <dt><a name="32"></a>[CONCEPTUAL]</dt>
    <dd>Conceptual Structures: Information Processing in Mind and Machine;
      John F. Sowa; Addison Wesley, Reading MA, 1984.</dd>
  <dt><a name="33"></a>[KNOWLEDGE]</dt>
    <dd>Knowledge Representation; John F. Sowa; Brooks/Cole, 2000. ISBN:
      0-534-94965-7</dd>
  <dt><a name="34"></a>[RDFFRAGMENT]</dt>
    <dd>Re: How to address RDF fragment; Ralph R Swick; Message to World Wide
      Web Consortium RDF-comments mailing list: <a
      href="http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html">
      http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html</a>.</dd>
  <dt><a name="35"></a>[CCPPEX]</dt>
    <dd>CC/PP exchange protocol;Hidetaka Ohto, Johan Hjelm; World Wide Web
      Consortium Note 24 June 1999: <a
      href="/1999/06/NOTE-CCPPexchange-19990624">http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624</a></dd>
  <dt><a name="37"></a>[WAI]</dt>
    <dd>Web Content Accessibility Guidelines 2.0; Wendy Chisholm, Jason
      White, Gregg Vanderheiden; World Wide Web Consortium Working Draft 22
      August 2002: <a
      href="/TR/2002/WD-WCAG20-20020822/">http://www.w3.org/TR/2002/WD-WCAG20-20020822/</a></dd>
</dl>
<dl>
  <dt><a name="rdfprimer"></a>[RDFPRIMER]</dt>
    <dd>RDF Primer; Frank Manola, Eric Miller; World Wide Web Consortium
      Working Draft 23 January 2003: <a
      href="/TR/2003/WD-rdf-primer-20030123/">http://www.w3.org/TR/2003/WD-rdf-primer-20030123/</a></dd>
</dl>

<h2><a name="Appendix_A"></a>Appendix A: Terminology and abbreviations</h2>

<h3><a name="Terminology"></a>A.1 Terminology</h3>

<p>This appendix is INFORMATIVE.</p>
<dl>
  <dt>Attribute, or CC/PP attribute</dt>
    <dd>A CC/PP attribute refers to the data elements describing the profile
      and is denoted as an RDF property. Each CC/PP attribute is associated
      with a value or a list of values or am RDF resource.
      <b><i>NOTE</i></b>: this is quite distinct from an XML attribute;
      except where the meaning obvious in context, the term "CC/PP attribute"
      is generally used to emphasize this usage.</dd>
  <dt>CC/PP Processor</dt>
    <dd>A CC/PP processor transforms a CC/PP document from its RDF format
      into some other format. A CC/PP processor understands CC/PP syntax and
      structure, including "defaults", but it does not understand application
      semantics associated with CC/PP attributes of CC/PP components.</dd>
  <dt>CC/PP Repository</dt>
    <dd>A server that stores the user agent profile or profile segments
      persistently in a form that may be referenced by and incorporated into
      a profile. A CC/PP repository is typically a Web server that provides
      CC/PP profiles or profile segments in response to HTTP requests.</dd>
  <dt>Cacheable</dt>
    <dd>A data resource is said to be "cacheable" if the data resource
      contains a property that allows a server to determine whether the
      cached resource matches a request for a similar resource.</dd>
  <dt>Cache</dt>
    <dd>A storage area used by a server or proxy to store data resources that
      have been retrieved or created in response to a request. When a new
      request for a "cached" data resource is received, the server or proxy
      can respond with the cached version instead of retrieving or creating a
      new copy.</dd>
  <dt>Capability</dt>
    <dd>An attribute of a sender or receiver (often the receiver) which
      indicates an ability to generate or process a particular type of
      message content. See also "CC/PP Attributes".</dd>
  <dt>Client</dt>
    <dd>An entity that is the original compositor of a CC/PP profile.</dd>
  <dt>Confidentiality</dt>
    <dd>Protecting the content of a message from unauthorized disclosure.</dd>
  <dt>Content Generation</dt>
    <dd>For the purpose of this specification, "content generation" refers to
      generating content appropriate to the user agent profile of the request
      by using the user agent profile as input to a dynamic content
      generation engine. The XSL and style sheets of the document are used to
      tailor the document to the user agent profile of the request.</dd>
  <dt>Content Negotiation</dt>
    <dd>The mechanism for selecting the appropriate representation when
      servicing a request. The representation of entities in any response can
      be negotiated (including error responses).</dd>
  <dt>Content Selection</dt>
    <dd>For the purpose of this specification, "content selection" refers to
      selecting an appropriate document from a list of possible choices or
      variants by matching the document profile with the user agent profile
      of the request.</dd>
  <dt>Content Provider</dt>
    <dd>A server that originates content in response to a request.</dd>
  <dt>Data Resource</dt>
    <dd>A data object that can be transferred across a network. Data
      resources may be available in multiple representations (e.g. multiple
      languages, data formats, size, resolutions) or vary in other ways.</dd>
  <dt>Document</dt>
    <dd>For the purpose of this specification, "document" refers to content
      supplied in response to a request. Using this definition, a "document"
      may be a collection of smaller "documents", which in turn is a part of
      a greater "document".</dd>
  <dt>Document Profile</dt>
    <dd>Document profiles offer a means to characterize the features
      appropriate to given categories of user agents. For instance, one
      profile might include support for style sheets, vector graphics and
      scripting, while another might be restricted to the tags in HTML 3.2.
      Document profiles can be used by servers to select between document
      variants developed for different user agent categories. They can be
      used to determine what transformations to apply when such variants are
      not available. Content developers can use document profiles to ensure
      that their Web sites will be rendered as intended.</dd>
  <dt>Dynamic Content</dt>
    <dd>Content that is generated in response to a request. This may be used
      for content that depends on changing environmental factors such as time
      (e.g., stock quotes) or place (e.g., nearby gas stations)</dd>
  <dt>Feature</dt>
    <dd>Functional property of a device or entity.</dd>
  <dt>Gateway</dt>
    <dd>Software that is capable of bridging disparate network protocols. For
      the purposes of this specification, "gateway" refers to protocol
      bridging functionality, which may exist in a stand-alone gateway or may
      be co-located with a proxy or origin server.</dd>
  <dt>Hint</dt>
    <dd>A suggestion or preference for a particular option. While this option
      is strongly recommended, its use is not required.</dd>
  <dt>Machine Understandable</dt>
    <dd>Data that is described with tags that associate a meaning to the data
      (i.e., an "author" tag would describe the author of the document),
      allowing data to be searched or combined and not just displayed.</dd>
  <dt>Namespace</dt>
    <dd>A qualifier added to an XML tag to ensure uniqueness among XML
      elements.</dd>
  <dt>Negotiate Content</dt>
    <dd>Message content that has been selected by content negotiation.</dd>
  <dt>Negotiation Metadata</dt>
    <dd>Information which is exchanged between the sender and the receiver of
      a message by content negotiation in order to determine the variant
      which should be transferred.</dd>
  <dt>Non-variant Content</dt>
    <dd>When the form/format of the content being sent does not depend on
      receiver's capabilities and/or preferences</dd>
  <dt>Origin Server</dt>
    <dd>Software that can respond to requests by delivering appropriate
      content or error messages. The origin server may receive requests via
      either WSP or HTTP. Application programs executing on the origin server
      deliver content that is tailored in accordance with the CC/PP that can
      be found within the provided Profile. For the purpose of this
      specification, "origin server" refers to content generation
      capabilities, which may physically exist in a stand-alone Web server or
      may be co-located with a proxy or gateway.</dd>
  <dt>Preference</dt>
    <dd>An attribute of a sender or receiver (often the receiver) which
      indicates a preference to generate or process one particular type of
      message content over another, even if both are possible.</dd>
  <dt>Privacy</dt>
    <dd>Preventing the unintended or unauthorized disclosure of information
      about a person. Such information may be contained within a message, but
      may also be inferred from patterns of communication; e.g. when
      communications happen, the types of resource accessed, the parties with
      whom communication occurs, etc.</dd>
  <dt>Profile</dt>
    <dd>An instance of the schema that describe capabilities for a specific
      device and network. A profile need not have all the attributes
      identified in the vocabulary/schema.</dd>
  <dt>Proxy</dt>
    <dd>Software that receives HTTP requests and forwards that request toward
      the origin server (possibly by way of an upstream proxy) using HTTP.
      The proxy receives the response from the origin server and forwards it
      to the requesting client. In providing its forwarding functions, the
      proxy may modify either the request or response or provide other
      value-added functions. For the purposes of this specification, "proxy"
      refers to request/response forwarding functionality, which may exist in
      a stand-alone HTTP proxy or may be co-located with a gateway or origin
      server.</dd>
  <dt>RDF Resource</dt>
    <dd>An object or element being described by RDF expressions is a
      resource. An RDF resource is typically identified by a URI.</dd>
  <dt>Receiver</dt>
    <dd>A system component (device or program) which receives a message.</dd>
  <dt>Schema, RDF Schema</dt>
    <dd>An RDF Schema denotes resources which constitute the particular
      unchanging versions of an RDF vocabulary at any point in time. It is
      used to provide information (such as organization and relationship)
      about the interpretation of the statements in an RDF data model. It
      does not include the values associated with the attributes.</dd>
  <dt>Security</dt>
    <dd>Describes a set of procedures applied to data communications to
      ensure that information is transferred exactly as the sender and
      receiver intend, and in no other way. Security generally breaks down
      into Integrity, Authentication, Confidentiality and Privacy.</dd>
  <dt>Sender</dt>
    <dd>A system component (device or program) which transmits a message.</dd>
  <dt>User</dt>
    <dd>An individual or group of individuals acting as a single entity. The
      user is further qualified as an entity who uses a device to request
      content and/or resource from a server.</dd>
  <dt>User agent</dt>
    <dd>A program, such as a browser, running on the device that acts on a
      user's behalf. Users may use different user agents at different
    times.</dd>
  <dt>User agent profile</dt>
    <dd>Capabilities and preference information pertaining to the
      capabilities of the device, the operating and network environment, and
      users personal preferences for receiving content and/or resource.</dd>
  <dt>Variant</dt>
    <dd>One of several possible representations of a data resource.</dd>
  <dt>Variant Content</dt>
    <dd>When the form/format of the content being sent depends on receiver's
      capabilities and/or preferences</dd>
  <dt>Vocabulary</dt>
    <dd>A collection of attributes that adequately describe the CC/PP. A
      vocabulary is associated with a schema.</dd>
</dl>

<h3><a name="Abbreviations">A.2 Abbreviations</a></h3>

<table summary="Abbreviations">
  <tbody>
    <tr>
      <th>CC/PP</th>
      <td>Composite Capabilities/Preferences Profile</td>
    </tr>
    <tr>
      <th>CC/PPex</th>
      <td>CC/PP Exchange Protocol</td>
    </tr>
    <tr>
      <th>CONNEG</th>
      <td>Content Negotiation Working Group in the IETF</td>
    </tr>
    <tr>
      <th>ER</th>
      <td>Entity-Relationship</td>
    </tr>
    <tr>
      <th>HTML</th>
      <td>HyperText Markup Language</td>
    </tr>
    <tr>
      <th>HTTP</th>
      <td>HyperText Transfer Protocol</td>
    </tr>
    <tr>
      <th>HTTPex</th>
      <td>HTTP Extension Framework</td>
    </tr>
    <tr>
      <th>IANA</th>
      <td>Internet Assigned Numbers Authority</td>
    </tr>
    <tr>
      <th>IETF</th>
      <td>Internet Engineering Task Force</td>
    </tr>
    <tr>
      <th>IOTP</th>
      <td>Internet Open Trading Protocol</td>
    </tr>
    <tr>
      <th>LDAP</th>
      <td>Lightweight Directory Access Protocol</td>
    </tr>
    <tr>
      <th>OTA</th>
      <td>Over The Air, i.e. in the radio network</td>
    </tr>
    <tr>
      <th>RDF</th>
      <td>Resource Description Framework</td>
    </tr>
    <tr>
      <th>RFC</th>
      <td>Request For Comments</td>
    </tr>
    <tr>
      <th>TBD</th>
      <td>To Be Determined</td>
    </tr>
    <tr>
      <th>TCP/IP</th>
      <td>Transmission Control Protocol/Internet Protocol</td>
    </tr>
    <tr>
      <th>UAProf</th>
      <td>WAP User Agent Profile</td>
    </tr>
    <tr>
      <th>W3C</th>
      <td>World Wide Web Consortium</td>
    </tr>
    <tr>
      <th>WAP</th>
      <td>Wireless Application Protocol</td>
    </tr>
    <tr>
      <th>WBXML</th>
      <td>WAP Binary XML</td>
    </tr>
    <tr>
      <th>WML</th>
      <td>Wireless Markup Language</td>
    </tr>
    <tr>
      <th>WSP</th>
      <td>Wireless Session Protocol</td>
    </tr>
    <tr>
      <th>XHTML</th>
      <td>Extensible HyperText Markup Language</td>
    </tr>
    <tr>
      <th>XSL</th>
      <td>Extensible Stylesheet Language</td>
    </tr>
    <tr>
      <th>XML</th>
      <td>Extensible Markup Language</td>
    </tr>
  </tbody>
</table>

<h2><a name="Appendix_B"></a>Appendix B: RDF schema for structure</h2>

<p>This appendix is NORMATIVE, but support by CC/PP processors is
OPTIONAL.</p>

<h3><a name="xtocid-33666555">B.1 Summary of CC/PP class hierarchy</a></h3>

<table summary="Figure B-1" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure B-1: CC/PP class hierarchy</caption>
  <tbody>
    <tr bgcolor="#CCCCFF">
      <td><pre>rdfs:Resource
    ccpp:Profile            {Profile deliverable to origin server}
    ccpp:Component

rdfs:Literal
  ccpp:string               {A text value of a CC/PP attribute}
  ccpp:integer              {An integer value of a CC/PP attribute}
  ccpp:rational             {A rational number CC/PP attribute value}

rdf:Bag                     {A set value for a CC/PP attribute}
rdf:Seq                     {A sequence value for a CC/PP attribute}
   
rdf:Property
  ccpp:Property             {A property applied to a CCPP:Resource}
    ccpp:Structure          {A structural property in a CC/PP profile}
    ccpp:Attribute          {A property denoting a CC/PP attribute}</pre>
      </td>
    </tr>
  </tbody>
</table>

<h3><a name="xtocid-33666556">B.2 Summary of CC/PP properties</a></h3>

<h4><a name="xtocid-33666557">Structural properties (instances of</a>
<tt>ccpp:Structure</tt>)</h4>

<table summary="Figure B-2" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure B-2: CC/PP structural properties</caption>
  <tbody>
    <tr bgcolor="#CCCCFF">
      <td><pre>ccpp:component      Domain=ccpp:Profile,         Range=ccpp:Component
ccpp:defaults       Domain=ccpp:Component,       Range=ccpp:Component</pre>
      </td>
    </tr>
  </tbody>
</table>

<h3><a name="xtocid-33666558">B.3 RDF Schema</a></h3>

<h4><a name="xtocid-33666559">CC/PP core and class structure:</a></h4>

<p>(Schema URI: <tt><a
href="/2002/11/08-ccpp-schema">http://www.w3.org/2002/11/08-ccpp-schema</a></tt>)</p>

<table summary="Figure B-3" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure B-3: RDF schema for CC/PP classes and core
  properties</caption>
  <tbody>
    <tr bgcolor="#CCFFCC">
      <td><pre>&lt;?xml version='1.0'?&gt;

&lt;!DOCTYPE rdf:RDF [
  &lt;!ENTITY ns-rdf  'http://www.w3.org/1999/02/22-rdf-syntax-ns#'&gt;
  &lt;!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'&gt;
  &lt;!ENTITY ns-ccpp 'http://www.w3.org/2002/11/08-ccpp-schema#'&gt;
]&gt;

&lt;rdf:RDF
  xmlns:rdf  = '&amp;ns-rdf;'
  xmlns:rdfs = '&amp;ns-rdfs;'
  xmlns:ccpp = '&amp;ns-ccpp;'&gt;

&lt;!--  CC/PP class definitions --&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;Profile'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP Profile&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-rdfs;Resource'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      This class is any complete profile that can be delivered to an
      origin server or other system that generates content for a client.
    &lt;/rdfs:comment&gt;
  &lt;/rdfs:Class&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;Component'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP profile component&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-rdfs;Resource'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      A base class for any collection of CC/PP attribute values.
      A CC/PP client profile consists of one or more components,
      typically using a derived class that indicates the use of the
      component (e.g. prf:HardwarePlatform, prf:SoftwarePlatform).
    &lt;/rdfs:comment&gt;
  &lt;/rdfs:Class&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;string'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Text value&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-rdfs;Literal'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      This is the class of RDF Literals that represent CC/PP
      attribute string values.
    &lt;/rdfs:comment&gt;
    &lt;rdfs:seeAlso rdf:resource=
      'http://www.w3.org/TR/xmlschema-2/#string'/&gt;
  &lt;/rdfs:Class&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;integer'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Integer value&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-rdfs;Literal'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      This is the class of RDF Literals that represent CC/PP
      attribute integer number values.
    &lt;/rdfs:comment&gt;
    &lt;rdfs:seeAlso rdf:resource=
      'http://www.w3.org/TR/xmlschema-2/#integer'/&gt;
  &lt;/rdfs:Class&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;rational'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Rational value&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-rdfs;Literal'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      This is the class of RDF Literals that represent CC/PP
      attribute rational number values.
    &lt;/rdfs:comment&gt;
  &lt;/rdfs:Class&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;Property'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP Property&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-rdf;Property'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      ccpp:Property is the super-class for ccpp:Structure and
      ccpp:Attribute. Therefore all property arcs that are not part
      of the core RDF namespace and constitute parts of a CC/PP
      profile are defined as subclasses of ccpp:Property. This
      allows schema-validating environments with language mixing to
      isolate the CC/PP elements of an RDF graph rooted in some
      given resource from other attributes of that resource.
    &lt;/rdfs:comment&gt;
  &lt;/rdfs:Class&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;Structure'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP structural property&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-ccpp;Property'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      All properties that are structural elements of a CC/PP profile
      are defined as instances of ccpp:Structure. This allows
      structural combining elements of a profile to be distinguished
      from attributes in a schema-aware environment.
    &lt;/rdfs:comment&gt;
  &lt;/rdfs:Class&gt;

  &lt;rdfs:Class rdf:about='&amp;ns-ccpp;Attribute'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP Attribute&lt;/rdfs:label&gt;
    &lt;rdfs:subClassOf rdf:resource='&amp;ns-ccpp;Property'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      All properties that describe client capabilities or preferences
      in a CC/PP profile should be defined as instances of
      ccpp:Attribute. This allows structural combining elements
      of a profile to be distinguished from client features in a
      schema-validating environment.
    &lt;/rdfs:comment&gt;
  &lt;/rdfs:Class&gt;


&lt;!--  CC/PP structural property definitions --&gt;
&lt;!--  Basic client profile description      --&gt;

  &lt;ccpp:Structure rdf:about='&amp;ns-ccpp;component'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP component property&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Client-profile'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      Indicates a component of a top-level client profile.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Structure&gt;

  &lt;ccpp:Structure rdf:about='&amp;ns-ccpp;defaults'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP default properties&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      This property indicates a Component that contains default
      properties for some other component.  That is, any attributes
      that are not found in the subject resource but are present in
      the object resource may be incorporated from the object into
      the resulting CC/PP profile.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Structure&gt;

  &lt;ccpp:Structure rdf:about='&amp;ns-ccpp;Defaults'&gt;
    &lt;rdfs:label xml:lang="en"&gt;CC/PP default properties&lt;/rdfs:label&gt;
    &lt;rdfs:subPropertyOf rdf:resource='&amp;ns-ccpp;defaults'/&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      Same as 'defaults'.
      Defined as sub-property for backwards compatibility with UAProf

      Use of this is deprecated:  use 'defaults' instead.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Structure&gt;
&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<h2><a name="Appendix_C"></a>Appendix C: CC/PP attribute vocabulary for print
and display</h2>

<p>The appendix is OPTIONAL and INFORMATIVE.</p>

<p>Designers of CC/PP applications who need to describe such features are
encouraged to use this vocabulary rather than define new terms. This
vocabulary is based in part on work done in the IETF media feature
registration (CONNEG) Working Group <a href="#8">[RFC2534]</a>.</p>

<p>The client attribute names defined below may be used to identify some
common features associated with client devices that print or display visual
information, such as text or graphics. They are described using XML namespace
local parts, which are further qualified by the XML namespace identifier
<tt><a
href="/2002/11/08-ccpp-client">http://www.w3.org/2002/11/08-ccpp-client</a></tt>.
(These attributes apply to presented capabilities of the client rather than
to a specific internal component or aspect of a client system.)</p>
<dl>
  <dt><i>deviceIdentifier</i>:</dt>
    <dd>(Value data type: String) A URI that serves as an identifier of the
      client device or user agent type.</dd>
  <dt><i>type</i>:</dt>
    <dd>(Value data type: set of Strings) A MIME content type that can be
      accepted and presented by a client. Similar in principle to the HTTP
      'accept:' header, but specifying a single MIME content-type, without
      associated content-type parameters. Multiple accepted content-types can
      be described by a value that is a set of content-type string values.
      Where needed, content-type parameters can be expressed by additional
      CC/PP attributes.</dd>
  <dt><i>schema</i>:</dt>
    <dd>(Value data type: set of Strings) A URI that identifies a schema that
      is recognized by the client. The schema may be an XML DTD <a
      href="#1">[XML]</a>, XML Schema <a href="#13">[XMLSCHEMA-1]</a>, RDF
      Schema <a href="#4">[RDFSCHEMA]</a> or any other applicable document
      structure that can be identified by a URI. A <i>Schema</i> value
      refines any acceptable document type indicated by the <i>Type</i>
      attribute, but its meaning must not depend on the value of <i>Type</i>.
      Typically, this will be used to indicate specific XML DTDs or schema
      that are recognized within <tt>text/xml</tt> or
      <tt>application/xml</tt> document types.</dd>
  <dt><i><font color="black">cha</font>rW<font
  color="black">idth</font></i>:</dt>
    <dd>(Value data type: Integer) For a text display device (type="text/*"),
      the width of the character display. For non-proportional font displays,
      the number of display cells. For non-proportional font displays as
      typically used in East Asia, the number of half-width display cells
      (ideographic characters and other full-width characters typically
      occupy two display cells). For proportional font displays, the width of
      the display in ens (where an en is the typographical unit that is the
      width of an en-dash/letter 'n').</dd>
  <dt><i>charHeight</i>:</dt>
    <dd>(Value data type: Integer) For a text display device
      (<tt>type="text/*"</tt>), the number of lines of text that can be
      displayed (i.e. the display height in characters).</dd>
  <dt><i>charset</i>:</dt>
    <dd>(Value data type: set of Strings, per <a href="#29">[RFC2278]</a>)
      For a text handling device, a character encoding that can be processed
      (values per MIME 'charset' parameter on content-type
      <tt>"text/*"</tt>). <i><b>NOTE:</b></i> the term "charset" is a
      historical misnomer, and does not necessarily indicate a repertoire of
      characters that can be displayed, just an encoding. In some cases,
      though, the encoding may imply a repertoire.</dd>
  <dt><i>pix-x</i>:</dt>
    <dd>(Value data type: Integer) For an image display device
      (<tt>type="image/*"</tt>), the number of horizontal pixels that can be
      displayed.</dd>
  <dt><i>pix-y</i>:</dt>
    <dd>(Value data type: Integer) For an image display device
      (<tt>type="image/*"</tt>), the number of vertical pixels that can be
      displayed.</dd>
  <dt><i>color</i>:</dt>
    <dd>(Value data type: String, per <a href="#8">[RFC2534]</a>) For text
      and image display devices, an indication of the color capabilities (per
      RFC 2534 <a href="#8">[RFC2534]</a>, possible values are
      "<tt>binary</tt>", "<tt>grey</tt>", "<tt>limited</tt>",
      "<tt>mapped</tt>" and "<tt>full</tt>").
      <strong><em>NOTE</em></strong><b>:</b> the <i>color</i> attribute
      provides a very coarse indication of color capabilities, sufficient for
      a range of simple applications, and may be refined by additional
      attributes where capabilities need to be described in greater
    detail.</dd>
</dl>

<h4><a name="xtocid-33666562">Client attribute properties (instances of</a>
<tt>ccpp:Attribute</tt>)</h4>

<table summary="Figure C-1" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure C-1: CC/PP client vocabulary
  properties</caption>
  <tbody>
    <tr bgcolor="#CCCCFF">
      <td><pre>ccpp-client:deviceIdentifier Domain=ccpp:Component,   Range=ccpp:string
ccpp-client:type             Domain=ccpp:Component,   Range=rdf:Bag
ccpp-client:schema           Domain=ccpp:Component,   Range=ccpp:string
ccpp-client:charWidth        Domain=ccpp:Component,   Range=ccpp:integer
ccpp-client:charHeight       Domain=ccpp:Component,   Range=ccpp:integer
ccpp-client:charset          Domain=ccpp:Component,   Range=rdf:Bag
ccpp-client:pix-x            Domain=ccpp:Component,   Range=ccpp:integer
ccpp-client:pix-y            Domain=ccpp:Component,   Range=ccpp:integer
ccpp-client:color            Domain=ccpp:Component,   Range=ccpp:string</pre>
      </td>
    </tr>
  </tbody>
</table>

<h4><a name="xtocid-62790564">Schema for client vocabulary</a></h4>

<p>(Schema URI: <tt><a
href="/2002/11/08-ccpp-client">http://www.w3.org/2002/11/08-ccpp-client</a></tt>)</p>

<table summary="Figure C-2" border="1" cellspacing="2" cellpadding="2">
  <caption align="bottom">Figure C-2: RDF schema for client
  vocabulary</caption>
  <tbody>
    <tr bgcolor="#CCFFCC">
      <td><pre>&lt;?xml version='1.0'?&gt;

&lt;!DOCTYPE rdf:RDF [
  &lt;!ENTITY ns-rdf  'http://www.w3.org/1999/02/22-rdf-syntax-ns#'&gt;
  &lt;!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'&gt;
  &lt;!ENTITY ns-ccpp 'http://www.w3.org/2002/11/08-ccpp-schema#'&gt;
  &lt;!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-ccpp-client#'&gt;
]&gt;

&lt;rdf:RDF
  xmlns:rdf         = '&amp;ns-rdf;'
  xmlns:rdfs        = '&amp;ns-rdfs;'
  xmlns:ccpp        = '&amp;ns-ccpp;'
  xmlns:ccpp-client = '&amp;ns-ccpp-client;'&gt;

&lt;!--  CC/PP attribute property definitions --&gt;

  &lt;!-- These properties represent some common vocabulary that is     --&gt;
  &lt;!-- available for use by applications that need to indicate       --&gt;
  &lt;!-- the common features indicated by these attributes.  They      --&gt;
  &lt;!-- serve as an example of how a new attribute vocabulary can     --&gt;
  &lt;!-- be defined for use in a CC/PP profile.                        --&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;deviceIdentifier'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Client device identifier&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;string'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      A URI that identifies the type of client device or user agent.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;type'&gt;
    &lt;rdfs:label xml:lang="en"&gt;MIME content type&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-rdf;Bag'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      A string containing a MIME content-type, or a set of such strings,
      indicating the MIME content-types that can be handled.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;schema'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Schema identifier&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;string'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      A URI that identifies a language or DTD that is recognized by
      the client, or a set of such URIs.

      Specific values of this attribute may be applicable to certain
      MIME content types.  For example, a URI that is associated with
      a resource containing an XML DTD will generally be applicable
      only with text/xml or application/xml content types.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;charWidth'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Character display width&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;integer'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      For character displays, the number of characters that can be
      rendered across the display.  For displays using a proportional
      font, this is the display width in typographical 'em's.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;charHeight'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Character display height&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;integer'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      For character displays, the number of rows of characters that
      can be displayed.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;charset'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Character set encoding&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-rdf;Bag'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      For character displays, the MIME 'charset' values that
      can be handled.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;pix-x'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Pixel display width&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;integer'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      For raster displays, the width of the display in pixels.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;pix-y'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Pixel display height&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;integer'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
       For raster displays, the height of the display in pixels.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

  &lt;ccpp:Attribute rdf:about='&amp;ns-ccpp-client;color'&gt;
    &lt;rdfs:label xml:lang="en"&gt;Color display capabilities&lt;/rdfs:label&gt;
    &lt;rdfs:domain rdf:resource='&amp;ns-ccpp;Component'/&gt;
    &lt;rdfs:range  rdf:resource='&amp;ns-ccpp;string'/&gt;
    &lt;rdfs:comment xml:lang="en"&gt;
      For display or print devices, an indication of the color
      rendering capabilities:
      binary  - indicates bi-level color (black-and-white, or similar).
      grey    - indicates gray scale capability, capable of sufficient
                distinct levels for a monochrome photograph.
      limited - indicates a limited number of distinct colors, but
                not with sufficient control for displaying a color
                photograph (e.g. a pen plotter, high-light printer or
                limited display).
      mapped  - indicates a palettized color display, with enough
                levels and control for coarse display of color
                photographs.
      full    - indicates full color display capability.
    &lt;/rdfs:comment&gt;
  &lt;/ccpp:Attribute&gt;

&lt;/rdf:RDF&gt;</pre>
      </td>
    </tr>
  </tbody>
</table>

<h2><a name="Appendix_D"></a>Appendix D: Recommendations for creating a
vocabulary</h2>

<p>This appendix in INFORMATIVE.</p>

<p>Fundamental to the design of CC/PP is the idea that new client attributes
can be defined, as needed, through the introduction of new vocabularies.</p>

<p>Similarly, new relationships can be introduced through new vocabulary
items, though the introduction of these needs a great deal of care to ensure
their semantics are adequately and consistently defined. A general principle
is that application-neutral CC/PP processors should be able to understand and
manipulate CC/PP relationships without necessarily understanding the CC/PP
attributes to which they refer.</p>

<p>It is recommended that RDF Schema be used, in conjunction with supporting
documentation, to define any new CC/PP vocabulary. The rest of this section
assumes that RDF Schema is being used for defining any new vocabulary. The
previous appendix is an example of this approach.</p>

<p>New vocabularies are introduced through XML namespaces. Their relationship
to other CC/PP vocabulary items can be defined by new RDF schema statements
(which must necessarily augment the core RDF schema for the CC/PP vocabulary
given in <a href="#Appendix_C">Appendix C</a> of this document).</p>

<h3><a name="Basic"></a>D.1 Basic format for all vocabulary items</h3>
All vocabulary items used by CC/PP are URIs and optional fragment
identifiers, used as RDF property arc identifiers. Relative URI forms should
not be used. Vocabulary items used for different purposes are generally
associated with different XML namespaces. Some common RDF base classes are
defined so that a schema-aware RDF processor can perform improved analysis of
a CC/PP profile, and separate CC/PP profile elements from other statements
made about any resource that appear in the same RDF graph as a CC/PP profile.

<p>All properties used as CC/PP attributes must be instances of the class
<tt>ccpp:Attribute</tt>, which itself is a subclass of <tt>rdf:Property</tt>.
(That is, the schema defining CC/PP attribute properties should define them
as instances of <tt>ccpp:Attribute</tt>. Thus, a schema-aware processor can
distinguish between properties that are part of a CC/PP profile, and
properties which may be part of an attribute value.)</p>

<p>Each CC/PP attribute is associated with a component of a profile (e.g.
HardwarePlatform, SoftwarePlatform, etc.), and is used as a property of an
instance of the appropriate component resource. All such component resource
types are subclasses of <tt>ccpp:Component</tt>. New
<code>ccpp:Component</code> based classes may be introduced for new types of
attribute vocabulary, but it is strongly recommended that an existing
<code>ccpp:Component</code> type be used if one is applicable.</p>

<blockquote>
  <p><b><i>NOTE</i></b>: A simple CC/PP parser is not required to be
  schema-aware, and its implementation does not need to have knowledge of the
  RDF class of any attribute or resource, nor is the profile required to
  carry RDF type information. The discussion of classes and schema-aware
  processing is in relation to possible future developments of generic RDF
  processors that may deal with CC/PP and other RDF vocabularies and schemas,
  possibly mixed in a single document. For such developments to be possible,
  it is important to take account of class and schema issues in the design of
  CC/PP, even though simple CC/PP processors need no such awareness.</p>
</blockquote>

<h3><a name="namespaces"></a>D.2 Use of XML namespaces</h3>

<p>All CC/PP attributes must be associated with a fully resolvable namespace
identifier URI. (Relative URIs, or URIs whose interpretation may depend on
the context in which they are used, should not be used.)</p>

<blockquote>
  <p><em><strong>NOTE</strong></em>: It is anticipated that a namespace URI
  used for CC/PP attributes may also be used to identify an RDF or other
  schema relating to those attributes. However, such usage is beyond the
  scope of this specification.</p>
</blockquote>

<p>Typically, new CC/PP attributes will be associated with a new namespace,
which serves (among other things) to distinguish between possible different
uses of the same attribute name local parts. For example, <code>a:foo</code>
and <code>b:foo</code> name quite distinct attributes as long as the prefixes
<code>a:</code> and <code>b:</code> are associated with different namespace
URIs.</p>

<h3><a name="Principles"></a>D.3 Principles for defining new attributes</h3>

<h4><a name="xtocid-33666567">D.3.1 If possible, reuse existing
vocabularies</a></h4>

<p>Re-using existing vocabularies, where applicable, leverages work that has
already been undertaken and reduces the opportunity for different attribute
names that mean almost but not quite the same thing.</p>

<p>Note that names using different namespaces may be freely mixed in a
profile, so requiring one additional feature is not a good reason to define a
complete new vocabulary.</p>

<h4><a name="3.3.2"></a>D.3.2 Attribute value type and interpretation</h4>
Attribute definitions should indicate the type and interpretation of the
associated value. Ultimately it is a matter for agreement between generating
and receiving applications how any particular attribute value is to be
interpreted.

<p>Where possible, for ease of processing and compatibility with other
frameworks, attribute values should be based on one of the data types
described in section <a href="#AttributeData">4.1</a> of this document.</p>

<p>Where attributes express a quantity associated with a client, the units of
that quantity should be clearly associated with the attribute definition.
There is no separate mechanism for indicating the units in which an attribute
value is expressed.</p>

<h4><a name="3.3.3"></a>D.3.3 Interpretation not dependent on other attribute
values</h4>
The meaning of every attribute must be defined in isolation from other
attributes: no attribute may have a meaning that changes dependent on the
value of some other attribute. E.g. an attribute called, say, page-width must
always be expressed using the same units: it is not acceptable for this
attribute to be expressed in characters for some class of device, millimeters
for another, and inches for another. (Note that it is still allowable to
define an attribute that cannot be interpreted unless some other attribute is
also defined; the important principle here is that adding a new attribute
should not invalidate any knowledge of a client that can be deduced from
attributes previously defined.)

<p>Attributes may be defined in "layers", so that simple capabilities (e.g.
ability to handle color photographic images) can be described by a simple
attribute, with additional attributes used to provide more detailed or arcane
capabilities (e.g. exact color matching capabilities).</p>

<h4><a name="3.3.4"></a>D.3.4 Attribute naming conventions</h4>
Attributes are RDF properties. The RDF Model and Syntax document <a
href="#3">[RDF]</a>, Appendix C, recommends the use of "interCap" name styles
for RDF property names (starting with a lowercase letter, and having 2nd and
subsequent words within a name started with a capital letter and no internal
punctuation). We recommend such style be used for CC/PP attribute names,
except where some other form is preferred for compatibility with other
systems (such as some CONNEG-compatible print and display attributes
described below).

<p>RDF class names used in CC/PP profiles preferably begin with an uppercase
letter.</p>

<h4><a name="AttributeApplicability"></a>D.3.5 Attributes should have
specific applicability</h4>

<p>If an attribute is defined with a broad range of applicability, problems
could arise if a user tries to apply a single attribute to different parts of
a profile.</p>

<p>An attribute defined very broadly might be subject to different privacy or
security concerns when applied in different circumstances. For example,
having a text-to-voice capability on a mobile phone type of device might be a
generally useful feature, but a similar feature in a PC might be indicative
of a personal disability. Thus a combination of text-to-voice capability and
using a PC-type platform might suggest private information not necessarily
associated with any of the features in isolation.</p>

<h3><a name="ProtocolInteractions"></a>D.4 Protocol interactions</h3>

<p>In some cases, there may be overlaps between CC/PP vocabularies and a
particular protocol with which CC/PP is used. E.g. the client vocabulary
<i>charset</i> and the HTTP <code>accept-charset:</code> header. To some
extent, the protocol-independent nature of CC/PP makes this inevitable, to
the extent that existing protocols may have limited content negotiation
facilities.</p>

<p>When designing vocabularies, avoid defining features which would be
expected to be part of a particular protocol behavior; anything that
describes or relates to a transfer mechanism rather than what is transferred
should be avoided; e.g. support for a feature like HTTP persistent
connections should not be indicated in a CC/PP profile, as (a) it is a
protocol-specific feature, and (b) it doesn't really help the origin server
to select appropriate content for the client.</p>

<p>Similarly, when defining protocol bindings for using CC/PP, interaction
with existing negotiation mechanisms should be considered and specified. A
detailed treatment of this topic is beyond the scope of this
specification.</p>

<h2><a name="Appendix_E"></a>Appendix E: Review of applicable
vocabularies</h2>

<p>This appendix is INFORMATIVE.</p>

<p>This section introduces some possible sources of properties to be
described by CC/PP attribute vocabularies. It is not normative, and is
included to give an idea of some kinds of client feature that CC/PP might be
used to convey.</p>

<h3><a name="IETF"></a>E.1 IETF media feature registration (CONNEG)</h3>
The IETF has defined an IANA registry for media feature tags <a
href="#5">[RFC2506]</a> and a syntax <a href="#6">[RFC2533]</a> for
relational-style expressions using these to describe client and server media
features. A small common vocabulary has been defined <a
href="#8">[RFC2534]</a>, which has been used as a basis for the CC/PP client
common vocabulary. The IETF Internet fax Working Group has also created
additional registrations to describe the capabilities of fax machines <a
href="#16">[RFC2531]</a>.

<p>RFC 2506 <a href="#5">[RFC2506]</a> defines three kinds of media feature
tags:</p>
<ul>
  <li><i>IETF tree</i>: registered feature tags that are simple names, which
    are defined and assigned under the auspices of the IETF standards
  process.</li>
  <li><i>Global tree</i>: registered feature tags that are simple names
    preceded by <tt>'g.'</tt>. These are defined by groups other than the
    IETF, but are registered with IANA to ensure uniqueness of these
  names.</li>
  <li><i>Unregistered</i>: feature tags that consist of <tt>'u.'</tt>
    followed by a slightly restricted form of URI.</li>
</ul>
There is currently a proposal to create a URN namespace for IANA registries.
This would create a mechanism to allow IANA-registered feature tags to be
used directly as URIs in CC/PP expressions.

<p>Unregistered feature tags may be used in CC/PP expressions by stripping
off the leading '<tt>u.</tt>' and taking the resulting URI.</p>

<p>All media feature tags and values can be expressed in CC/PP, but not all
CC/PP profiles can be expressed as media feature tags and values. In
particular, CC/PP text values are case sensitive whereas some media feature
values are case insensitive. Media feature values can be mapped to CC/PP text
values by applying a case-normalization convention (e.g. convert to
lowercase).</p>

<p>This version of CC/PP does not have mechanisms matching those in the IETF
media feature framework, which can be used within CC/PP to state capabilities
in terms of comparisons with fixed values (e.g. '<tt>pix-x&lt;=640</tt>') and
attribute values that appear in certain combinations (e.g.
'<tt>pix-x=640</tt>' AND '<tt>pix-y=480</tt>' OR '<tt>pix-x=800</tt>' AND
'<tt>pix-y=600</tt>'). Future work may define such mechanisms.</p>

<h3><a name="UAPROF"></a>E.2 WAP UAProf</h3>
UAProf <a href="#9">[UAPROF]</a> is a WAP Forum specification that is
designed to allow wireless mobile devices to declare their capabilities to
data servers and other network components.

<p>The design of UAProf is already based on RDF. As such, its vocabulary
elements use the same basic format that is used for CC/PP.</p>

<p>The CC/PP model follows UAProf, in that each user agent property is
defined as belonging to one of a small number of components, each of which
corresponds to an aspect of a user agent device; e.g.</p>
<ul>
  <li>Hardware platform</li>
  <li>Software platform</li>
  <li>WAP characteristics</li>
  <li>Browser user agent</li>
  <li>Network characteristics</li>
</ul>

<p>Although its RDF schema is more prescriptive regarding class and property
usage than UAProf, the design of CC/PP is backwards compatible. The goal is
that valid UAProf profiles are also valid CC/PP profiles; however not all
CC/PP profiles are necessarily valid UAProf profiles.</p>

<h3><a name="TIFF"></a>E.3 TIFF</h3>
TIFF is a raster image encapsulation file format developed and maintained by
Adobe Systems <a href="#17">[TIFF]</a>. It is also the basis for the standard
file format for Internet Fax <a href="#18">[RFC2301]</a>.

<p>As well as pixel-based image data in a variety of coding and compression
formats, TIFF supports a wide range of options for different kinds of
image-related information. These options might be candidate CC/PP attributes.
Many of the TIFF properties relating to image handling capabilities have
already been defined as tags in the CONNEG space as part of the Internet Fax
work <a href="#16">[RFC2531]</a>; these might best be referenced using URIs
based on their CONNEG tag names.</p>

<h3><a name="WAVE"></a>E.4 WAVE</h3>
WAVE is an encapsulation format for audio data, developed and maintained by
Microsoft <a href="#19">[MULTIMEDIA]</a>.

<p>There is a registry of WAVE-supported audio codecs that might be used as
CC/PP attributes <a href="#20">[RFC2361]</a>.</p>

<p>IETF work in progress for voice messaging (VPIM/IVM) could create IETF
media feature registry tags that are usable by CC/PP profiles through the
same mechanisms described in section <a href="#IETF">E.1</a> above.</p>

<h3><a name="MPEG-4"></a>E.5 MPEG-4</h3>
MPEG-4 is an encapsulation format for video data, possibly combined with
audio data, developed and maintained by the ISO MPEG Working Group <a
href="#21">[MPEG]</a>.

<h3><a name="MPEG-7"></a>E.6 MPEG-7</h3>
MPEG-7 is a metadata format for information associated with image, video,
audio and other data, currently in development by the ISO MPEG Working Group
<a href="#26">[MPEG-7]</a>.

<h3><a name="PWG"></a>E.7 PWG</h3>
The printer Working Group defines attributes and capabilities applicable to
printing devices <a href="#22">[PWG]</a>. Some of this work is incorporated
into the IETF Internet Printing Protocol (IPP) <a href="#23">[RFC2566]</a>.

<h3><a name="Salutation"></a>E.8 Salutation</h3>
Salutation is a protocol and identification scheme for communicating devices,
mainly in a LAN environment, developed and maintained by the Salutation
Consortium <a href="#24">[SALUTATION]</a>. The device capability
identification mechanisms probably include many items that might be used as
CC/PP attributes.

<h2><a name="Appendix_F"></a>Appendix F: CC/PP applications</h2>

<p>This appendix is INFORMATIVE.</p>

<p>CC/PP is a format framework designed to be used in the context of a wider
application or operational environment. This specification does not define
how to use CC/PP with any particular protocol or application.</p>

<p>This appendix highlights some other issues that application developers
must consider in their designs. Many of these issues may be covered by an
applicable protocol specification used to convey CC/PP profiles.</p>

<p>To make effective use of the CC/PP framework, the operating rules for the
wider environment must specify:</p>
<ul>
  <li>Capability exchange protocol</li>
  <li>Trust model</li>
  <li>Vocabulary</li>
  <li>Security mechanisms</li>
  <li>Constraints on allowable attribute value types</li>
  <li>Attribute value processing and/or matching rules</li>
  <li>Proxy vocabulary and processing</li>
  <li>Rules for request profile identification</li>
  <li>Additional information to be included with any transmitted resource
  data</li>
  <li>URI forms allowed for identifying referenced profile documents (e.g.
    defaults)</li>
  <li>Mechanisms for locating and retrieving referenced profile documents</li>
  <li>Interactions with any existing negotiation mechanisms in the host
    protocol</li>
</ul>

<p>There are a few protocol assumptions built into the design of CC/PP.
Although it is intended to be largely protocol independent, some
consideration has been given to use of CC/PP with HTTP for retrieving Web
resources.</p>

<h3><a name="Outline"></a>F.1 Outline of request processing in HTTP</h3>

<p>CC/PP is envisaged to be used with HTTP in the following fashion.</p>

<p>(This is not a protocol specification, just an indication of the kind of
information flows envisaged. Defining a protocol to convey CC/PP information
is a separate effort <a href="#35">[CCPPEX]</a>).</p>

<table summary="Figure F-1" border="1" cellspacing="2" cellpadding="2"
bgcolor="#FFCC99">
  <caption align="bottom">Figure F-1: HTTP request processing</caption>
  <tbody>
    <tr>
      <td><pre>  +------+ (5)       (4) +-------+               +------+
  |Client| &lt;==response== | Proxy | &lt;==response== |Origin| &lt;====&gt; (Resource)
  |  UA  | ===request==&gt; |       | ===request==&gt; |server| (3)    (  data  )
  +------+ (1)   |       +-------+ (2)   |       +------+
                 |                       |
                 v                       v
(Client  ) &lt;--- (Client profile) &lt;----- (Request profile)
(defaults)       + local values          |
                                         v
                        (Proxy   ) &lt;--- (Proxy profile)
                        (defaults)       + local values</pre>
      </td>
    </tr>
  </tbody>
</table>
<ol>
  <li>The client sends an HTTP request, with an accompanying CC/PP client
    profile. The client profile may contain references to default profiles
    describing a range of common capabilities for the client concerned (e.g.
    a particular computer/operating system/browser combination, or a
    particular model of mobile device), and values that are variations from
    the default profile.</li>
  <li>The HTTP request may pass through a firewall/proxy that (a) imposes
    constraints on the kinds of content that can be accessed, or (b) can
    adapt other forms of content to the capabilities of the requesting
    client. This proxy extends the CC/PP profile with a description of these
    constraints and adaptations, and sends this with the HTTP request on to
    the origin server. The request may pass through several such proxies.</li>
  <li>The origin server receives the request and interprets the CC/PP
    profile. It selects and/or generates content that matches the combined
    proxy and client capabilities described in the profile. This is sent to
    the last proxy in the request chain in an HTTP response.</li>
  <li>If required, the proxy applies any content adaptations, and any other
    functions it is designed to perform. The resulting response and content
    is passed back toward the requesting client.</li>
  <li>The client receives the HTTP response and presents the content it
    contains.</li>
</ol>

<blockquote>
  <p><b><i>NOTE</i></b>: There is some overlap between CC/PP and the various
  HTTP accept-* headers. A protocol specification for using CC/PP with HTTP
  must indicate how HTTP 'accept-*' headers may be used, and how they
  interact with CC/PP profiles.</p>
</blockquote>

<h3><a name="ProtocolAssumptions"></a>F.2 Protocol assumptions for proxy
behavior</h3>

<p>The framework for describing proxy behaviors makes some assumptions about
the protocol used to convey a CC/PP profile:</p>
<ul>
  <li>The CC/PP profile is conveyed in one or more parts, each containing a
    graph fragment, which are combined to form a single RDF graph.</li>
  <li>In addition to the RDF graph, the protocol must separately name the RDF
    resource corresponding to the root of the current request profile.</li>
  <li>The current operational model is that all CC/PP profile interpretation
    is performed by the origin server, and none by the proxies. It may be
    necessary for the protocol to allow the origin server to provide
    information with its response that allows proxies to decide whether or
    not to apply any conversions that they offer; e.g. is XHTML-to-WML
    conversion required, or does the client have native XHTML capability?
    <p><b><i>NOTE</i></b>: The "current operational model" noted above does
    not prohibit proxies from interpreting CC/PP profiles. Rather, it means
    that the framework for describing proxy behaviors does not require that
    proxies interpret them.</p>
  </li>
</ul>

<h2><a name="Appendix_G"></a>Appendix G: RDF Compatibility</h2>

<p>This appendix is INFORMATIVE.</p>

<p>This CC/PP specification is based on Resource Description Framework (RDF)
Model and Syntax Specification <a href="#3">[RDF]</a>, a W3C Recommendation.
That version of RDF does not have explicit datatyping of literals. The RDF
specifications have been undergoing revision as this specification is being
written. The revised RDF (<a href="/TR/rdf-syntax-grammar/">RDF/XML Syntax
Specification (Revised)</a>), which at the time of writing has not reached
recommendation status, introduces support for specifying the XML Schema
datatype of a literal value. This appendix outlines the implications for
implementors in making their CC/PP implementations compatible with this
proposed addition to RDF. It is hoped that a future version of the CC/PP
specification will propose how explicit datatyping should be used in defining
CC/PP profiles.</p>

<h3><a name="RDFImplicitDatatyping">G.1 Implicit datatyping</a></h3>

<p>In this specification, a CC/PP attribute value contained in a CC/PP
profile is, in RDF (Revised) <a href="#rdfprimer">[RDFPRIMER]</a>
terminology, an <a href="/TR/rdf-concepts/#dfn-plain-literal">RDF Plain
Literal</a>. A CC/PP vocabulary schema (such as the example in <a
href="#Appendix_C">Appendix C</a>), that is defined in terms of the simple
types introduced in the CC/PP schema (in <a href="#Appendix_B">Appendix
B</a>), can provide additional type information for these attributes. A CC/PP
profile consumer application may use the vocabulary schema (either by
directly interpreting the schema data, or, for known vocabularies, by
embedding the equivalent information in the application) to check the
validity of the data provided in a profile, and to map the data into
programming language data types.</p>

<h3><a name="RDFExplicitDatatyping">G.2 Explicit datatyping</a></h3>

<p>The revised RDF Working Draft supports explicit XSD (<a
href="/TR/xmlschema-2/">XML Schema Datatypes</a>) datatyping. When explicit
datatyping is adopted, the CC/PP specification could be revised to permit an
attribute value in a CC/PP profile to be represented as an <a
href="/TR/rdf-concepts/#dfn-typed-literal">RDF Typed Literal</a>. In the <a
href="/TR/rdf-syntax-grammar/#section-Syntax-datatyped-literals">XML
serialization of an RDF Typed Literal</a>, the type of the literal value is
specified as an attribute of the element containing the literal value. In
this case, a CC/PP profile consumer application could use this type
information to interpret the CC/PP attribute value, without requiring access
to additional vocabulary schema information.</p>

<p>In the future it may be that, for backward compatibility, a CC/PP profile
consumer should be able to handle CC/PP attributes that use either implicit
or explicit datatyping.</p>

<h2><a name="RevisionHistory"></a>Appendix W: Revision history</h2>

<table summary="Revision history" style="width: 80%;" border="1">
  <tbody>
    <tr>
      <td width="20%" valign="top">20001218</td>
      <td width="80%" valign="top">Document created from merge of
        architecture, structure and vocabulary documents.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20001219</td>
      <td width="80%" valign="top">Move some vocabulary and proxy material
        from section to into sections 3 and 4. Various small edits.</td>
    </tr>
    <tr>
      <td width="20%" height="18" valign="top">20010109</td>
      <td width="80%" height="18" valign="top">Various editorial fixes. Merge
        appendices dealing with print and display vocabulary. Remove some
        vocabulary source references. Add XML examples to many of the RDF
        graph examples. Reorganize material in sections 2 and 3, moving some
        technical detail to section 3. Move discussion of CC/PP applications
        to a new appendix. Assign figure numbers.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010112</td>
      <td width="80%" valign="top">More group review editorial comments.
        Fixed some schema errors. Moved client schema summary to appendix C.
        Updated UAProf reference and namespace URI. Added Working Group
        members to acknowledgments.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010116</td>
      <td width="80%" valign="top">More group review editorial comments.
        Added citation of RFC2119. Changed some instances of rdf:Bag to {...}
        notation in graph descriptions. Use ccpp:defaults consistently in
        examples; add note about allowing ccpp:Defaults for compatibility
        with UAProf. Section 2.1.3: added some additional text about
        references to external defaults. Added points for allowed URIs and
        resolution mechanisms in appendix F. Figure 3-12 notation change.
        Section 4.1: attempt to further clarify what is required behavior.
        Section 4.3, add paragraph about support of RDF schema. Appendix D:
        add text recommending use of RDF schema to define vocabularies.
        Section 3.1.1, add text about use of rdf:type properties for
        ccpp:Component resources. Appendix B: remove references to ccpp:Set
        and ccpp:Value.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010118</td>
      <td width="80%" valign="top">Validate RDF examples with SiRPAC (W3C
        online facility) and correct errors detected. Fix up some internal
        links.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010129</td>
      <td width="80%" valign="top">Add hyperlinked ToC (courtesy of "htmltoc"
        by Earl Hood)</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010223</td>
      <td width="80%" valign="top">Published as First Working Draft.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010315</td>
      <td width="80%" valign="top">Added last-call section. Changed some
        spelling. Published as Last-call working Working Draft.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010425</td>
      <td width="80%" valign="top">Fold in review comments for editorial
        matters. Explain use of names for URIs in examples. Remove unused
        terms from glossary.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010510</td>
      <td width="80%" valign="top">Remove P3P from glossary; P3P integration
        will be discussed in a separate security document. Review all
        examples to use full URIs rather than placeholder names, and qualify
        all RDF attributes with namespace prefixes. Added cross-reference
        from section 2.3 to 3.1.4 and 3.1.5 (CC/PP usage of RDF). Added NOTE
        saying why proxy descriptions are not linked directly. Added sequence
        value to data types. Remove requirement for an attribute to be unique
        across all components of a profile. Added restriction that a single
        "Proxy-behavior" must reference a single type of component, and that
        the component type should be specified (section 3.2.2). Clarify that
        'charset' feature really indicates a character encoding. Appendix F
        re-worked to make it clearer that this document does not define an
        HTTP binding for using CC/PP. Added 'xml:lang' attributes to schemas
        in appendices B and C. Revise interpretation of charWidth to better
        cater for international characters.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010511</td>
      <td width="80%" valign="top">Reference XML schema data types, and fix
        up some minor schema errors. Introduce new class ccpp:Structure to
        clearly distinguish all CC/PP structural properties from attribute
        properties. Editorial fix in relationship to UAProf (E.2).</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010522</td>
      <td width="80%" valign="top">Revise text relating to CC/PP attributes
        that are represented by URI strings: preferred treatment is as RDF
        resources rather than literal URI strings (section 4.1.1.1 and
        various examples). Discussion of graph composition (new section
        3.1.6). Deleted some gratuitous repetition (sections 3.1.1 and
      3.1.2).</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010620</td>
      <td width="80%" valign="top">Revise all examples to use explicit
        namespace prefixes for RDF elements and attributes. Remove unused
        ccpp: namespace declaration from some examples.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010704</td>
      <td width="80%" valign="top">Fix small errors in examples 2-3b and
        3-2c. Editorial fixes.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20010906</td>
      <td width="80%" valign="top">Reword text in 3.1.5 describing use of
        rdf:type on ccpp:Component instance. Revise description of
        'charWidth' in appendix C to remove some errors with respect to
        international characters. Section 4.1.1.1: Added some text indicating
        that XML conventions must be used for encoding non-ASCII characters
        in URI values (per RDF spec). Section 4.1.2.2: added note that
        vocabularies that use sequence values should define the significance
        of the ordering. Add text pointing about possible protocol
        interactions to appendices D, F and F.1. Checked example of empty
        description element with RDF validator.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20011102</td>
      <td width="80%" valign="top"><p>Revise the wording in section 4.1.1.1
        about encoding of non-ASCII characters in URI values, to reference
        the XML specification errata <a
        href="/XML/xml-V10-2e-errata#E26">http://www.w3.org/XML/xml-V10-2e-errata#E26</a>.
        Updated reference [XML] to cite the errata document. Revision to
        section 4.1.2 introduction text to clarify that arbitrary RDF
        resources may be used for attribute values, though their meaning is
        not defined here. Fix typo.</p>
      </td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020402</td>
      <td width="80%" valign="top">Add hyperlinks to schema documents.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020501</td>
      <td width="80%" valign="top">Added the term 'XML attributes' where
        necessary to distinguish between CC/PP attributes and XML attributes.
        Fixed the local about reference in Figure 2-1b. Added 'section'
        hyperlinks where necessary. Removed unnecessary angle brackets around
        namespace identifiers. Removed extraneous space from date of Working
        Group meeting. Removed the proxy hardware and software examples:
        there is no need for a proxy to append its processor or operating
        system to a CC/PP request and using this as an example will cause
        confusion. Removed some remaining instances of the term 'URI string'.
        Changed 'don't reuse existing vocabularies' heading to 'reuse
        existing vocabularies'. Removed an unnecessarily capitalized
        'Defaults' from Section 3.1.3. Fixed the references so they work:
        there was a problem with the square brackets. Changed 'RDF schema' to
        'RDF Schema' where it is used to refer to the W3C specification.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020502</td>
      <td width="80%" valign="top">Fixed errors in RDF in Figure 1-2 and
        Figure 3-3 identified with W3C RDF validation service.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020507</td>
      <td width="80%" valign="top">Updated section 3.1.5 to resolve issue 16.
        Updated section 2.2 to resolve issue 54. Added a paragraph about WAI
        to resolve issue 115.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020520</td>
      <td width="80%" valign="top">Updated CC/PP schema to create datatypes
        for anyURI, string and integer in the CC/PP namespace that reference
        the datatypes in the XML Schema. The previous version of the schema
        just referenced the XML schema datatypes. Changed CC/PP namespace to
        <a
      href="/2002/05/20-ccpp#">http://www.w3.org/2002/05/20-ccpp#</a>.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020715</td>
      <td width="80%" valign="top">Updated the reference section to
        distinguish between normative and informative references and use
        [AAAA] not [nnnn] reference label format as per W3C Style Guide to
        address issue 181. Removed examples using composite literals i.e.
        changed all instances of <code>&lt;display&gt;</code> to
        <code>&lt;displayWidth&gt;</code> and
        <code>&lt;displayHeight&gt;</code> to address issue 152. Changed
        example profiles so that rdf:about's point to a profile URI rather
        than a schema URI as this means the component applies to this
        particular profile instance, rather than any device using this
        particular schema to address issue 153. Added some text to section
        3.1.1 to address issue 175. Inserted Figure 3.2b to explain default
        resolution to address issue 180.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020717</td>
      <td width="80%" valign="top">Updated the UAProf URL, specifically in
        Section 2.2, and added text proposed by Art Barstow to resolve issue
        54. Also updated UAProf examples so they use legal UAProf property
        names.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020719</td>
      <td width="80%" valign="top">Removed a remaining instance of the
        sentence "This is one of three properties to describe a proxy
        behavior." to address issue 37.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020812</td>
      <td width="80%" valign="top">Added a sentence to section 3.2 and three
        additional paragraphs to section 3.2.2 to address issue 182.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020812</td>
      <td width="80%" valign="top">Changed a paragraph in section 3.2 to
        address issue 182.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20020924</td>
      <td width="80%" valign="top">Removed usage of ccpp:Resource to resolve
        issue 31.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20021105</td>
      <td width="80%" valign="top">Altered text of abstract to indicate proxy
        vocabulary is optional. Altered text of introduction to indicate
        proxy vocabulary is optional. Added a preceding sentence in section
        2.1.4 saying proxy support is optional. Ditto for section 2.2. Moved
        Client-profile, Request-profile, Proxy-profile and Proxy-Behavior
        from CCPP Schema to proxy Schema. Updated figures B.1 and B.2 and
        added two new figures, B.3 and B.4 to reflect this. Due to the data
        typing decision made by RDF-Core concerning interpreting literals,
        changed all instances of XML Schema datatypes to CC/PP data types.
        Removed the sentence "Note that, where available, XML schema
        datatypes (xsdt:) are used for literal values [XMLSCHEMA-2]." from
        section B.1. Updated URIs to 08 November 2002. Changed definition of
        CC/PP profile in Section 2.1 to "A CC/PP profile is broadly
        constructed as a 2-level hierarchy: a profile having a number of
        components, and each component having at least one or more
        attributes." to resolve the concern expressed by the UAProf drafting
        committee that the CC/PP definition of a component is incompatible
        with UAProf.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20021211</td>
      <td width="80%" valign="top">Fixed problem with Figure 2-3b described
        in issue 183. Clarified meaning of CC/PP profile for issue 185.
        Clarified the status of appendices to address issue 189. Removed the
        term "CC/PP expression" from section 2.2 to address issue 191.
        Updated the RDF Schema reference to point at the March 2000 Candidate
        Recommendation version. Fixed UAProf reference to address issue 198.
        Fixed schema in B.3 to address issue 200. Updated introductory
        paragraph to Appendix C to address issue 201. Added a definition of a
        "CC/PP processor" to appendix B to address issue 202 and replaced
        instance of "CC/PP parser" with CC/PP processor.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20021213</td>
      <td width="80%" valign="top">Checked usage of optional and recommended
        so that instances are capitalized where necessary to address issue
        188.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20030203</td>
      <td width="80%" valign="top">Fixed the use of both
        http://www.w3.org/2002/12/13-ccpp-schema and
        http://www.w3.org/2002/12/13-ccpp as CC/PP namespaces. Uniformly
        adopted the use of rdf:about in the schemas.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20030212</td>
      <td width="80%" valign="top">Fixed problem with section 2 in toc. Fixed
        bold # in CC/PP namespace in section 2.2. Fixed grammatical error in
        section 4.1.2.2.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20030320</td>
      <td width="80%" valign="top">Added mention of RDF data typing and
        further DIWG work to status section. Added mention of compatibility
        with CONNEG to section 1. Removed use of compound simple types in
        examples in section 2.1.3. Removed section 2.1.4 (introduction to
        proxies), section 2.3 (rdf primer), section 3.2 (proxies). Ensured
        the document references the RDF specs (RDF M&amp;S, RDF/XML Syntax,
        RDF Primer, RDF Schema) in appropriate places. Promoted section 3.1
        subsections to section 3 subsections. Removed case-insensitive text
        from section 4.1.1.2. Changed minimum recommended value for integer
        numbers and corrected the XML schema datatype in section 4.1.1.3.
        Described difficulty of rational numbers in section 4.1.1.4.
        Clarified expressive relationship with CONNEG in section E.1.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20030728</td>
      <td width="80%" valign="top">Removed remnants mentioning proxy. Added
        note about RDF Primer referencing more recent versions of RDF specs
        in status section. Changed schema URL from
        http://www.w3.org/2002/11/08-ccpp to
        http://www.w3.org/2002/11/08-ccpp-schema in section 2.2. Added UAProf
        namespace compatibility for component and defaults in section 3.1 and
        3.3. Changed HTML 3.0 to HTML 3.2 in various examples. Removed Tokens
        from section 4.1.1.2 and Appendix C. Fixed rational number schema in
        section 4.1.1.4. Clarified that multiple occurences of a single
        attribute within a single component are not allowed in section 4.1.2.
        Added section 5 Conformance. Changed references to point to dated
        copies in section 7. Removed anyURI from schema in Appendices B and
        C. Changed Rational datatype to rational in Appendix B. Added note
        about case normalization for CONNEG compatibility in section E.1.
        Added Appendix G RDF Compatibility.</td>
    </tr>
    <tr>
      <td width="20%" valign="top">20030915</td>
      <td width="80%" valign="top">Various editorial changes and
        clarifications. Added "delivery context" term to section 1. Removed
        redundant paragraph regarding namespace URIs in section 2.2. Removed
        section 4.1.1.1 "Values described by URIs" since it should have been
        removed when anyURI was removed.</td>
    </tr>
  </tbody>
</table>
<hr>

<p align="left"><a href="http://validator.w3.org/"><img
src="http://www.w3.org/Icons/valid-html401.gif" alt="Valid HTML 4.01!"
border="0" height="31" width="88"></a></p>
</body>
</html>