discontinued / server · Files

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

div.constraint,
div.issue,
div.note       { margin-left: 2em; }
div.notice     { margin-left: 2em; font-weight: bold; font-size: larger; color: red }

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


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

   div.reprdef { border: 4px double gray;
                 margin: 0em 0em; padding: 0em }
   div.reprHeader { margin: 4px;
                    font-weight: bold }
   span.reprdef { color: #A52A2A }
   div.reprBody { border-top-width: 4px;
                  border-top-style: double;
                  border-top-color: #d3d3d3;
                  padding: 0px ; margin: 0em}
   span.termdef { color: #850021 }
   span.arrow { font-style: normal; font-weight: bold }
   span.termdef { color: #850021 }
   a.termdef:visited, a.termdef:link { font-family: sans-serif;
                              font-style: normal;
                              color: #850021;
                              text-decoration: none }
   a.termdefxspecref:visited, a.termdefxspecref:link { font-family: sans-serif;
                              font-style: normal;
                              color: #850021 }
   a.termref:visited, a.termref:link { font-family: sans-serif;
                              font-style: normal;
                              color: #850021;
                              text-decoration: none }
   tr.bitcell { height: 2em }
   td.bitcell { width: 2em }
   .del { text-decoration: line-through }
   .chg { color: red }
   .add { color: fuchsia }

   sup small { font-style: italic;
               color: #8F8F8F }

   div.notice { margin-left: 2em; font-weight: bold; font-size: larger; color: #005A9C; }

</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC.css"></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p>
<h1><a name="title" id="title"></a>Efficient XML Interchange (EXI) Format 1.0</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Recommendation 10 March 2011</h2><dl><dt>This version:</dt><dd>
<a href="http://www.w3.org/TR/2011/REC-exi-20110310/">http://www.w3.org/TR/2011/REC-exi-20110310/</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/exi/">http://www.w3.org/TR/exi/</a></dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2011/PR-exi-20110120/">http://www.w3.org/TR/2011/PR-exi-20110120/</a>
</dd><dt>Editors:</dt><dd>John Schneider, AgileDelta, Inc.</dd><dd>Takuki Kamiya, Fujitsu Laboratories of America, Inc.</dd></dl><p>Please refer to the <a href="http://www.w3.org/XML/EXI/exi-10-errata"><strong>errata</strong></a> for this document, which may
      include normative corrections.</p><p>See also <a href="http://www.w3.org/TR/2011/REC-exi-20110310/,translations"><strong>translations</strong></a>.</p><p>This document is also available in these non-normative formats: <a href="exi.xml">XML</a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>&nbsp;&copy;&nbsp;2011&nbsp;<a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>This document is the specification of the Efficient XML Interchange (EXI)
format. EXI is a very compact representation for the Extensible Markup
Language (XML) Information Set that is intended to simultaneously optimize
performance and the utilization of computational resources. The EXI
format uses a hybrid approach drawn from the information and formal language
theories, plus practical techniques verified by measurements,
for entropy encoding XML information. Using a relatively simple algorithm,
which is amenable to fast and compact implementation, and a small set of
datatype representations, 
it reliably produces efficient encodings of XML event streams.
The grammar production system and format definition of EXI are presented.</p></div><div>
<h2><a name="status" id="status"></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 is the Recommendation of the Efficient XML Interchange Format 1.0. It has been produced by the <a href="http://www.w3.org/XML/EXI/">EXI Working Group</a>, which is part of the <a href="http://www.w3.org/XML/Activity">Extensible Markup Language (XML) Activity</a>. 
The goals of the EXI Working Group are discussed in the <a href="http://www.w3.org/XML/2009/02/exi-charter.html">charter</a>.
</p><p>Changes since the previous publication based on feedback received during the review period and from implementers are listed in the <a href="#changes">Change Log</a>. A <a href="http://www.w3.org/2007/10/htmldiff?doc1=http://www.w3.org/TR/2011/PR-exi-20110120/&amp;doc2=http://www.w3.org/TR/2011/REC-exi-20110310/">diff-marked version</a> against the previous version of this document is also available.  </p><p> The EXI Working Group has produced a 
<a href="http://www.w3.org/XML/EXI/#InteropTestingFramework">test suite</a> testing the interoperability of this specification, and an <a href="http://www.w3.org/XML/EXI/implementation-report/">interoperability test report</a>. </p><p>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. 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.</p><p>Individuals are invited to send feedback on this document by email to <a href="mailto:public-exi-comments@w3.org">public-exi-comments@w3.org</a>, a mailing list with a <a href="http://lists.w3.org/Archives/Public/public-exi-comments/">public archive</a>. This mailing list is reserved for comments, it is inappropriate to send discussion email to this address. Discussion should take place on the <a href="mailto:public-exi@w3.org">public-exi@w3.org</a> mailing list (<a href="http://lists.w3.org/Archives/Public/public-exi/">public archive</a>).</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/38502/status#specs">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. </p></div><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1. <a href="#introduction">Introduction</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#history">History and Design</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#conventions">Notational Conventions and Terminology</a><br>
2. <a href="#principles">Design Principles</a><br>
3. <a href="#concepts">Basic Concepts</a><br>
4. <a href="#streams">EXI Streams</a><br>
5. <a href="#header">EXI Header</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#EXICookie">EXI Cookie</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;5.2 <a href="#DistinguishingBits">Distinguishing Bits</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;5.3 <a href="#version">EXI Format Version</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;5.4 <a href="#options">EXI Options</a><br>
6. <a href="#encodingEvents">Encoding EXI Streams</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;6.1 <a href="#eventCodes">Determining Event Codes</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;6.2 <a href="#encodingEventCodes">Representing Event Codes</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;6.3 <a href="#fidelityOptions">Fidelity Options</a><br>
7. <a href="#encodingValues">Representing Event Content</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;7.1 <a href="#encodingDatatypes">Built-in EXI Datatype Representations</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.1 <a href="#encodingBinary">Binary</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.2 <a href="#encodingBoolean">Boolean</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.3 <a href="#encodingDecimal">Decimal</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.4 <a href="#encodingFloat">Float</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.5 <a href="#encodingInteger">Integer</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.6 <a href="#encodingUnsignedInteger">Unsigned Integer</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.7 <a href="#encodingQName">QName</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.8 <a href="#encodingDateTime">Date-Time</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.9 <a href="#encodingBoundedUnsigned">n-bit Unsigned Integer</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.10 <a href="#encodingString">String</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.10.1 <a href="#restrictedCharSet">Restricted Character Sets</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.1.11 <a href="#encodingList">List</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;7.2 <a href="#encodingEnumerations">Enumerations</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;7.3 <a href="#stringTable">String Table</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.3.1 <a href="#stringTablePartitions">String Table Partitions</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.3.2 <a href="#encodingOptimizedForHits">Partitions Optimized for Frequent use of Compact Identifiers</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;7.3.3 <a href="#encodingOptimizedForMisses">Partitions Optimized for Frequent use of String Literals</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;7.4 <a href="#datatypeRepresentationMap">Datatype Representation Map</a><br>
8. <a href="#grammars">EXI Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;8.1 <a href="#grammarNotation">Grammar Notation</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.1.1 <a href="#fixedEventCodes">Fixed Event Codes</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.1.2 <a href="#variableEventCodes">Variable Event Codes</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;8.2 <a href="#grammarEventCodes">Grammar Event Codes</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;8.3 <a href="#pruningProductions">Pruning Unneeded Productions</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;8.4 <a href="#builtinGrammars">Built-in XML Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.4.1 <a href="#builtinDocGrammars">Built-in Document Grammar</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.4.2 <a href="#builtinFragGrammars">Built-in Fragment Grammar</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.4.3 <a href="#builtinElemGrammars">Built-in Element Grammar</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;8.5 <a href="#informedGrammars">Schema-informed Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.1 <a href="#informedDocGrammars">Schema-informed Document Grammar</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.2 <a href="#informedFragGrammars">Schema-informed Fragment Grammar</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.3 <a href="#informedElementFragGrammar">Schema-informed Element Fragment Grammar</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4 <a href="#informedElemGrammars">Schema-informed Element and Type Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1 <a href="#protoGrammars">EXI Proto-Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.1 <a href="#grammarConcatOperator">Grammar Concatenation Operator</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.2 <a href="#elementGrammars">Element Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.3 <a href="#typeGrammars">Type Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.3.1 <a href="#simpleTypeGrammars">Simple Type Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.3.2 <a href="#complexTypeGrammars">Complex Type Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.3.3 <a href="#anyTypeGrammar">Complex Ur-Type Grammar</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.4 <a href="#attributeUses">Attribute Uses</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.5 <a href="#particles">Particles</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.6 <a href="#elementTerms">Element Terms</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.7 <a href="#wildcardTerms">Wildcard Terms</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.8 <a href="#modelGroupTerms">Model Group Terms</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.8.1 <a href="#sequenceGroupTerms">Sequence Model Groups</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.8.2 <a href="#choiceGroupTerms">Choice Model Groups</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.1.8.3 <a href="#allGroupTerms">All Model Groups</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.2 <a href="#normalizedGrammars">EXI Normalized Grammars</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.2.1 <a href="#eliminatingProductions">Eliminating Productions with no Terminal Symbol</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.2.2 <a href="#eliminatingSymbols">Eliminating Duplicate Terminal Symbols</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.3 <a href="#eventCodeAssignment">Event Code Assignment</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.4 <a href="#undeclaredProductions">Undeclared Productions</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.4.1 <a href="#addingProductions">Adding Productions when Strict is False</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;8.5.4.4.2 <a href="#addingProductionsStrict">Adding Productions when Strict is True</a><br>
9. <a href="#compression">EXI Compression</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;9.1 <a href="#blocks">Blocks</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;9.2 <a href="#channels">Channels</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;9.2.1 <a href="#StructureChannel">Structure Channel</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;9.2.2 <a href="#ValueChannels">Value Channels</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;9.3 <a href="#CompressedStreams">Compressed Streams</a><br>
10. <a href="#conformance">Conformance</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;10.1 <a href="#streamConformance">EXI Stream Conformance</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;10.2 <a href="#processorConformance">EXI Processor Conformance</a><br>
</p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A <a href="#References">References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;A.1 <a href="#Normative-References">Normative References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;A.2 <a href="#Informative-References">Other References</a><br>
B <a href="#InfosetMapping">Infoset Mapping</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.1 <a href="#DocumentInformationItem">Document Information Item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.2 <a href="#ElementInformationItem">Element Information Items</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.3 <a href="#AttributeInformationItem">Attribute Information Item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.4 <a href="#ProcessingInstructionInformationItem">Processing Instruction Information Item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.5 <a href="#UnexpandedEntityInformationItem">Unexpanded Entity Reference Information item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.6 <a href="#CharacterInformationItem">Character Information item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.7 <a href="#CommentInformationItem">Comment Information item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.8 <a href="#DocumentTypeDeclaractionInformationItem">Document Type Declaration Information item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.9 <a href="#UnparsedEntityInformationItem">Unparsed Entity Information Item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.10 <a href="#NotationMapping">Notation Information Item</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;B.11 <a href="#NamespaceInformationItem">Namespace Information Item</a><br>
C <a href="#optionsSchema">XML Schema for EXI Options Document</a><br>
D <a href="#initialStringValues">Initial Entries in String Table Partitions</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;D.1 <a href="#initialUriValues">Initial Entries in Uri Partition</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;D.2 <a href="#initialPrefixValues">Initial Entries in Prefix Partitions</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;D.3 <a href="#initialLocalNames">Initial Entries in Local-Name Partitions</a><br>
E <a href="#regexToCharset">Deriving 
Set of Characters 
from XML Schema Regular Expressions</a><br>
F <a href="#mediaTypeRegistration">Content Coding and Internet Media Type</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;F.1 <a href="#contentCoding">Content Coding</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;F.2 <a href="#internetMediaType">Internet Media Type</a><br>
G <a href="#example">Example Encoding</a> (Non-Normative)<br>
H <a href="#grammarExamples">Schema-informed Grammar Examples</a> (Non-Normative)<br>
&nbsp;&nbsp;&nbsp;&nbsp;H.1 <a href="#exampleProtoGrammars">Proto-Grammar Examples</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;H.2 <a href="#exampleNormGrammars">Normalized Grammar Examples</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;H.3 <a href="#exampleCompleteGrammars">Complete Grammar Examples</a><br>
I <a href="#changes">Recent Specification Changes</a> (Non-Normative)<br>
&nbsp;&nbsp;&nbsp;&nbsp;I.1 <a href="#changes8">Changes from Proposed Recommendation</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;I.2 <a href="#changes7">Changes from Candidate Recommendation</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;I.3 <a href="#changes6">Changes from Last Call Working Draft</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;I.4 <a href="#changes5">Changes from Fourth Public Working Draft</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;I.5 <a href="#changes4">
Changes from Third Public Working Draft
</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;I.6 <a href="#changes3">
Changes from Second Public Working Draft
</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;I.7 <a href="#changes2">
Changes from First Public Working Draft
</a><br>
J <a href="#acknowledgements">Acknowledgements</a> (Non-Normative)<br>
</p></div><hr><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1. Introduction</h2><p>The Efficient XML Interchange (EXI) format is a very compact, high
performance XML representation that was designed to work well for a
broad range of applications.  It simultaneously improves performance
and significantly reduces bandwidth requirements without compromising
efficient use of other resources such as battery life, code size,
processing power, and memory.
</p><p>EXI uses a grammar-driven approach that achieves very efficient
encodings using a straightforward encoding algorithm and a small set
of 
datatype representations. 
Consequently, <a href="#key-exiprocessor" class="termref"><span class="arrow"></span>EXI processors<span class="arrow"></span></a> are relatively simple and
can be implemented on devices with limited capacity. </p><p>EXI is schema
"informed", meaning that it can utilize available schema
information to improve compactness and performance, but does not
depend on accurate, complete or current schemas to work. It supports
arbitrary schema extensions and deviations and also works very
effectively with partial schemas or in the absence of any schema.  The
format itself also does not depend on any particular schema language,
or format, for schema information. </p><p><span class="termdef"><a name="key-exiprocessor" id="key-exiprocessor">[Definition:]&nbsp;&nbsp;</a>A program module
called an <b>EXI processor</b>, whether it is software or
hardware, is used by application programs to encode their structured data
into <a href="#key-existream" class="termdef"><span class="arrow"></span>EXI streams<span class="arrow"></span></a> and/or to decode
<a href="#key-existream" class="termdef"><span class="arrow"></span>EXI streams<span class="arrow"></span></a> to make the structured
data accessible.</span>

The former and latter aforementioned roles of EXI processors are called <span class="termdef"><a name="key-exiencoder" id="key-exiencoder">[Definition:]&nbsp;&nbsp;</a><b>EXI stream encoder</b></span> and <span class="termdef"><a name="key-exidecoder" id="key-exidecoder">[Definition:]&nbsp;&nbsp;</a><b>EXI stream decoder</b></span> respectfully.

This document not only specifies the
EXI format, but also defines errors that EXI processors are required to
detect and behave upon.</p><p>The primary goal of this document is to define the EXI format completely without leaving ambiguity so as to make it feasible for implementations to interoperate. As such, the document lends itself to describing the design and features of the format in a systematic manner, often declaratively with relatively few prosaic annotations and examples. Those readers who prefer a step-by-step introduction to the EXI format design and features are suggested to start with the non-normative <a href="#exiprimer">[EXI Primer]</a>.
</p><div class="div2">
<h3><a name="history" id="history"></a>1.1 History and Design</h3><p>EXI is the result of extensive work carried out by the W3C's XML
Binary Characterization (XBC) and Efficient XML Interchange (EXI)
Working Groups. XBC was chartered to investigate the costs and
benefits of an alternative form of XML, and formulate a way to objectively
evaluate the potential of a substitute format for XML.  Based on XBC's
recommendations, EXI was chartered, first to measure, evaluate, and
compare the performance of various XML technologies (using metrics
developed by XBC <a href="#xbcmeas">[XBC Measurement Methodologies]</a>), and then, if it appeared
suitable, to formulate a recommendation for a W3C format
specification. The measurements results and analyses, are presented
elsewhere <a href="#eximeas">[EXI Measurements Note]</a>. The format described in this
document is the specification so recommended. 
</p><p>The functional requirements of the EXI format are those that were
prepared by the XBC WG in their analysis of the desirable properties
of a high performance representation for XML <a href="#xbcproperties">[XBC Properties]</a>.
Those properties were derived from a very broad set of use cases also
identified by the XBC working group <a href="#xbcusecases">[XBC Use Cases]</a>.
</p><p>The design of the format presented here, is largely based on the
results of the measurements carried out by the group to evaluate the
performance characteristics (mainly of processing efficiency and
compactness) of various existing formats. The EXI format is based on
Efficient XML <a href="#efx">[Efficient XML]</a>, including for example the basis heuristic grammar approach,
compression algorithm, and resulting entropy encoding. 
</p><p>EXI is compatible with XML at the XML Information Set <a href="#XMLInfoset">[XML Information Set]</a> level, rather than at the XML syntax level. This
permits it to encapsulate an efficient alternative syntax and grammar
for XML, while facilitating at least the potential for minimizing the
impact on XML application interoperability.
</p></div><div class="div2">
<h3><a name="conventions" id="conventions"></a>1.2 Notational Conventions and Terminology</h3><p>The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear
EMPHASIZED in this document, are to be interpreted as described in RFC
2119 <a href="#RFC2119">[IETF RFC 2119]</a>. Other terminology used to describe the EXI
format is defined in the body of this specification.
</p><p>The term <b>event</b> and <b>stream</b> is used throughout this document to denote <b><a href="#key-exievent" class="termref"><span class="arrow"></span>EXI event<span class="arrow"></span></a></b> and <b><a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a></b> respectively unless the words are qualified differently to mean otherwise.</p><p>This document specifies an abstract grammar for EXI. In grammar notation, all terminal
symbols are represented in plain text and all non-terminal symbols are
represented in <em>italics</em>. Grammar productions are
represented as follows: </p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>LeftHandSide</em> :&nbsp;&nbsp;
Terminal&nbsp;&nbsp;<em>NonTerminal</em></td></tr></tbody></table><p>A set of one or more grammar productions that share the same
left-hand side non-terminal symbol are often presented together annotated
with <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> that specify how events matching the terminal symbols of the associated productions are represented in the EXI stream as follows: 
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="3">
<em>LeftHandSide</em> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">
Terminal<sub>&nbsp;1</sub>&nbsp;&nbsp;<em>NonTerminal</em><sub>&nbsp;1</sub></td><td>EventCode<sub>&nbsp;1</sub></td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;2</sub>&nbsp;&nbsp;<em>NonTerminal</em><sub>&nbsp;2</sub></td><td>EventCode<sub>&nbsp;2</sub></td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;3</sub>&nbsp;&nbsp;<em>NonTerminal</em><sub>&nbsp;3</sub></td><td>EventCode<sub>&nbsp;3</sub></td></tr><tr><td></td><td></td><td>...</td><td></td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;n</sub>&nbsp;&nbsp;<em>NonTerminal</em><sub>&nbsp;n</sub></td><td>EventCode<sub>&nbsp;n</sub></td></tr></tbody></table><p>Section <a href="#grammarNotation"><b>8.1 Grammar Notation</b></a> introduces additional notations for describing productions and <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> in grammars. Those additional notations facilitate concise representation of the EXI grammar system.
</p><p>
<span class="termdef"><a name="key-qname" id="key-qname">[Definition:]&nbsp;&nbsp;</a>
In this document, the term <b>qname</b> is used to denote a 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#QName" class="termdefxspecref">QName</a><sup><small>XS2</small></sup>.
</span>
QName values are composed of an uri, a local-name and an optional prefix. Two qnames are considered equal if they have the same uri and local-name, regardless of their prefix values. In cases where prefixes are not relevant, such as in the grammar notation, they are not specified by this document.
</p><p>Terminal symbols that are qualified with a qname permit the use of a wildcard symbol (*) in place of or as part of a qname. The forms of terminal symbols involving qname wildcards used in grammars and their definitions are described in the table below.
</p><table width="80%" border="1"><colgroup align="left" width="25%" span="1"></colgroup><colgroup span="1"></colgroup><thead><tr><th align="center">Wildcard</th><th>Definition</th></tr></thead><tbody><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;SE&nbsp;(*)</td><td>The terminal symbol that matches a start element (SE) event with any qname.</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;SE (<em>uri</em>&nbsp;:&nbsp;*)</td><td>The terminal symbol that matches a start element (SE) event with any local-name in namespace <em>uri</em>.</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;AT&nbsp;(*)</td><td>The terminal symbol that matches an attribute (AT) event with any qname.</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;AT&nbsp;(<em>uri</em>&nbsp;: *)</td><td>The terminal symbol that matches an attribute (AT) event with any local-name in namespace <em>uri</em>.</td></tr></tbody></table><p>Several prefixes are used throughout this document to designate certain namespaces. The bindings shown below are assumed, however, any prefixes can be used in practice if they are properly bound to the namespaces.</p><table width="80%" border="1"><colgroup align="left" width="25%" span="1"></colgroup><colgroup span="1"></colgroup><thead><tr><th align="center">Prefix</th><th>Namespace Name</th></tr></thead><tbody><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;exi</td><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.w3.org/2009/exi
</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;xsd</td><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.w3.org/2001/XMLSchema</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;xsi</td><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
http://www.w3.org/2001/XMLSchema-instance</td></tr></tbody></table><p>In describing the layout of an EXI format construct, a pair of square brackets [ ] are used to surround the name of a field to denote that the occurrence of the field is optional in the structure of the part or component that contains the field.
</p><p>In arithmetic expressions, the notation &lceil;<em>x</em>&rceil; where <em>x</em> represents a real number denotes the ceiling of <em>x</em>, that is, the smallest integer greater than or equal to <em>x</em>.
</p><p>
When it is stated that strings are sorted in lexicographical order, 
it is done so character by character, and the order among characters is determined by comparing their Unicode code points.
</p><p>Unless stated otherwise, when this specification indicates one type is derived from another type, it means the type is derived by extension or restriction, not by union or list. Similarly, when this specification uses the term type hierarchy, it is referring to the hierarchy of types derived from one another by extension or restriction
</p></div></div><div class="div1">
<h2><a name="principles" id="principles"></a>2. Design Principles</h2><p>The following design principles were used to guide the development of EXI and encourage consistent design decisions. They are listed here to provide insight into the EXI design rationale and to anchor discussions on desirable EXI traits.</p><dl><dt class="label">General:</dt><dd><p>One of primary objectives of EXI is to maximize the number of systems, devices and applications that can communicate using XML data. Specialized approaches optimized for specific use cases should be avoided.</p></dd><dt class="label">Minimal:</dt><dd><p>To reach the broadest set of small, mobile and embedded applications, simple, elegant approaches are preferred to large, analytical or complex ones. </p></dd><dt class="label">Efficient:</dt><dd><p>EXI must be competitive with hand-optimized binary formats so it can be used by applications that require this level of efficiency. </p></dd><dt class="label">Flexible:</dt><dd><p>EXI must deal flexibly and efficiently with documents that contain arbitrary schema extensions or deviate from their schema. Documents that contain schema deviations should not cause encoding to fail. </p></dd><dt class="label">Interoperable:</dt><dd><p>EXI must integrate well with existing XML technologies, minimizing the changes required to those technologies. It must be compatible with the XML Information Set <a href="#XMLInfoset">[XML Information Set]</a>, without significant subsetting or supersetting, in order to maintain interoperability with existing and prospective XML specifications.</p></dd></dl></div><div class="div1">
<h2><a name="concepts" id="concepts"></a>3. Basic Concepts</h2><p>EXI achieves broad generality, flexibility, and performance, by unifying concepts from formal language theory and information theory into a single, relatively simple algorithm. The algorithm uses a grammar to determine what is likely to occur at any given point in an XML document and encodes the most likely alternatives in fewer bits. The fully generalized algorithm works for any language that can be described by a grammar (e.g., XML, Java, HTTP, etc.); however, EXI is optimized specifically for XML languages. </p><p>The built-in EXI grammars accept any XML document or fragment and may be augmented with productions derived from schemas or other sources of information about what is likely to occur in a set of XML documents. 
When schemas are used, EXI also supports a user-customizable set of Datatype Representations for efficiently representing typed values.
Though use of any schema languages including XML Schemas <a href="#schema1">[XML Schema Structures]</a> 
&nbsp; <a href="#schema2">[XML Schema Datatypes]</a>, RELAX NG schemas <a href="#relaxng">[ISO/IEC 19757-2:2008]</a>, DTDs 
<a href="#XML10">[XML 1.0]</a> &nbsp; <a href="#XML11">[XML 1.1]</a> is permitted, EXI grammars and 
datatype representations need to be given bindings for each schema language used.
This specification only defines how EXI grammars and datatype representations 
relate to XML schema.
</p><p>
The <a href="#key-exiencoder" class="termref"><span class="arrow"></span>EXI stream encoder<span class="arrow"></span></a> uses the grammar to map a stream of XML information items onto a smaller, lower entropy, stream of <a href="#key-exievent" class="termref"><span class="arrow"></span>events<span class="arrow"></span></a>. </p><p>The <a href="#key-exiencoder" class="termref"><span class="arrow"></span>EXI stream encoder<span class="arrow"></span></a> then represents the stream of events using a set of simple variable length codes called <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a>. <a href="#key-eventcode" class="termref"><span class="arrow"></span>Event codes<span class="arrow"></span></a> are similar to Huffman codes <a href="#huffman">[Huffman Coding]</a>, but are much simpler to compute and maintain. They are encoded directly as a sequence of values, or if additional compression is desired, they are passed to the <a href="#compression" class="termref"><span class="arrow"></span>EXI compression<span class="arrow"></span></a> algorithm, which replaces frequently occurring event patterns to further reduce size. </p></div><div class="div1">
<h2><a name="streams" id="streams"></a>4. EXI Streams</h2><p><span class="termdef"><a name="key-existream" id="key-existream">[Definition:]&nbsp;&nbsp;</a>An <b>EXI stream</b> is an 
<a href="#key-exiheader" class="termdef"><span class="arrow"></span>EXI header<span class="arrow"></span></a>
followed by an EXI body.</span> <span class="termdef"><a name="key-exibody" id="key-exibody">[Definition:]&nbsp;&nbsp;</a>The <b>EXI body</b> carries the content of the document, while the EXI header communicates the options used for encoding the EXI body.</span> Section
<a href="#header"><b>5. EXI Header</b></a> describes the <a href="#key-exiheader" class="termref"><span class="arrow"></span>EXI header<span class="arrow"></span></a>. 
</p><p><span class="termdef"><a name="key-exievent" id="key-exievent">[Definition:]&nbsp;&nbsp;</a>The building block of an EXI body is an <b>EXI event</b>.</span> An EXI body consists of a sequence of EXI events representing an <a href="#key-exidocument" class="termref"><span class="arrow"></span>EXI document<span class="arrow"></span></a> or an <a href="#key-exifragment" class="termref"><span class="arrow"></span>EXI fragment<span class="arrow"></span></a>.
</p><p>The EXI events permitted at any given position in an EXI stream are determined by the EXI grammar. 
As is the case with XML, 
the events occur with nesting pairs of matching start element and end element events where any pair does not intersect with another except when it is fully contained in the other.

The EXI grammar incorporates knowledge of the XML grammar and may be augmented and refined using schema information and fidelity options. The EXI grammar is formally specified in section <a href="#grammars"><b>8. EXI Grammars</b></a>.</p><p>
An EXI body can represent an EXI document with a single root element or an EXI fragment with zero or more root elements. 
<span class="termdef"><a name="key-exidocument" id="key-exidocument">[Definition:]&nbsp;&nbsp;</a>
<b>EXI documents</b> are EXI bodies with a single root element that conform to the Built-in Document Grammar (See <a href="#builtinDocGrammars"><b>8.4.1 Built-in Document Grammar</b></a>) or Schema-informed Document Grammar (See <a href="#informedDocGrammars"><b>8.5.1 Schema-informed Document Grammar</b></a>).
</span>
<span class="termdef"><a name="key-exifragment" id="key-exifragment">[Definition:]&nbsp;&nbsp;</a>
<b>EXI fragments</b> are EXI bodies with zero or more root elements that conform to the Built-in Fragment Grammar (See <a href="#builtinFragGrammars"><b>8.4.2 Built-in Fragment Grammar</b></a>) or Schema-informed Fragment Grammar (See <a href="#informedFragGrammars"><b>8.5.2 Schema-informed Fragment Grammar</b></a>).
</span>
</p><p>
<span class="termdef"><a name="key-schemainformed-existream" id="key-schemainformed-existream">[Definition:]&nbsp;&nbsp;</a>When schema information is available to describe the contents of an EXI body, such an EXI stream is a <b>schema-informed EXI stream</b> and the EXI body is interpreted according to the Schema-informed Document Grammar (See <a href="#informedDocGrammars"><b>8.5.1 Schema-informed Document Grammar</b></a>) or Schema-informed Fragment Grammar (See <a href="#informedFragGrammars"><b>8.5.2 Schema-informed Fragment Grammar</b></a>).</span> 
<span class="termdef"><a name="key-schemaless-existream" id="key-schemaless-existream">[Definition:]&nbsp;&nbsp;</a>Otherwise, an EXI stream is a <b>schema-less EXI stream</b>, and the EXI body is interpreted according to the Built-in Document Grammar (See <a href="#builtinDocGrammars"><b>8.4.1 Built-in Document Grammar</b></a>) or Built-in Fragment Grammar (See <a href="#builtinFragGrammars"><b>8.4.2 Built-in Fragment Grammar</b></a>).</span>
</p><p>The following table summarizes the EXI event types and associated event content that occur in an EXI stream.  
<span class="termdef"><a name="key-content-item" id="key-content-item">[Definition:]&nbsp;&nbsp;</a>
The content of an event consists of <b>content items</b>, 
</span>
and the content items appear in an EXI stream in the order they are shown in the table 
following their respective <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> that 
each marks the start of an <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a>. 
In addition, the table includes the grammar notation used to represent each <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a> in this specification. Each <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a> in an EXI stream participates in a mapping system that relates <a href="#key-exievent" class="termref"><span class="arrow"></span>events<span class="arrow"></span></a> to XML Information Items so that an EXI document 
or an EXI fragment 
as a whole serves to represent an XML Information Set. The table shows XML Information Items relevant to each EXI event. Appendix <a href="#InfosetMapping"><b>B Infoset Mapping</b></a> describes the mapping system in detail.</p><a name="eventTypes" id="eventTypes"></a><table border="1"><caption>Table 4-1. EXI events</caption><thead><tr><th>EXI Event Type</th><th>Event Content 
(Content Items) 
</th><th>Grammar Notation 
(Terminal Symbols) 
</th><th>Information Item</th></tr></thead><tbody><tr><td>Start Document</td><td>&nbsp;</td><td>SD</td><td rowspan="2"><a href="#DocumentInformationItem"><b>B.1 Document Information Item</b></a></td></tr><tr><td>End Document</td><td>&nbsp;</td><td>ED</td></tr><tr><td rowspan="3">Start Element</td><td rowspan="3"><em>qname</em>
</td><td>SE (&nbsp;<em>qname</em>&nbsp;)</td><td rowspan="4"><a href="#ElementInformationItem"><b>B.2 Element Information Items</b></a></td></tr><tr><td>SE&nbsp;(&nbsp;*&nbsp;)</td></tr><tr><td>
SE&nbsp;(&nbsp;<em>uri&nbsp;:&nbsp;</em>*&nbsp;)
</td></tr><tr><td>End Element</td><td>&nbsp;</td><td>EE</td></tr><tr><td rowspan="3">Attribute</td><td rowspan="3"><em>qname, value</em></td><td>AT&nbsp;(&nbsp;<em>qname</em>&nbsp;)</td><td rowspan="3"><a href="#AttributeInformationItem"><b>B.3 Attribute Information Item</b></a></td></tr><tr><td>AT&nbsp;(&nbsp;*&nbsp;)</td></tr><tr><td>
AT&nbsp;(&nbsp;<em>uri&nbsp;:&nbsp;</em>*&nbsp;)
</td></tr><tr><td>Characters</td><td><em>value</em></td><td>CH</td><td><a href="#CharacterInformationItem"><b>B.6 Character Information item</b></a></td></tr><tr><td>Namespace Declaration</td><td>
<em>
uri
</em>, <em>
prefix
</em>, 
<em>local-element-ns</em>
</td><td>NS</td><td><a href="#NamespaceInformationItem"><b>B.11 Namespace Information Item</b></a></td></tr><tr><td>Comment</td><td>
<em>text</em></td><td>CM</td><td><a href="#CommentInformationItem"><b>B.7 Comment Information item</b></a></td></tr><tr><td>Processing Instruction</td><td>
<em>name, text</em></td><td>PI</td><td><a href="#ProcessingInstructionInformationItem"><b>B.4 Processing Instruction Information Item</b></a></td></tr><tr><td>DOCTYPE</td><td>
<em>name, public, system, text</em></td><td>DT</td><td><a href="#DocumentTypeDeclaractionInformationItem"><b>B.8 Document Type Declaration Information item</b></a></td></tr><tr><td>Entity Reference</td><td>
<em>name</em></td><td>ER</td><td><a href="#UnexpandedEntityInformationItem"><b>B.5 Unexpanded Entity Reference Information item</b></a></td></tr><tr><td>Self Contained</td><td>&nbsp;</td><td>SC</td><td>&nbsp;</td></tr></tbody></table><p>Section 
<a href="#encodingEvents"><b>6. Encoding EXI Streams</b></a> describes the algorithm used to encode <a href="#key-exievent" class="termref"><span class="arrow"></span>events<span class="arrow"></span></a> in the EXI stream. 
As indicated in the table above, there are some event types that carry content with their <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a> instances while other event types function as markers without content. 
</p><p>SE events may be followed by a series of NS events. Each NS event either associates a prefix with an URI, assigns a default namespace, or in the case of a namespace declaration with an empty URI, rescinds one of such associations in effect at the point of its occurrence. The effect of the association or disassociation caused by a NS event stays in effect until the corresponding EE event occurs.
</p><p>Like XML, the namespace of a particular element may be specified by a namespace declaration 
preceding 
the element or a local namespace declaration following the element name. When the namespace is specified by a local namespace declaration, the <em>local-element-ns</em> flag of the associated NS event is set to true and the prefix of the element is set to the prefix of that NS event. When the namespace is specified by a previous namespace declaration, the <em>local-element-ns</em> flag of all local NS events is false and the prefix of the element is set according to the prefix component of the element <em>qname</em>. The series of NS events associated with a particular element may include at most one NS event with its 
<em>local-element-ns</em> flag
 set to true. The <em>uri</em> of a NS event with its 
<em>local-element-ns</em> flag
 set to true MUST match the <em>uri</em> of the associated SE event.
</p><p>An SE event may be followed by a SC event, indicating the element is self-contained and can be read independently from the rest of the EXI body. Applications may use self-contained elements to index portions of the EXI body for random access.
</p><p>
The representation of <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> which identify the event type and start each event is described in <a href="#encodingEventCodes"><b>6.2 Representing Event Codes</b></a>. 
Each item in the event content has a 
datatype representation
associated with it as shown in the following table. The content of each <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a>, if any, is encoded as a sequence of items each of which being encoded according to its 
datatype representation 
in order starting with the first item followed by subsequent items.</p><a name="table2" id="table2"></a><table border="1" width="95%"><caption>Table 4-2. Datatype representations of event content items</caption><colgroup width="20%" span="1"></colgroup><colgroup width="30%" span="1"></colgroup><colgroup width="50%" span="1"></colgroup><thead><tr><th>Content item</th><th>Used in</th><th>
Datatype representation
</th></tr></thead><tbody><tr><td id="key-nameContentItem">
<em>name</em></td><td>PI, DT, ER</td><td>
<a href="#encodingString"><b>7.1.10 String</b></a></td></tr><tr><td id="key-prefixContentItem">
<em>prefix</em></td><td>NS</td><td>
<a href="#encodingString"><b>7.1.10 String</b></a></td></tr><tr><td id="key-indicatorContentItem">
<em>local-element-ns</em>
</td><td>NS</td><td>
<a href="#encodingBoolean"><b>7.1.2 Boolean</b></a></td></tr><tr><td id="key-publicContentItem">
<em>public</em></td><td>DT</td><td>
<a href="#encodingString"><b>7.1.10 String</b></a></td></tr><tr><td id="key-qnameContentItem">
<em>qname</em></td><td>SE, AT</td><td>
<a href="#encodingQName"><b>7.1.7 QName</b></a></td></tr><tr><td id="key-systemContentItem">
<em>system</em></td><td>DT</td><td>
<a href="#encodingString"><b>7.1.10 String</b></a></td></tr><tr><td id="key-textContentItem">
<em>text</em></td><td>CM, PI, DT</td><td>
<a href="#encodingString"><b>7.1.10 String</b></a></td></tr><tr><td id="key-uriContentItem">
<em>uri</em></td><td>NS</td><td>
<a href="#encodingString"><b>7.1.10 String</b></a></td></tr><tr><td id="key-valueContentItem">
<em>value</em></td><td>CH, AT</td><td>According to the schema datatype (see 
<a href="#encodingValues"><b>7. Representing Event Content</b></a>) if any is in effect, otherwise <a href="#encodingString"><b>7.1.10 String</b></a></td></tr></tbody></table><p>The datatype representation 
used for each <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content item depends on the schema 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#datatype" class="">datatype</a><sup><small>XS2</small></sup> 
if any that is in effect for that <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a>. 
The String datatype representation (see <a href="#encodingString"><b>7.1.10 String</b></a>) 
is used for <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>values</em><span class="arrow"></span></a> that do not have an associated schema datatype, 
cannot be or are opted not to be represented by their associated datatype representations, 
or occur in mixed content. Section 
<a href="#encodingValues"><b>7. Representing Event Content</b></a> describes how each of the types listed above are encoded in an EXI stream. </p><div class="note"><p class="prefix"><b>Note:</b></p>
The syntax and semantics of the NS event are designed to minimize the overhead required for representing namespace prefixes in EXI streams without introducing significant complexity. In the common case where each namespace is bound to a single prefix, this design reduces the overhead for representing all element and attribute namespace prefixes to zero bits.
</div></div><div class="div1">
<h2><a name="header" id="header"></a>5. EXI Header</h2><p>
Each <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a> begins with an EXI header.
<span class="termdef"><a name="key-exiheader" id="key-exiheader">[Definition:]&nbsp;&nbsp;</a>
The <b>EXI header</b> 
can identify EXI streams, 

distinguish EXI 
streams 

from text XML documents, 
identify the version of the EXI format being used, and specify the options used to process the body of the EXI stream.
</span>
The EXI header has the following structure:
</p><table border="1" rules="cols"><tbody><tr><td align="center" rowspan="2">
<a href="#key-exiCookie" class="termref"><span class="arrow"></span>
&nbsp;[&nbsp;EXI&nbsp;Cookie&nbsp;]&nbsp;
<span class="arrow"></span></a>

</td><td align="center" rowspan="2">
<a href="#key-distinguishingbits" class="termref"><span class="arrow"></span>
&nbsp;Distinguishing&nbsp;Bits&nbsp;
<span class="arrow"></span></a></td><td align="center">
&nbsp;Presence&nbsp;Bit&nbsp;
</td><td align="center">
<a href="#key-version" class="termref"><span class="arrow"></span>
&nbsp;EXI&nbsp;Format&nbsp;
<span class="arrow"></span></a>
</td><td align="center" rowspan="2">
&nbsp;[<a href="#key-options" class="termref"><span class="arrow"></span>EXI&nbsp;Options<span class="arrow"></span></a>]&nbsp;
</td><td align="center" rowspan="2">
&nbsp;[Padding&nbsp;Bits]&nbsp;
</td></tr><tr><td align="center">
&nbsp;for&nbsp;EXI&nbsp;Options&nbsp;
</td><td align="center">
<a href="#key-version" class="termref"><span class="arrow"></span>
&nbsp;Version&nbsp;
<span class="arrow"></span></a>
</td></tr></tbody></table><p>The EXI Options field within an EXI header is optional.  Its presence is indicated by
the value of the presence bit that follows <a href="#key-distinguishingbits" class="termref"><span class="arrow"></span>Distinguishing Bits<span class="arrow"></span></a>. The presence and absence is indicated by the value 1 and 0, respectively.  
</p><p>When the <a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression<span class="arrow"></span></a> option is true, or the <a href="#key-alignmentOption" class="termref"><span class="arrow"></span>alignment<span class="arrow"></span></a> option is <a href="#key-bytealignment" class="termref"><span class="arrow"></span>byte-alignment<span class="arrow"></span></a> or <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a>, 
padding bits of minimum length required to make the whole length of 
the header byte-aligned are added at the end of the header. 
On the other hand, there are no padding bits when the alignment in use is <a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a>.
The padding bits field 
if it is present 
can contain any values of bits as its contents.
</p><p>
The details of the 
<a href="#key-exiCookie" class="termref"><span class="arrow"></span>EXI Cookie<span class="arrow"></span></a>, 

<a href="#key-distinguishingbits" class="termref"><span class="arrow"></span>Distinguishing Bits<span class="arrow"></span></a>, <a href="#key-version" class="termref"><span class="arrow"></span>EXI Format Version<span class="arrow"></span></a> and <a href="#key-options" class="termref"><span class="arrow"></span>EXI Options<span class="arrow"></span></a> are described in the following sections.
</p><div class="div2">
<h3><a name="EXICookie" id="EXICookie"></a>5.1 EXI Cookie</h3><p>
<span class="termdef"><a name="key-exiCookie" id="key-exiCookie">[Definition:]&nbsp;&nbsp;</a>
An <a href="#key-exiheader" class="termdef"><span class="arrow"></span>EXI header<span class="arrow"></span></a> MAY start with an <b>EXI Cookie</b>,
which is a four byte field that serves to indicate that the stream of which it is a part is an EXI stream.</span> The four byte field consists of four characters 
"&nbsp;$&nbsp;" , "&nbsp;E&nbsp;", "&nbsp;X&nbsp;" and "&nbsp;I&nbsp;" 

in that order, each represented as an ASCII octet, as follows.
</p><table border="1"><tbody><tr class="bitcell"><td align="center" class="bitcell">'<sup>&nbsp;</sup>$<sub>&nbsp;</sub>'</td><td align="center" class="bitcell">'<sup>&nbsp;</sup>E<sub>&nbsp;</sub>'</td><td align="center" class="bitcell">'<sup>&nbsp;</sup>X<sub>&nbsp;</sub>'</td><td align="center" class="bitcell">'<sup>&nbsp;</sup>I<sub>&nbsp;</sub>'</td></tr></tbody></table><p>
This four byte sequence is particular to EXI and specific enough to distinguish EXI streams from a broad range of data types currently used on the Web. While the EXI cookie is optional, its use is RECOMMENDED in the EXI header when the EXI stream is exchanged in a context where a longer, more specific content-based datatype identifier is desired than that provided by the <a href="#key-distinguishingbits" class="termref"><span class="arrow"></span>Distinguishing Bits<span class="arrow"></span></a>,  whose role is more narrowly focused on distinguishing EXI streams from XML documents.
</p></div><div class="div2">
<h3><a name="DistinguishingBits" id="DistinguishingBits"></a>5.2 Distinguishing Bits</h3><p>
<span class="termdef"><a name="key-distinguishingbits" id="key-distinguishingbits">[Definition:]&nbsp;&nbsp;</a>
The second part in the EXI header is the <b>Distinguishing Bits</b>,
which is a two bit field of which the first bit contains the value 1 and the second bit contains the value 0, as follows.</span>
</p><table border="1"><tbody><tr class="bitcell"><td align="center" class="bitcell">1</td><td align="center" class="bitcell">0</td></tr></tbody></table><p>
Unlike the optional EXI cookie that MAY occur to precede this field, the presence of Distinguishing Bits is REQUIRED in the EXI header. It is used to distinguish EXI  streams from text XML documents in the absence of an <a href="#key-exiCookie" class="termref"><span class="arrow"></span>EXI cookie<span class="arrow"></span></a>.

This two bit sequence is the minimum that suffices to distinguish EXI
streams from XML documents since it is the minimum length bit
pattern that cannot occur as the first two bits of a well-formed XML
document represented in any one of the conventional character
encodings, such as UTF-8, UTF-16, UTF-32, UCS-2, UCS-4, EBCDIC, ISO 8859,
Shift-JIS and EUC, according to 
XML <a href="#XML10">[XML 1.0]</a> &nbsp; <a href="#XML11">[XML 1.1]</a>. 
Therefore, XML Processors that do not support EXI are expected to reject an EXI stream as early as they read
and process the first byte from the stream.</p><p>
Systems that use EXI streams as well as XML documents can reliably look at
the Distinguishing Bits to determine whether to interpret a particular
stream as XML or EXI.
</p></div><div class="div2">
<h3><a name="version" id="version"></a>5.3 EXI Format Version</h3><p><span class="termdef"><a name="key-version" id="key-version">[Definition:]&nbsp;&nbsp;</a>
The fourth part in the EXI header is the <b>EXI Format Version</b>, which identifies the version of the EXI format being used.</span>
EXI format version numbers are integers. Each version of the EXI Format Specification specifies the corresponding EXI format version number to be used by conforming implementations. The EXI format version number that corresponds with this version of the EXI format specification is 1 (one).</p><p>
The first bit of the version field indicates whether the version is a preview or final version of the EXI format.
A value of 0 indicates this is a final version and a value of 1 indicates this is a preview
version. Final versions correspond to final, approved versions of the EXI format specification.
An <a href="#key-exiprocessor" class="termref"><span class="arrow"></span>EXI processor<span class="arrow"></span></a> that implements a final version of the EXI format specification is REQUIRED to process EXI streams that have a version field with its first bit set to 0 followed by a version number that corresponds to the version of the EXI specification the processor implements. The behavior of an EXI processor on an EXI stream with its first bit set to 0 followed by a version not corresponding to a version implemented by the processor is not constrained by this specification. For example, the EXI processor MAY reject such a stream outright or it MAY attempt to process the EXI body.

Preview versions of the EXI format are useful for
gaining implementation and deployment experience prior to finalizing a
particular version of the EXI format. While preview versions may match drafts of this specification, they are not governed by this specification and the behaviour of EXI processors encountering preview versions of the EXI format is implementation dependent. Implementers are free to coordinate to achieve interoperability between different preview versions of the EXI format.
</p><p>Following the first bit of the version is a sequence of one or more
4-bit unsigned integers representing the version number. The version
number is determined by summing this sequence of 4-bit unsigned
values and adding 1 (one). The sequence is terminated by any 4-bit unsigned integer with
a value in the range 0-14. As such, the first 15 version numbers are
represented by 4 bits, the next 15 are represented by 8 bits, etc.</p><p>Given an EXI stream with its stream cursor positioned just past the first bit of the EXI format version field, the EXI format version number can be computed by going through the following steps with version number initially set to 1.</p><ol class="enumar"><li>Read next 4 bits as an unsigned integer value.</li><li>Add the value that was just read to the version number.</li><li>If the value is 15, go to step 1, otherwise (i.e. the value being in the range of 0-14), use the current value of the version number as the EXI version number.</li></ol><p>The following are example EXI format version numbers.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N67273" id="N67273"></a><i><span>Example 5-1. </span>EXI Format Version Examples</i></div><table border="1"><thead><tr><th width="200">EXI Format Version Field</th><th width="200">Description</th></tr></thead><tbody><tr><td>&nbsp;&nbsp;1 0000</td><td>&nbsp;&nbsp;Preview version 1</td></tr><tr><td>&nbsp;&nbsp;0 0000</td><td>&nbsp;&nbsp;Final version 1</td></tr><tr><td>&nbsp;&nbsp;0 1110</td><td>&nbsp;&nbsp;Final version 15</td></tr><tr><td>&nbsp;&nbsp;0 1111 0000</td><td>&nbsp;&nbsp;Final version 16</td></tr><tr><td>&nbsp;&nbsp;0 1111 0001</td><td>&nbsp;&nbsp;Final version 17</td></tr></tbody></table></div><p><a href="#key-exiprocessor" class="termref"><span class="arrow"></span>EXI processors<span class="arrow"></span></a> conforming with the final version of this
specification MUST use the 5-bit value 0 0000 as the version
number.</p></div><div class="div2">
<h3><a name="options" id="options"></a>5.4 EXI Options</h3><p><span class="termdef"><a name="key-options" id="key-options">[Definition:]&nbsp;&nbsp;</a>The 
fifth 

part of the EXI
header is the <b>EXI Options</b>, which provides a way to specify the
options used to encode the body of the EXI stream</span>.
<span class="termdef"><a name="key-optionsDoc" id="key-optionsDoc">[Definition:]&nbsp;&nbsp;</a>

The EXI Options are represented as an <b>EXI Options document</b>, which is an XML document encoded using the EXI format described in this specification.

</span>
This results in a very compact header
format that can be read and written with very little additional software.
</p><p>The presence of EXI Options in its entirety is optional in EXI header,
and it is predicated on the value of the presence bit that follows the
<a href="#key-distinguishingbits" class="termref"><span class="arrow"></span>Distinguishing Bits<span class="arrow"></span></a>.
When EXI Options are present in the header, an EXI Processor MUST observe the
specified options to process the EXI stream that follows. Otherwise,
an EXI Processor may obtain the EXI options using another mechanism. 
There are no fallback option values provided by this specification for use
in the absence of the whole EXI Options part.

</p><p>
<a href="#key-exiprocessor" class="termref"><span class="arrow"></span>EXI processors<span class="arrow"></span></a> MAY provide external means for applications or users to
specify EXI Options when the EXI Options document is absent.
Such <a href="#key-exiprocessor" class="termref"><span class="arrow"></span>EXI processors<span class="arrow"></span></a> are typically used in controlled systems
where the knowledge about the effective EXI Options is shared prior to
the exchange of EXI 
streams . The mechanisms to communicate out-of-band EXI Options and their representation are implementation dependent.</p><p>The following table describes the EXI options that may be specified in the
EXI Options document.</p><a name="exiOptionsInOptionsField" id="exiOptionsInOptionsField"></a><table border="1"><caption>Table 5-1. EXI Options in Options Document</caption><thead><tr><th>EXI Option</th><th>Description</th><th>Default Value</th></tr></thead><tbody><tr><td>
<a href="#key-alignmentOption" class="termref"><span class="arrow"></span>alignment<span class="arrow"></span></a>
</td><td>
Alignment of <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a>
</td><td>
<a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a>
</td></tr><tr><td><a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression<span class="arrow"></span></a></td><td>EXI compression is used to achieve better compactness</td><td>false</td></tr><tr><td><a href="#key-strictOption" class="termref"><span class="arrow"></span>strict<span class="arrow"></span></a></td><td>Strict interpretation of schemas is used to achieve better compactness</td><td>false</td></tr><tr><td><a href="#key-fragmentOption" class="termref"><span class="arrow"></span>fragment<span class="arrow"></span></a></td><td>Body is encoded as an <a href="#key-exifragment" class="termref"><span class="arrow"></span>EXI fragment<span class="arrow"></span></a> instead of an <a href="#key-exidocument" class="termref"><span class="arrow"></span>EXI document<span class="arrow"></span></a>
</td><td>false</td></tr><tr><td><a href="#key-preserveOption" class="termref"><span class="arrow"></span>preserve<span class="arrow"></span></a></td><td>
Specifies whether the support for the preservation of comments, pis, etc. is each enabled

</td><td>all false</td></tr><tr><td><a href="#key-selfContained" class="termref"><span class="arrow"></span>selfContained<span class="arrow"></span></a></td><td>Enables self-contained elements</td><td>false</td></tr><tr><td><a href="#key-schemaIdOption" class="termref"><span class="arrow"></span>schemaId<span class="arrow"></span></a></td><td>Identify the schema information, if any, used to encode the body</td><td>
<em>no default value</em>
</td></tr><tr><td><a href="#key-datatypeRepresentationOption" class="termref"><span class="arrow"></span>
datatypeRepresentationMap
<span class="arrow"></span></a></td><td>
Specify alternate datatype representations for typed <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>values</em><span class="arrow"></span></a> in the <a href="#key-exibody" class="termref"><span class="arrow"></span>EXI body<span class="arrow"></span></a>

</td><td>
<em>no default value</em>
</td></tr><tr><td><a href="#key-blockSizeOption" class="termref"><span class="arrow"></span>blockSize<span class="arrow"></span></a></td><td>Specifies the block size used for EXI compression</td><td>1,000,000</td></tr><tr><td>
<a href="#key-valueMaxLengthOption" class="termref"><span class="arrow"></span>valueMaxLength<span class="arrow"></span></a>

</td><td>
Specifies the maximum string length of 
<a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> 
content items to be considered for addition to the string table.
</td><td>
unbounded

</td></tr><tr><td>
<a href="#key-valuePartitionCapacityOption" class="termref"><span class="arrow"></span>valuePartitionCapacity<span class="arrow"></span></a>
</td><td>
Specifies the total capacity of value partitions in a string table

</td><td>
unbounded

</td></tr><tr><td><a href="#key-userMetaData" class="termref"><span class="arrow"></span>[user defined meta-data]<span class="arrow"></span></a></td><td>User defined meta-data may be added</td><td><em>no default value</em></td></tr></tbody></table><p>Appendix <a href="#optionsSchema"><b>C XML Schema for EXI Options Document</b></a> provides an XML Schema
describing 
<a href="#key-optionsDoc" class="termref"><span class="arrow"></span>the EXI Options document<span class="arrow"></span></a>.
This schema is designed to produce smaller headers
for option combinations used when compactness is critical.</p><p>
The <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a> is
represented as an <a href="#key-exibody" class="termref"><span class="arrow"></span>EXI body<span class="arrow"></span></a> 
 informed by the above mentioned schema using the default options 
specified by the following XML document.
An EXI Options document consists only of an EXI body, and MUST NOT 
start with an EXI header.
</p><div class="reprdef"><div class="reprHeader"><span class="reprdef">Header options used for encoding the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a></span></div><div class="reprBody"><pre>
  &lt;header xmlns="http://www.w3.org/2009/exi"&gt;
    &lt;strict/&gt;
  &lt;/header&gt;
</pre></div></div><p>Note that this specification does not require <a href="#key-exiprocessor" class="termref"><span class="arrow"></span>EXI processors<span class="arrow"></span></a> to read and process the schema prescribed for EXI options document (<a href="#optionsSchema"><b>C XML Schema for EXI Options Document</b></a>), in order to process EXI options documents. EXI processors MUST use the schema-informed grammars that stem from the schema in processing EXI options documents, beyond which there is no requirement as to the use of the schema, and implementations are free to use any methods to retrieve the instructions that observe the grammars for processing EXI options documents. Section <a href="#informedGrammars"><b>8.5 Schema-informed Grammars</b></a> describes the system to derive schema-informed grammars from XML Schemas.
</p><p>Below is a brief description of each EXI option.</p><p><span class="termdef"><a name="key-alignmentOption" id="key-alignmentOption">[Definition:]&nbsp;&nbsp;</a>The <b>alignment option</b> is used to control the alignment of <a href="#key-eventcode" class="termdef"><span class="arrow"></span>event codes<span class="arrow"></span></a> and <a href="#key-content-item" class="termdef"><span class="arrow"></span>content items<span class="arrow"></span></a>.</span> The value is one of <a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a>, <a href="#key-bytealignment" class="termref"><span class="arrow"></span>byte-alignment<span class="arrow"></span></a> or <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a>, of which <a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a> is the default value assumed when the "alignment" element is absent in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a>. 
The option values <a href="#key-bytealignment" class="termref"><span class="arrow"></span>byte-alignment<span class="arrow"></span></a> and <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a> are effected when "byte" and "pre-compress" elements are present in the EXI Options document, respectively. 
When the value of <a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression option<span class="arrow"></span></a> is set to true, alignment of the EXI Body is governed by the rules specified in <a href="#compression"><b>9. EXI Compression</b></a> instead of the alignment option value. The "alignment" element MUST NOT appear in an EXI options document when the "compression" element is present.
</p><p><span class="termdef"><a name="key-unaligned" id="key-unaligned">[Definition:]&nbsp;&nbsp;</a>The alignment option value <b>bit-packed</b> indicates that the <a href="#key-eventcode" class="termdef"><span class="arrow"></span>event codes<span class="arrow"></span></a> and associated content are packed in bits without any padding in-between.</span>
</p><p><span class="termdef"><a name="key-bytealignment" id="key-bytealignment">[Definition:]&nbsp;&nbsp;</a>The alignment option value <b>byte-alignment</b> indicates that the <a href="#key-eventcode" class="termdef"><span class="arrow"></span>event codes<span class="arrow"></span></a> and associated content are aligned on byte boundaries.</span> While byte-alignment generally results in EXI streams of larger sizes compared with their bit-packed equivalents, byte-alignment may provide a help in some use cases that involve frequent copying of large arrays of scalar data directly out of the stream. It can also make it possible to work with data in-place and can make it easier to debug encoded data by allowing items on aligned boundaries to be easily located in the stream.</p><p>
<span class="termdef"><a name="key-precompression" id="key-precompression">[Definition:]&nbsp;&nbsp;</a>The alignment option value <b>pre-compression</b> indicates that all steps involved in compression (see section <a href="#compression"><b>9. EXI Compression</b></a>) are to be done with the exception of the final step of applying the DEFLATE algorithm.</span> The primary use case of pre-compression is to avoid a duplicate compression step when compression capability is built into the transport protocol. In this case, pre-compression just prepares the stream for later compression.
</p><p>
<span class="termdef"><a name="key-compressionOption" id="key-compressionOption">[Definition:]&nbsp;&nbsp;</a>The <b>compression option</b> is a Boolean used to increase compactness using additional computational resources.</span> The default value "false" is assumed when the "compression" element is absent in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a> whereas its presence denotes the value "true". 
When set to true, the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and associated content are compressed according to <a href="#compression"><b>9. EXI Compression</b></a> regardless of the <a href="#key-alignmentOption" class="termref"><span class="arrow"></span>alignment<span class="arrow"></span></a> option value. As mentioned above, the "compression" element MUST NOT appear in an EXI options document when the "alignment" element is present.
</p><p>
<span class="termdef"><a name="key-strictOption" id="key-strictOption">[Definition:]&nbsp;&nbsp;</a>The <b>strict option</b> is a Boolean used to increase compactness by using a strict interpretation of the schemas and omitting preservation of certain items, such as comments, processing instructions and namespace prefixes.</span> The default value "false" is assumed when the "strict" element is absent in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a> 
whereas its presence denotes the value "true". 
When set to true, 
those productions that have NS, CM, PI, ER, and SC terminal symbols are omitted from the
EXI grammars, and schema-informed element and type grammars are restricted to only permit items declared in the schemas. 
A note in section <a href="#addingProductionsStrict"><b>8.5.4.4.2 Adding Productions when Strict is True</b></a> describes some additional restrictions consequential of the use of this option.


The "strict" element MUST NOT appear in an <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI options document<span class="arrow"></span></a> when 
one of "dtd", "prefixes", "comments", "pis" or "selfContained" 
element is present in the same options document.
</p><p>
<span class="termdef"><a name="key-fragmentOption" id="key-fragmentOption">[Definition:]&nbsp;&nbsp;</a>The <b>fragment option</b> is a Boolean that indicates whether the <a href="#key-exibody" class="termdef"><span class="arrow"></span>EXI body<span class="arrow"></span></a> is an <a href="#key-exidocument" class="termdef"><span class="arrow"></span>EXI document<span class="arrow"></span></a> or an <a href="#key-exifragment" class="termdef"><span class="arrow"></span>EXI fragment<span class="arrow"></span></a>.</span>  When set to true, the <a href="#key-exibody" class="termref"><span class="arrow"></span>EXI body<span class="arrow"></span></a> is an <a href="#key-exifragment" class="termref"><span class="arrow"></span>EXI fragment<span class="arrow"></span></a>. Otherwise, the <a href="#key-exibody" class="termref"><span class="arrow"></span>EXI body<span class="arrow"></span></a> is an <a href="#key-exidocument" class="termref"><span class="arrow"></span>EXI document<span class="arrow"></span></a>. The default value "false" is assumed when the "fragment" element is absent in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a> 
whereas its presence denotes the value "true". 
</p><p><span class="termdef"><a name="key-preserveOption" id="key-preserveOption">[Definition:]&nbsp;&nbsp;</a>The <b>preserve option</b> is a set of Booleans that can be set independently 
to each enable or disable a share of the format's capacity determining whether or how certain information items can be preserved in the EXI stream.
</span> 
Section <a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a> describes the set of information items 
affected by the preserve option.
The presence of "dtd", "prefixes", "lexicalValues", "comments" and "pis" in the EXI Options document each turns on fidelity options Preserve.comments, Preserve.pis, Preserve.dtd, Preserve.prefixes and Preserve.lexicalValues whereas the absence denotes turning each off. 
The elements "dtd", "prefixes", "comments" and "pis" 
MUST NOT appear in an <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI options document<span class="arrow"></span></a> when the "strict" element is present in the same options document. 
The element "lexicalValues", on the other hand, is permitted to occur in the presence of "strict" element.
</p><p><span class="termdef"><a name="key-selfContained" id="key-selfContained">[Definition:]&nbsp;&nbsp;</a>The <b>selfContained option</b> is a Boolean used to enable the use of self-contained elements in the EXI stream.</span> Self-contained elements may be read independently from the rest of the EXI body, allowing them to be indexed for random access. The "selfContained" element MUST NOT appear in an <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI options document<span class="arrow"></span></a> when 
one of "compression", "pre-compression" or "strict" elements are present 
in the same options document. The default value "false" is assumed when the "selfContained" element is absent from the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a> 
whereas its presence denotes the value "true". 
</p><p><span class="termdef"><a name="key-schemaIdOption" id="key-schemaIdOption">[Definition:]&nbsp;&nbsp;</a>The <b>schemaId option</b> may be used to identify the schema information used 
for processing 
the EXI body.</span> When the 
"schemaId" element in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI options document<span class="arrow"></span></a> contains the xsi:nil attribute 
with its value set to true, 
no schema information 
is used for processing
the EXI body (i.e. a <a href="#key-schemaless-existream" class="termref"><span class="arrow"></span>schema-less EXI stream<span class="arrow"></span></a>). 
When the value of the "schemaId" element is empty, no user defined schema information is used for processing the EXI body;
however, the built-in XML schema types are available for use in the EXI body.
When the schemaId option is absent (i.e., undefined), no statement is made about the schema information used to encode the EXI body and this information
MUST be communicated out of band.
This specification does not dictate the syntax or semantics of other values specified in this field. An example schemaId scheme is the use of URI that is apt for globally identifying schema resources on the Web.
The parties involved in the exchange are free to agree on the scheme of schemaId field that is appropriate for their use to uniquely identify the schema information. 
</p><p><span class="termdef"><a name="key-datatypeRepresentationOption" id="key-datatypeRepresentationOption">[Definition:]&nbsp;&nbsp;</a>The <b>
datatypeRepresentationMap option</b> 
specifies an alternate set of datatype representations for typed
<a href="#key-valueContentItem" class="termdef"><span class="arrow"></span><em>values</em><span class="arrow"></span></a> in 
the <a href="#key-exibody" class="termdef"><span class="arrow"></span>EXI body<span class="arrow"></span></a> 
as described in <a href="#datatypeRepresentationMap"><b>7.4 Datatype Representation Map</b></a>.</span>
When there are no "datatypeRepresentationMap" elements in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a>, no Datatype Representation Map is used for processing the EXI body.
This option does not take effect when the value of the Preserve.lexicalValues fidelity option is true (see <a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a>), 
or when  the <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a> is a <a href="#key-schemaless-existream" class="termref"><span class="arrow"></span>schema-less EXI stream.<span class="arrow"></span></a>

</p><p><span class="termdef"><a name="key-blockSizeOption" id="key-blockSizeOption">[Definition:]&nbsp;&nbsp;</a>The <b>blockSize option</b> specifies the block size used for EXI compression.</span> When the "blockSize" element is absent in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a>, the default blocksize of 1,000,000 is used. The default blockSize is intentionally large but can be reduced for processing large documents on devices with limited memory.</p><p>

<span class="termdef"><a name="key-valueMaxLengthOption" id="key-valueMaxLengthOption">[Definition:]&nbsp;&nbsp;</a>
The <b>valueMaxLength option</b> specifies the maximum length of <a href="#key-valueContentItem" class="termdef"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content items to be considered for addition to the string table.
</span> 
The default value "unbounded" is assumed when the "valueMaxLength" element is absent in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a>.
</p><p>
<span class="termdef"><a name="key-valuePartitionCapacityOption" id="key-valuePartitionCapacityOption">[Definition:]&nbsp;&nbsp;</a>
The <b>valuePartitionCapacity option</b> specifies the maximum number of <a href="#key-valueContentItem" class="termdef"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content items in the string table at any given time.
</span>
The default value "unbounded" is assumed when the "valuePartitionCapacity" element is absent in the <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a>. 
Section <a href="#encodingOptimizedForMisses"><b>7.3.3 Partitions Optimized for Frequent use of String Literals</b></a> specifies the behavior of the string table when this capacity is reached.




</p><p>
<span class="termdef"><a name="key-userMetaData" id="key-userMetaData">[Definition:]&nbsp;&nbsp;</a>
The <b>user defined meta-data</b> conveys auxiliary information that applications may use to facilitate interpretation of the EXI stream. 
</span> 
The user defined meta-data MUST NOT be interpreted in a way that alters or extends the EXI data format defined in this specification. 
User defined meta-data may be added to an EXI Options document just prior to the <a href="#key-alignmentOption" class="termref"><span class="arrow"></span>alignment<span class="arrow"></span></a> option. 
</p></div></div><div class="div1">
<h2><a name="encodingEvents" id="encodingEvents"></a>6. Encoding EXI Streams</h2><p>The rules for encoding a series of <a href="#key-exievent" class="termref"><span class="arrow"></span>events<span class="arrow"></span></a> as an <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a> are very
simple and are driven by a declarative set of grammars that describes
the structure of an <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a>. Every <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a> in the stream is
encoded using the same set of encoding rules, which are summarized as
follows: </p><ol class="enumar"><li>Get the next event 
data 
to be encoded</li><li>If fidelity options (see <a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a>) indicate this event type is not processed,
go to step 1
</li><li>Use the grammars to determine the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of the <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a></li><li>Encode the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> followed by the event content (see <a href="#eventTypes">Table 4-1</a>)</li><li>Evaluate the grammar production matched by the <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a></li><li>Repeat until the End Document (ED) event is encoded</li></ol><p>Self-contained (SC), namespace (NS) and attribute (AT) events associated with a given element occur directly after the start element (SE) event in the following order:</p><table border="1" rules="cols"><tbody><tr><td align="center" width="50" height="30">SC</td><td align="center" width="50">NS</td><td align="center" width="50">NS</td><td align="center" width="50">...</td><td align="center" width="50">NS</td><td align="center" width="100">
AT (xsi:type)
</td><td align="center" width="100">
AT (xsi:nil)
</td><td align="center" width="50">AT</td><td align="center" width="50">AT</td><td align="center" width="50">...</td><td align="center" width="50">AT</td></tr></tbody></table><p>Namespace (NS) events occur in document order. 
The xsi:type and xsi:nil attributes 
occur before all other AT events. 
When the grammar currently in effect for the element is either a <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> (see <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>) or a <a href="#key-informed-elem-fragment-grammar" class="termref"><span class="arrow"></span>schema-informed element fragment grammar<span class="arrow"></span></a> (see <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>), the remaining attribute (AT) events can occur in any order. Otherwise, when the grammar in effect is a <a href="#key-informedElementGrammar" class="termref"><span class="arrow"></span>schema-informed element grammar<span class="arrow"></span></a> or a <a href="#key-informedTypeGrammar" class="termref"><span class="arrow"></span>schema-informed type grammar<span class="arrow"></span></a> (see <a href="#informedElemGrammars"><b>8.5.4 Schema-informed Element and Type Grammars</b></a>), the remaining attributes can occur in any order that is permitted by the grammar, though in practice they SHOULD occur in lexicographical order sorted first by <em>qname</em> local-name then by <em>qname</em> uri for achieving better compactness, where a <em>qname</em> is a <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of an attribute.
</p><div class="note"><p class="prefix"><b>Note:</b></p>
Under certain cirmcumstances, it is not strictly required that the xsi:type or xsi:nil attributes occur before other AT events of the same element. See the notes in section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a> for details.
</div><p>EXI uses the same simple procedure described above, to encode well-formed documents, document fragments, schema-valid information items, schema-invalid information items, information items partially described by schemas and information items with no schema at all. Only the grammars that describe these items differ. For example, an element with no schema information is encoded according to the XML grammar defined by the XML specification, while an element with schema information is encoded according to the more specific grammar defined by that schema. </p><p><span class="termdef"><a name="key-eventcode" id="key-eventcode">[Definition:]&nbsp;&nbsp;</a>An <b>event code</b> is a sequence of 1 to 3 non-negative integers called parts used to identify each event in an EXI stream. The EXI grammars describe which events may occur at each point in an EXI stream and associate an even code with each one.</span> 
(See <a href="#grammarEventCodes"><b>8.2 Grammar Event Codes</b></a> for more description of event codes.) 

</p><p>Section <a href="#eventCodes"><b>6.1 Determining Event Codes</b></a> describes in detail how the grammar is used to determine the event code of an <a href="#key-exievent" class="termref"><span class="arrow"></span>event<span class="arrow"></span></a>. Section <a href="#encodingEventCodes"><b>6.2 Representing Event Codes</b></a> describes in detail how event codes are represented as bits. Section 
<a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a> describes available fidelity options and how they 
affect 
the EXI stream. Section <a href="#encodingValues"><b>7. Representing Event Content</b></a> describes how the typed event contents are represented as bits. </p><div class="div2">
<h3><a name="eventCodes" id="eventCodes"></a>6.1 Determining Event Codes</h3><p>The structure of an EXI stream is described by the EXI grammars, which are formally specified in section 
<a href="#grammars"><b>8. EXI Grammars</b></a>. Each grammar defines which events are permitted to occur at any given point in the EXI stream and provides a pre-assigned <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> for each one.
</p><p>For example, the grammar productions below describe the events that can occur in a schema-informed EXI stream after the Start-Document (SD) event provided there are four global elements defined in the schema and assign an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> for each one. 
See <a href="#informedDocGrammars"><b>8.5.1 Schema-informed Document Grammar</b></a> for the process used for generating the grammar productions below from the schema.
</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N68226" id="N68226"></a><i><span>Example 6-1. </span>Example productions with event codes</i></div><table width="95%"><thead><tr><th colspan="4">&nbsp;</th></tr><tr><th align="left" colspan="3">&nbsp;&nbsp;Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="3"><em>DocContent</em></td></tr><tr><td></td><td width="5%"></td><td width="75%">SE ("A") 
<em>DocEnd</em></td><td>0</td></tr><tr><td></td><td width="5%"></td><td width="75%">SE ("B") 
<em>DocEnd</em></td><td>1</td></tr><tr><td></td><td width="5%"></td><td width="75%">SE ("C") 
<em>DocEnd</em></td><td>2</td></tr><tr><td></td><td width="5%"></td><td width="75%">SE ("D") 
<em>DocEnd</em></td><td>3</td></tr><tr><td></td><td width="5%"></td><td width="75%">SE&nbsp;(*) 
<em>DocEnd</em></td><td>4</td></tr><tr><td></td><td></td><td>DT 
<em>DocContent</em></td><td>5.0</td></tr><tr><td></td><td></td><td>CM 
<em>DocContent</em></td><td>5.1.0</td></tr><tr><td></td><td></td><td>PI 
<em>DocContent</em></td><td>5.1.1</td></tr></tbody></table></div><p>At the point in an EXI stream where the above grammar productions are in effect, the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of Start Element "A" (i.e. SE("A")) is 0. The event code of a DOCTYPE (DT) event at this point in the stream is 5.0, and so on. 
</p></div><div class="div2">
<h3><a name="encodingEventCodes" id="encodingEventCodes"></a>6.2 Representing Event Codes</h3><p>Each <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> is represented by a sequence of 1 to 3 parts that uniquely identify an event. 

<a href="#key-eventcode" class="termref"><span class="arrow"></span>Event code<span class="arrow"></span></a> parts are encoded in order starting with the first part followed by subsequent parts.</p><p>

The 
<em>i</em>-th part of an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> is encoded as an <em>n</em>-bit unsigned integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where 
<em>n</em> is &lceil;&nbsp;log<sub>&nbsp;2</sub>&nbsp;<em>m</em>&nbsp;&rceil; and <em>m</em> is the number of distinct values used as the 
<em>i</em>-th part of its own and all its sibling event codes in the current grammar.

Two <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> are siblings at the <em>i</em>-th part if and only if they share the same values in all preceding parts. All <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> are siblings at the first part.
</p><p>
If there is only one distinct value for a given part, the part is omitted (i.e., encoded in log<sub>&nbsp;2</sub>&nbsp;1 =&nbsp;0&nbsp;bits =&nbsp;0&nbsp;bytes).
</p><p>For example, the eight  <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> shown in the 
<em>DocContent</em> grammar above have values ranging from 0 to 5 for the first part. Six distinct values are needed to identify the first part of these <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a>. 
Therefore, the first part can be encoded as an <em>n</em>-bit unsigned integer where <em>n</em> = &lceil;&nbsp;log<sub>&nbsp;2</sub>&nbsp;6&nbsp;&rceil; =&nbsp;3. In the same fashion, the second and third part (if present) are represented as <em>n</em>-bit unsigned integers where <em>n</em> is &lceil;&nbsp;log<sub>&nbsp;2</sub>&nbsp;2&nbsp;&rceil; =&nbsp;1&nbsp; and &lceil;&nbsp;log<sub>&nbsp;2</sub>&nbsp;2&nbsp;&rceil; =&nbsp;1&nbsp; respectively.
</p><p>
When the value of the <a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression option<span class="arrow"></span></a> is false and <a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a> alignment is used, <em>n</em>-bit unsigned integers are represented using <em>n</em> bits. The first table below illustrates how the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> of each 
event matched by the <em>DocContent</em> grammar above are represented in this case.</p><p>
When the value of <a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression option<span class="arrow"></span></a> is true, or either <a href="#key-bytealignment" class="termref"><span class="arrow"></span>byte-alignment<span class="arrow"></span></a> or <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a> alignment option is used, <em>n</em>-bit unsigned integers are represented using the minimum number of bytes required to store <em>n</em> bits. The second table below illustrates how the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> of each 
event matched by the <em>DocContent</em> grammar above are represented in this case. </p><div class="exampleOuter">
<div class="exampleHeader"><a name="N68561" id="N68561"></a><i><span>Example 6-2. </span>Example event code encoding</i></div><p></p><table border="1" width="95%"><caption>Table 6-1. Example event code encoding 
when EXI compression is not in effect and <a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a> alignment option is used
</caption><colgroup span="1"></colgroup><colgroup span="3" align="center"></colgroup><colgroup span="1"></colgroup><colgroup align="center" span="1"></colgroup><thead><tr><th width="30%">Event</th><th colspan="3">Part values</th><th width="40%">Event Code Encoding</th><th width="10%"># bits</th></tr></thead><tbody><tr><td>SE ("A")</td><td>0</td><td>&nbsp;</td><td>&nbsp;</td><td>000</td><td>3</td></tr><tr><td>SE ("B")</td><td>1</td><td>&nbsp;</td><td>&nbsp;</td><td>001</td><td>3</td></tr><tr><td>SE ("C")</td><td>2</td><td>&nbsp;</td><td>&nbsp;</td><td>010</td><td>3</td></tr><tr><td>SE ("D")</td><td>3</td><td>&nbsp;</td><td>&nbsp;</td><td>011</td><td>3</td></tr><tr><td>SE&nbsp;(*)</td><td>4</td><td>&nbsp;
</td><td>&nbsp;</td><td>100
</td><td>3</td></tr><tr><td>DT</td><td>5</td><td>0</td><td>&nbsp;</td><td>101&nbsp;&nbsp;0</td><td>4</td></tr><tr><td>CM</td><td>5</td><td>1</td><td>0</td><td>101&nbsp;&nbsp;1&nbsp;&nbsp;0</td><td>5</td></tr><tr><td>PI</td><td>5</td><td>1</td><td>1</td><td>101&nbsp;&nbsp;1&nbsp;&nbsp;1</td><td>5</td></tr></tbody></table><table border="1" width="95%"><colgroup span="1"></colgroup><colgroup span="3" align="center"></colgroup><colgroup span="1"></colgroup><colgroup span="1"></colgroup><tbody><tr><td width="30%"># distinct values (<em>m</em>)</td><td>6</td><td>2</td><td>2</td><td width="40%">&nbsp;</td><td width="10%">&nbsp;</td></tr><tr><td><table border="0"><tr><td># bits per part</td></tr><tr><td>&nbsp;&nbsp;&lceil; log <sub>2</sub>&nbsp;<em>m</em> &rceil;</td></tr></table></td><td>3</td><td>1</td><td>1</td><td>&nbsp;</td><td>&nbsp;</td></tr></tbody></table><p></p><table border="1" width="95%"><caption>Table 6-2. Example event code encoding 
when EXI compression is in effect, or either
<a href="#key-bytealignment" class="termref"><span class="arrow"></span>byte-alignment<span class="arrow"></span></a> or <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a> alignment option is used
</caption><colgroup span="1"></colgroup><colgroup span="3" align="center"></colgroup><colgroup span="1"></colgroup><colgroup align="center" span="1"></colgroup><thead><tr><th width="30%">Event</th><th colspan="3">Part values</th><th width="40%">Event Code Encoding</th><th width="10%"># bytes</th></tr></thead><tbody><tr><td>SE ("A")</td><td>0</td><td>&nbsp;</td><td>&nbsp;</td><td>00000000</td><td>1</td></tr><tr><td>SE ("B")</td><td>1</td><td>&nbsp;</td><td>&nbsp;</td><td>00000001</td><td>1</td></tr><tr><td>SE ("C")</td><td>2</td><td>&nbsp;</td><td>&nbsp;</td><td>00000010</td><td>1</td></tr><tr><td>SE ("D")</td><td>3</td><td>&nbsp;</td><td>&nbsp;</td><td>00000011</td><td>1</td></tr><tr><td>SE&nbsp;(*)</td><td>4</td><td>&nbsp;</td><td>&nbsp;</td><td>00000100
</td><td>1</td></tr><tr><td>DT</td><td>5</td><td>0</td><td>&nbsp;</td><td>00000101&nbsp;&nbsp;00000000</td><td>2</td></tr><tr><td>CM</td><td>5</td><td>1</td><td>0</td><td>00000101&nbsp;&nbsp;00000001&nbsp;&nbsp;00000000</td><td>3</td></tr><tr><td>PI</td><td>5</td><td>1</td><td>1</td><td>00000101&nbsp;&nbsp;00000001&nbsp;&nbsp;00000001</td><td>3</td></tr></tbody></table><table border="1" width="95%"><colgroup span="1"></colgroup><colgroup span="3" align="center"></colgroup><colgroup span="1"></colgroup><colgroup span="1"></colgroup><tbody><tr><td width="30%"># distinct values (<em>m</em>)</td><td>6</td><td>2</td><td>2</td><td width="40%">&nbsp;</td><td width="10%">&nbsp;</td></tr><tr><td><table border="0"><tr><td># bytes per part</td></tr><tr><td>&nbsp;&nbsp;&lceil; (log <sub>2</sub>&nbsp;<em>m</em>) / 8 &rceil;</td></tr></table></td><td>1</td><td>1</td><td>1</td><td>&nbsp;</td><td>&nbsp;</td></tr></tbody></table></div></div><div class="div2">
<h3><a name="fidelityOptions" id="fidelityOptions"></a>6.3 Fidelity Options</h3><p>Some XML applications do not require the entire XML feature set and would prefer to eliminate the overhead associated with unused features. For example, the SOAP 1.2 specification 
<a href="#soap12">[SOAP 1.2]</a> prohibits the use of XML 
processing instructions. 
In addition, there are many data-exchange use cases that do not require XML comments or DTDs. </p><p>
The <a href="#key-preserveOption" class="termref"><span class="arrow"></span>preserve option<span class="arrow"></span></a> in EXI Options comprises a set of fidelity options, each of which independently 
enables or disables the format's capacity for 
the preservation (or preservation level) of a certain type of information item. 
Applications can use the <a href="#key-preserveOption" class="termref"><span class="arrow"></span>preserve option<span class="arrow"></span></a> to specify the set of fidelity options they require.
As specified in section 
<a href="#pruningProductions"><b>8.3 Pruning Unneeded Productions</b></a>, EXI processors MUST use these fidelity options to prune 
productions that match the associated events from the grammars, improving compactness and processing efficiency. </p><p>The table below lists the fidelity options supported by this version of the EXI specification and describes the effect setting these options has on the <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a>. </p><table border="1"><caption>Table 6-3. Fidelity options</caption><thead><tr><th>Fidelity option</th><th>Effect</th></tr></thead><tbody><tr><td id="key-preserveCommentsOption">Preserve.comments</td><td>CM events can be preserved</td></tr><tr><td id="key-preservePIsOption">Preserve.pis</td><td>PI events can be preserved</td></tr><tr><td id="key-preserveDTDOption">Preserve.dtd</td><td>DT and ER events can be preserved</td></tr><tr><td id="key-preservePrefixesOption">Preserve.prefixes</td><td>NS events and namespace prefixes can be preserved</td></tr><tr><td id="key-preserveLexicalValuesOption">Preserve.lexicalValues</td><td>Lexical form of element and attribute values can be preserved in <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content items
</td></tr></tbody></table><p>
When <a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/#dt-qualname" class="">qualified names</a><sup><small>NS</small></sup> are used in the <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em>s<span class="arrow"></span></a> of AT or CH events in an EXI Stream, the Preserve.prefixes fidelity option SHOULD be turned on to enable the preservation of the NS prefix declarations used by these values. 
Note, in particular among other cases, that this practice applies to the use of xsi:type attributes in EXI streams when Preserve.lexicalValues fidelity option is set to <em>true</em>.
</p><p>See section <a href="#streams"><b>4. EXI Streams</b></a> for the definition of EXI event types and their associated <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a>.
</p></div></div><div class="div1">
<h2><a name="encodingValues" id="encodingValues"></a>7. Representing Event Content</h2><p>
The <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of each event in an EXI body is represented as a sequence of 
<em>n</em>-bit unsigned integers (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>).
See section <a href="#encodingEventCodes"><b>6.2 Representing Event Codes</b></a> for the description of the event code representation. 
The <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> of an event are represented according to their datatype representations (see <a href="#table2">Table 4-2</a>). In the absence of an associated datatype representation, attribute and character <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>values</em><span class="arrow"></span></a> are 
represented as String (<a href="#encodingString"><b>7.1.10 String</b></a>).
</p><p><span class="termdef"><a name="key-exidatatype" id="key-exidatatype">[Definition:]&nbsp;&nbsp;</a>EXI defines a minimal set of datatype representations called 
<b>Built-in EXI datatype representations</b> that define how 
<a href="#key-content-item" class="termdef"><span class="arrow"></span>content items<span class="arrow"></span></a>
as well as the parts of an <a href="#key-eventcode" class="termdef"><span class="arrow"></span>event code<span class="arrow"></span></a> 
are represented in EXI streams.</span> 
When the <a href="#key-preserveLexicalValuesOption" class="termref"><span class="arrow"></span>Preserve.lexicalValues<span class="arrow"></span></a> option is false, 
<a href="#key-valueContentItem" class="termref"><span class="arrow"></span>values<span class="arrow"></span></a> are represented using built-in EXI datatype representations 
(see <a href="#encodingDatatypes"><b>7.1 Built-in EXI Datatype Representations</b></a>) or user-defined datatype representations 
(see <a href="#datatypeRepresentationMap"><b>7.4 Datatype Representation Map</b></a>) associated with the schema 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#datatype" class="">datatypes</a><sup><small>XS2</small></sup>. 
 
Otherwise, 
<a href="#key-valueContentItem" class="termref"><span class="arrow"></span>values<span class="arrow"></span></a>
are represented as Strings with restricted character sets (see <a href="#builtInRestrictedStrings">Table 7-2</a> below). The following table lists the 
built-in EXI datatype representations, associated 
EXI datatype identifiers 
and the XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-datatypes" class="">built-in datatypes</a><sup><small>XS2</small></sup> 
each 
EXI datatype representation
is used to represent by default.</p><a name="builtInEXITypes" id="builtInEXITypes"></a><table border="1"><caption>Table 7-1. 
Built-in EXI Datatype Representations
</caption><thead><tr><th>
Built-in EXI Datatype Representation

</th><th>EXI Datatype ID</th><th colspan="2">
XML Schema Datatypes 
</th></tr></thead><tbody><tr><td rowspan="2">
<a href="#encodingBinary">Binary</a>
</td><td>
exi:base64Binary
</td><td colspan="2"><em>base64Binary</em></td></tr><tr><td>
exi:hexBinary
</td><td colspan="2"><em>hexBinary</em></td></tr><tr><td>
<a href="#encodingBoolean">Boolean</a>
</td><td>
exi:boolean
</td><td colspan="2"><em>boolean</em></td></tr><tr><td rowspan="8">
<a href="#encodingDateTime">Date-Time</a>
</td><td>
exi:dateTime
</td><td colspan="2"><em>dateTime</em></td></tr><tr><td>
exi:time
</td><td colspan="2"><em>time</em></td></tr><tr><td>
exi:date
</td><td colspan="2"><em>date</em></td></tr><tr><td>
exi:gYearMonth
</td><td colspan="2"><em>gYearMonth</em></td></tr><tr><td>
exi:gYear
</td><td colspan="2"><em>gYear</em></td></tr><tr><td>
exi:gMonthDay
</td><td colspan="2"><em>gMonthDay</em></td></tr><tr><td>
exi:gDay
</td><td colspan="2"><em>gDay</em></td></tr><tr><td>
exi:gMonth
</td><td colspan="2"><em>gMonth</em></td></tr><tr><td>
<a href="#encodingDecimal">Decimal</a>
</td><td>
exi:decimal
</td><td colspan="2"><em>decimal</em></td></tr><tr><td>
<a href="#encodingFloat">Float</a>
</td><td>
exi:double
</td><td colspan="2"><em>float</em>, <em>double</em></td></tr><tr><td>
<a href="#encodingInteger">Integer</a>
</td><td>
exi:integer
</td><td colspan="2">
<em>integer</em>
</td></tr><tr><td>
<a href="#encodingString">String</a>
</td><td>
exi:string
</td><td colspan="2">
<em>string</em>, <em>anySimpleType</em> and all types derived by <em>union</em>
</td></tr><tr><td>
<a href="#encodingBoundedUnsigned">n-bit Unsigned Integer</a>
</td><td>&nbsp;</td><td colspan="2">
Not associated with any datatype directly, but used by <a href="#encodingInteger">Integer</a>
 datatype representation for some bounded <em>integers</em> (see <a href="#encodingInteger"><b>7.1.5 Integer</b></a>)
</td></tr><tr><td>
<a href="#encodingUnsignedInteger">Unsigned Integer</a>
</td><td>&nbsp;</td><td colspan="2">
Not associated with any datatype directly, but used by <a href="#encodingInteger">Integer</a>
 datatype representation for unsigned <em>integers</em> (see <a href="#encodingInteger"><b>7.1.5 Integer</b></a>)
</td></tr><tr><td>
<a href="#encodingList">List</a>
</td><td>&nbsp;</td><td colspan="2">All types derived by <em>list</em>, including 
<em>NMTOKENS</em>, <em>IDREFS</em> and <em>ENTITIES</em></td></tr><tr><td>
<a href="#encodingQName">QName</a>
</td><td>&nbsp;</td><td colspan="2">
xsi:type attribute values when <a href="#key-preserveLexicalValuesOption" class="termref"><span class="arrow"></span>Preserve.lexicalValues<span class="arrow"></span></a> option value is <em>false</em>


 
 

&nbsp;</td></tr></tbody></table><p>By default, datatypes derived from the XML Schema datatypes above are also represented according to the associated <a href="#key-exidatatype" class="termref"><span class="arrow"></span>built-in EXI datatype representation<span class="arrow"></span></a>. When there are more than one XML Schema datatypes above from which a datatype is derived directly or indirectly, the closest ancestor is used to determine the <a href="#key-exidatatype" class="termref"><span class="arrow"></span>built-in EXI datatype representation<span class="arrow"></span></a>. For example, a value of XML Schema datatype xsd:int is represented according to the same <a href="#key-exidatatype" class="termref"><span class="arrow"></span>built-in EXI datatype representation<span class="arrow"></span></a> as a value of XML Schema datatype xsd:integer. Although xsd:int is derived indirectly from xsd:integer and also further from xsd:decimal, a value of xsd:int is processed as an instance of xsd:integer because xsd:integer is closer to xsd:int than xsd:decimal is in the datatype inheritance hierarchy.</p><p>Each EXI datatype identifier above is a <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> that uniquely identifies one of the 
<a href="#key-exidatatype" class="termref"><span class="arrow"></span>built-in EXI datatype representations.<span class="arrow"></span></a> 
EXI datatype identifiers are used in <a href="#key-datatypeRepresentationMaps" class="termref"><span class="arrow"></span>Datatype Representation Maps<span class="arrow"></span></a> to 
change
the datatype representations used for specific schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#datatype" class="">datatypes</a><sup><small>XS2</small></sup> and their sub-types.
Only <a href="#key-exidatatype" class="termref"><span class="arrow"></span>built-in EXI datatype representations<span class="arrow"></span></a>
 that have been assigned identifiers are usable in <a href="#key-datatypeRepresentationMaps" class="termref"><span class="arrow"></span>Datatype Representation Maps<span class="arrow"></span></a>.
</p><p>When the <a href="#key-preserveLexicalValuesOption" class="termref"><span class="arrow"></span>Preserve.lexicalValues<span class="arrow"></span></a> option is true, all 
<a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>values</em><span class="arrow"></span></a> 
are represented as Strings. 

The table below defines restricted character sets for several of the built-in EXI datatypes. Each <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> that would have otherwise been represented by one of these datatypes is instead represented as a String with the associated restricted character set,
regardless of the actual pattern facets, if any, specified in the definitions of the schema datatypes. 
</p><a name="builtInRestrictedStrings" id="builtInRestrictedStrings"></a><table border="1" width="95%"><caption>Table 7-2. Restricted Character Sets for Built-in EXI 
Datatype Representations

</caption><colgroup width="20%" span="1"></colgroup><colgroup width="80%" span="1"></colgroup><thead><tr><th>EXI Datatype ID</th><th>Restricted Character Set</th></tr></thead><tbody><tr><td>
exi:base64Binary
</td><td>{ #x9, #xA, #xD, #x20, +, /, [0-9], =, [A-Z], [a-z] } </td></tr><tr><td>
exi:hexBinary
</td><td>{ #x9, #xA, #xD, #x20, [0-9], [A-F], [a-f] } </td></tr><tr><td>
exi:boolean
</td><td>{ #x9, #xA, #xD, #x20, 0, 1, a, e, f, l, r, s, t, u } </td></tr><tr><td>
exi:dateTime
</td><td rowspan="8">{ #x9, #xA, #xD, #x20, +, -, ., [0-9], :, T, Z } </td></tr><tr><td>
exi:time
</td></tr><tr><td>
exi:date
</td></tr><tr><td>
exi:gYearMonth
</td></tr><tr><td>
exi:gYear
</td></tr><tr><td>
exi:gMonthDay
</td></tr><tr><td>
exi:gDay
</td></tr><tr><td>
exi:gMonth
</td></tr><tr><td>
exi:decimal
</td><td>{ #x9, #xA, #xD, #x20, +, -, ., [0-9] } </td></tr><tr><td>
exi:double
</td><td>{ #x9, #xA, #xD, #x20, +, -, ., [0-9], E, F, I, N, a, e } </td></tr><tr><td>
exi:integer
</td><td>{ #x9, #xA, #xD, #x20, +, -, [0-9] } </td></tr></tbody></table><p>The restricted character set for the EXI List datatype representation is the restricted character set of the EXI datatype representation of the List item type.
</p><p>The rules used to represent values of String depend on the <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> to which the values belong. There are certain <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> whose value representation involve the use of string tables while other <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> are represented using the encoding rule described in <a href="#encodingString"><b>7.1.10 String</b></a> without involvement of string tables. The <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> that use string tables and how each of such <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> uses string tables to represent their values are described in <a href="#stringTable"><b>7.3 String Table</b></a>.</p><p>Schemas can provide one or more enumerated values for 
datatypes. 
When the <a href="#key-preserveLexicalValuesOption" class="termref"><span class="arrow"></span>Preserve.lexicalValues<span class="arrow"></span></a> option is false, 
EXI exploits those pre-defined values when they are available to represent values of such 
datatypes 
in a more efficient manner than 
would have done otherwise without using pre-defined values. 
The encoding rule for representing 
enumerated values 
is described in <a href="#encodingEnumerations"><b>7.2 Enumerations</b></a>. 
Datatypes 
that are derived from 
another 
by union and their subtypes are always represented as String regardless of the availability of enumerated values. Representation of values of which the 
datatype 
is one of QName, Notation or a 
datatype 
derived therefrom by restriction are also not affected by enumerated values if any.
</p><div class="div2">
<h3><a name="encodingDatatypes" id="encodingDatatypes"></a>7.1 Built-in EXI Datatype Representations</h3><p>The following sections describe the <a href="#key-exidatatype" class="termref"><span class="arrow"></span>built-in EXI datatype representations<span class="arrow"></span></a> used for representing 
<a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> in EXI streams. Unless otherwise stated, individual items in an EXI stream are packed into bytes most significant bit first.

</p><div class="div3">
<h4><a name="encodingBinary" id="encodingBinary"></a>7.1.1 Binary</h4><p>The Binary datatype representation is a length-prefixed sequence of octets representing the binary content. The length is represented as an Unsigned Integer (see 
<a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>). </p></div><div class="div3">
<h4><a name="encodingBoolean" id="encodingBoolean"></a>7.1.2 Boolean</h4><p>In the absence of pattern facets in the schema datatype, the Boolean datatype representation is a  <em>n</em>-bit unsigned integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where <em>n</em> is one (1). The value zero (0) represents false and the value one (1) represents true.
</p><p>Otherwise, when pattern facets are available in the schema datatype, the Boolean datatype representation is a <em>n</em>-bit unsigned integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where <em>n</em> is two (2) and the values zero (0), one (1), two (2) and three (3) represent the values "false", "0", "true" and "1" respectively.
</p></div><div class="div3">
<h4><a name="encodingDecimal" id="encodingDecimal"></a>7.1.3 Decimal</h4><p>The Decimal datatype representation is a Boolean sign (see <a href="#encodingBoolean"><b>7.1.2 Boolean</b></a>) followed by two Unsigned Integers (see <a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>). A sign value of zero (0) is used to represent positive Decimal values and a sign value of one (1) is used to represent negative Decimal values. The first Unsigned Integer represents the integral portion of the Decimal value. The second Unsigned Integer represents the fractional portion of the Decimal value with the digits in reverse order to preserve leading zeros.</p></div><div class="div3">
<h4><a name="encodingFloat" id="encodingFloat"></a>7.1.4 Float</h4><p>The Float datatype representation is two consecutive Integers (see 
<a href="#encodingInteger"><b>7.1.5 Integer</b></a>). The first Integer represents the mantissa of the floating point number and the second Integer represents the base-10 exponent of the floating point number. The range of the mantissa is - (2<sup>63</sup>) to 2<sup>63</sup>-1 and the range of the exponent is - (2<sup>14</sup>-1) to 2<sup>14</sup>-1. 
Mantissa or exponent values outside of the respective accepted range MUST NOT be used in the Float datatype representation. Values typed as Float with a mantissa or exponent outside the accepted range are represented as untyped values, processed by an alternative production if available that can be used to represent untyped values. 

Examples of such productions are those whose terminal symbol on the right-hand side is AT(<em>qname</em>) [untyped&nbsp;value], AT(*) [untyped&nbsp;value] or CH [untyped&nbsp;value] (See <a href="#addingProductions"><b>8.5.4.4.1 Adding Productions when Strict is False</b></a>).
</p><p>The exponent value -(2<sup>14</sup>) is used to indicate one of the special values: infinity, negative infinity and not-a-number (NaN). An exponent value -(2<sup>14</sup>) with mantissa values 1 and -1 represents 
positive infinity (INF) and negative infinity (-INF) respectively. An exponent value -(2<sup>14</sup>) with any other mantissa value represents NaN.
</p><p>The Float datatype representation can be decoded by going through the following steps.</p><ol class="enumar"><li>Retrieve the mantissa value using the procedure described in <a href="#encodingInteger"><b>7.1.5 Integer</b></a>.</li><li>Retrieve the exponent value using the procedure described in <a href="#encodingInteger"><b>7.1.5 Integer</b></a>.</li><li>If the exponent value is -(2<sup>14</sup>), the mantissa value 1 represents INF, the mantissa value -1 represents -INF and any other mantissa value represents NaN. If the exponent value is not -(2<sup>14</sup>), the float value is <em>m</em> &times; 10<sup><em>e</em></sup> where <em>m</em> is the mantissa and <em>e</em> is the exponent obtained in the preceding steps.
</li></ol></div><div class="div3">
<h4><a name="encodingInteger" id="encodingInteger"></a>7.1.5 Integer</h4><p>The Integer datatype representation supports signed integer numbers of arbitrary magnitude. The specific representation used depends on the <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-facet" class="">facet</a><sup><small>XS2</small></sup> values of the associated schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#datatype" class="">datatype</a><sup><small>XS2</small></sup> as follows. 
</p><p>
If the associated schema datatype is derived from xsd:integer and the bounded range determined by its
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-minInclusive" class="">minInclusive</a><sup><small>XS2</small></sup>, 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-minExclusive" class="">minExclusive</a><sup><small>XS2</small></sup>, 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-maxInclusive" class="">maxInclusive</a><sup><small>XS2</small></sup> and 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-maxExclusive" class="">maxExclusive</a><sup><small>XS2</small></sup> facets has 4096 or fewer values,
the value is represented as an <a href="#encodingBoundedUnsigned">n-bit Unsigned Integer</a> where <em>n</em> is &lceil;&nbsp;log<sub>2</sub> <em>m</em>&nbsp;&rceil; and <em>m</em> is the bounded range of the schema datatype.</p><p>Otherwise, if the associated schema datatype is derived from xsd:integer and the <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-minInclusive" class="">minInclusive</a><sup><small>XS2</small></sup> or 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#rf-minExclusive" class="">minExclusive</a><sup><small>XS2</small></sup> facets specify a lower bound greater than or equal to zero (0), the value is represented as an <a href="#encodingUnsignedInteger">Unsigned Integer</a>.</p><p>
Otherwise, the value is represented as a Boolean sign (see <a href="#encodingBoolean"><b>7.1.2 Boolean</b></a>) followed by an Unsigned Integer (see <a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>). A sign value of zero (0) is used to represent positive integers and a sign value of one (1) is used to represent negative integers. For non-negative values, the Unsigned Integer holds the magnitude of the value. For negative values, the Unsigned Integer holds the magnitude of the value minus 1. 
</p></div><div class="div3">
<h4><a name="encodingUnsignedInteger" id="encodingUnsignedInteger"></a>7.1.6 Unsigned Integer</h4><p>The Unsigned Integer datatype representation supports unsigned integer numbers of arbitrary magnitude. It is represented as a sequence of octets terminated by an octet with its most significant bit set to 0. The value of the unsigned integer is stored in the least significant 7 bits of the octets as a sequence of 7-bit bytes, with the least significant byte first. </p><p>EXI processors SHOULD support arbitrarily large Unsigned Integer values. EXI processors MUST support Unsigned Integer values less than 2147483648.</p><p>The Unsigned Integer datatype representation can be decoded by going through the following steps.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N70351" id="N70351"></a><i><span>Example 7-1. </span>
Example algorithm for decoding an Unsigned Integer
</i></div><ol class="enumar"><li>Start with the initial value set to 0 and the initial multiplier set to 1.</li><li>Read the next octet.</li><li>Multiply the value of the unsigned number represented by the 7 least significant bits of the octet by the current multiplier and add the result to the current value.</li><li>Multiply the multiplier by 128.</li><li>If the most significant bit of the octet was 1, go back to step 2.</li></ol></div><p></p></div><div class="div3">
<h4><a name="encodingQName" id="encodingQName"></a>7.1.7 QName</h4><p>The QName datatype representation is a sequence of values representing the URI, local-name and prefix components of the QName in that order, where the prefix component is present only when the <a href="#key-preservePrefixesOption" class="termref"><span class="arrow"></span>Preserve.prefixes<span class="arrow"></span></a> option is set to true.
</p><p>When the QName value is specified by a schema-informed grammar using the SE&nbsp;(<em>qname</em>) or AT&nbsp;(<em>qname</em>) terminal symbols, URI and local-name are implicit and are omitted.
Similarly, when the URI of the QName value is derived from a schema-informed grammar using 
SE&nbsp;(<em>uri</em>:&nbsp;*) 
or AT&nbsp;(<em>uri</em>:&nbsp;*) 
terminal symbols, URI is implicit thus omitted in the representation, and only the local-name component is encoded as a String (see <a href="#encodingString"><b>7.1.10 String</b></a>).
Otherwise, URI and local-name components are encoded as Strings. 
If the QName is in no namespace, the URI is represented by a zero length String. 
</p><p>When present, prefixes are represented as <em>n</em>-bit unsigned integers (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where <em>n</em> is 
&lceil;&nbsp;log<sub>2</sub>(<em>N</em>)&nbsp;&rceil; 
and <em>N</em> is the number of <em>prefix</em>es in the prefix string table partition associated with the URI of the QName or one (1) if there are no prefixes in this partition.  



If the given <em>prefix</em> exists in the associated prefix string table partition, it is represented using the compact identifier assigned by the partition. If the given <em>prefix</em> does not exist in the associated partition, the QName MUST be part of an SE event and the prefix MUST be resolved by one of the NS events immediately following the SE event (see resolution rules below). In this case, the unresolved prefix representation is not used and can be zero (0) or the compact identifier of any prefix in the associated partition.
 
</p><div class="note"><p class="prefix"><b>Note:</b></p>
When <em>N</em> is one, the prefix is represented using zero bits (i.e. omitted). 
</div><p>Given a <em>n</em>-bit unsigned integer <em>m</em> that represents either the prefix value or an unresolved prefix value, the effective prefix value is determined by following the rules described below in order. A QName is in error if its prefix cannot be resolved by the rules below.
</p><ol><li>If the prefix string table partition associated with the URI of the QName assigns the compact identifier <em>m</em> to a <em>prefix</em> value, select this <em>prefix</em> value as the candidate <em>prefix</em> value. Otherwise, there is no candidate <em>prefix</em> value.
</li><li>If the QName value is part of an SE event followed by an associated NS event with 
its <a href="#key-indicatorContentItem" class="termref"><span class="arrow"></span><em>local-element-ns</em><span class="arrow"></span></a> flag value 
set to true, the <em>prefix</em> value is the <em>prefix</em> of this NS event. Otherwise, the <em>prefix</em> value is the candidate value, if any, selected in step 1 above.
</li></ol></div><div class="div3">
<h4><a name="encodingDateTime" id="encodingDateTime"></a>7.1.8 Date-Time</h4><p>The Date-Time datatype representation is a sequence
of values representing the individual components of the Date-Time. The
following table specifies each of the possible date-time components
along with how they are encoded.</p><table border="1"><caption>Table 7-3. Date-Time components</caption><thead><tr><th>Component</th><th>Value</th><th>Type</th></tr></thead><tbody><tr><td>Year</td><td>Offset from 2000</td><td>Integer ( 
<a href="#encodingInteger"><b>7.1.5 Integer</b></a>)</td></tr><tr><td>MonthDay</td><td>
Month * 32 + Day
</td><td>
9-bit Unsigned Integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>) where day is a value in the range 1-31 and month is a value in the range 1-12.
</td></tr><tr><td>Time</td><td>
((Hour * 64) + Minutes) * 64 + seconds
</td><td>17-bit Unsigned Integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>)</td></tr><tr><td>FractionalSecs</td><td>Fractional seconds</td><td>Unsigned Integer ( 
<a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>) representing the fractional part of the seconds with digits in reverse order to preserve leading zeros</td></tr><tr><td>TimeZone</td><td>
TZHours * 64 + TZMinutes
</td><td>11-bit Unsigned Integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>) representing a signed integer offset by 896 ( = 14 * 64 )</td></tr><tr><td>presence</td><td>Boolean presence indicator</td><td>Boolean (<a href="#encodingBoolean"><b>7.1.2 Boolean</b></a>)</td></tr></tbody></table><p>
The variety of components that constitute a value and their appearance order depend on the XML Schema type associated with the value. The following table shows which components are included in a value of each XML Schema type that is relevant to Date-Time datatype. Items listed in square brackets are included if and only if the value of its preceding presence indicator (specified above) is set to true.</p><table border="1"><caption>Table 7-4. Assortment of Date-Time components</caption><thead><tr><th>XML Schema Datatype</th><th>Included Components</th></tr></thead><tbody><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#gYear" class="">gYear</a><sup><small>XS2</small></sup></td><td>Year, presence, [TimeZone]</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#gYearMonth" class="">gYearMonth</a><sup><small>XS2</small></sup></td><td rowspan="2">Year, MonthDay, presence, [TimeZone]</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#date" class="">date</a><sup><small>XS2</small></sup></td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime" class="">dateTime</a><sup><small>XS2</small></sup></td><td>Year, MonthDay, Time, presence, [FractionalSecs], presence, [TimeZone]</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#gMonth" class="">gMonth</a><sup><small>XS2</small></sup></td><td rowspan="3">MonthDay, presence, [TimeZone]</td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#gMonthDay" class="">gMonthDay</a><sup><small>XS2</small></sup></td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#gDay" class="">gDay</a><sup><small>XS2</small></sup></td></tr><tr><td><a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#time" class="">time</a><sup><small>XS2</small></sup></td><td>Time, presence, [FractionalSecs], presence, [TimeZone]</td></tr></tbody></table></div><div class="div3">
<h4><a name="encodingBoundedUnsigned" id="encodingBoundedUnsigned"></a>7.1.9 <em>n</em>-bit Unsigned Integer</h4><p>
When the value of the <a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression option<span class="arrow"></span></a> is false and
the <a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a> alignment is used, 
the <em>n</em>-bit Unsigned Integer datatype representation is an unsigned binary integer using <em>n</em> bits. 
Otherwise, it is an unsigned integer using the minimum number of bytes required to store 
<em>n</em> bits. Bytes are ordered with the least significant byte first.</p><p>
The <em>n</em>-bit unsigned integer is used for representing <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a>, the prefix component of QNames (see <a href="#encodingQName"><b>7.1.7 QName</b></a>) and certain <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content items, as described in respective relevant parts of this document. As described in section <a href="#encodingInteger"><b>7.1.5 Integer</b></a>, integers with a bounded range size <em>m</em> equal to 
4096 
or smaller are represented as <em>n</em>-bit unsigned integers with <em>n</em> being &lceil; log <sub>2</sub> <em>m</em> &rceil;, as an offset from the minimum value in the range.
</p></div><div class="div3">
<h4><a name="encodingString" id="encodingString"></a>7.1.10 String</h4><p>The String datatype representation is a length prefixed sequence of
characters. The length indicates the number of characters in the
string and is represented as an Unsigned Integer (see <a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>). If a restricted character set is defined for the string (see <a href="#restrictedCharSet"><b>7.1.10.1 Restricted Character Sets</b></a>), each character is represented as an <em>n</em>-bit Unsigned Integer (see <a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>). Otherwise, each character is represented by its Unicode 
<a href="#Unicode">[UNICODE]</a>
code point encoded as an Unsigned Integer (see <a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>).
</p><p>EXI uses a string table to represent certain
<a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> more efficiently. Section <a href="#stringTable"><b>7.3 String Table</b></a>
describes the string table and how it is applied to different content
items.</p><div class="div4">
<h5><a name="restrictedCharSet" id="restrictedCharSet"></a>7.1.10.1 Restricted Character Sets</h5><p>If a string value is associated with a schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#datatype" class="">datatype</a><sup><small>XS2</small></sup> 
derived from xsd:string and one or more of the datatypes in its datatype hierarchy has one or more pattern facets, there may be a restricted character set defined for the string value. The following steps are used to determine the restricted character set, if any, defined for a given string value associated with such a schema datatype.
</p><p>
Given the schema datatype, let the target datatype definition be the definition of the most-derived datatype that has one or more pattern facets immediately specified in its definition in the schema among those in the datatype inheritance hierarchy that traces backwards toward <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-primitive" class="">primitive datatypes</a><sup><small>XS2</small></sup> starting from the datatype.
If the target datatype definition is a definition for a <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-derived" class="">built-in datatype</a><sup><small>XS2</small></sup>, there is no restricted character set for the string value.  Otherwise, 
determine the set of characters for each immediate pattern facet of the target datatype definition according to section <a href="#regexToCharset"><b>E Deriving 
Set of Characters 
from XML Schema Regular Expressions</b></a>.
Then, compute the restricted set of characters for the string value as the union of all the sets of characters computed in the previous step. If the resulting set of characters contains less than 
256 
characters and contains only BMP characters, the string value has a restricted character set and each character is represented using an <em>n</em>-bit Unsigned Integer (see <a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where <em>n</em> is &lceil; log<sub>2</sub>(<em>N</em> + 1) &rceil; and <em>N</em> is the number of characters in the restricted character set.</p><p>The characters in the restricted character set are sorted by Unicode <a href="#Unicode">[UNICODE]</a> code point and represented by integer values in the range (0 ... <em>N</em>&minus;1) according to their ordinal position in the set. Characters that are not in this set are represented by the <em>n</em>-bit Unsigned Integer <em>N</em> followed by the Unicode code point of the character represented as an Unsigned Integer.</p><p>The figure below illustrates an overview of the process for determining and using restricted character sets described in this section. </p><div class="figure" style="text-align: center"><br><img src="restrictedCharset.png" alt="String Processing Model"><p><i><span>Figure 7-1. </span>String Processing Model</i></p><br></div></div></div><div class="div3">
<h4><a name="encodingList" id="encodingList"></a>7.1.11 List</h4><p>Values of type List are encoded as a length
prefixed sequence of values. The length is encoded as an Unsigned Integer (see
<a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>) and each value is encoded according
to its type (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>).</p></div></div><div class="div2">
<h3><a name="encodingEnumerations" id="encodingEnumerations"></a>7.2 Enumerations</h3><p>
When the <a href="#key-preserveLexicalValuesOption" class="termref"><span class="arrow"></span>Preserve.lexicalValues<span class="arrow"></span></a> option is false, 
enumerated values 
are encoded as
<em>n</em>-bit Unsigned Integers (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>) where <em>n</em> = &lceil; log <sub>2</sub> <em>m</em> &rceil; and <em>m</em> is the number of items
in the enumerated type. The unsigned integer value assigned to each item corresponds to
its ordinal position in the enumeration in schema-order starting with
position zero (0).
When there are more than one item that represent the same value in the enumeration, 
such value can be represented using the ordinal position of any items that represent the value.
</p><p>Exceptions are for schema types derived from others by union and their subtypes, QName or Notation and types derived therefrom by restriction. The values of such types are processed by their respective built-in EXI datatype representations instead of being represented as enumerations.</p></div><div class="div2">
<h3><a name="stringTable" id="stringTable"></a>7.3 String Table</h3><p>EXI uses a string table to assign "compact identifiers" to some
string values. Occurrences of string values found in the string table
are represented using the associated compact identifier rather than
encoding the entire "string literal". The string table is initially pre-populated with
string values that are likely to occur in certain contexts and is
dynamically expanded to include additional string values encountered
in the document. The following <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> are encoded using a
string table: </p><ul><li><a href="#key-uriContentItem" class="termref"><span class="arrow"></span><em>uris</em><span class="arrow"></span></a></li><li><a href="#key-prefixContentItem" class="termref"><span class="arrow"></span><em>prefixes</em><span class="arrow"></span></a></li><li><em>uri</em> and 
<em>local-name</em>
in <a href="#key-qnameContentItem" class="termref"><span class="arrow"></span><em>qnames</em><span class="arrow"></span></a></li><li><a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>values</em><span class="arrow"></span></a></li></ul><p>When a string value is found in the string table, the value is encoded
using the compact identifier and no changes are made to the string table as a result. 
When a string value is not found in the string table, its string literal is encoded
as a String without using a compact identifier, only after which
the string table is augmented by including the string value with an assigned
compact identifier
unless the string value represents a <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content item 
and fails to satisfy the criteria in effect by virtue of <a href="#key-valuePartitionCapacityOption" class="termref"><span class="arrow"></span>valuePartitionCapacity<span class="arrow"></span></a> and <a href="#key-valueMaxLengthOption" class="termref"><span class="arrow"></span>valueMaxLength<span class="arrow"></span></a> options

.</p><p>The string table is divided into partitions and each partition is
optimized for more frequent use of either compact identifiers or string literals
depending on the purpose of the partition. Section <a href="#stringTablePartitions"><b>7.3.1 String Table Partitions</b></a> describes how EXI string table is
partitioned. Section <a href="#encodingOptimizedForHits"><b>7.3.2 Partitions Optimized for Frequent use of Compact Identifiers</b></a>
describes how string values are encoded when the associated partition
is optimized for more frequent use of compact identifiers. Section <a href="#encodingOptimizedForMisses"><b>7.3.3 Partitions Optimized for Frequent use of String Literals</b></a> describes how string values are
encoded when the associated partition is optimized for more frequent use
of string literals.</p><p>The life cycle of a string table spans the processing of 
a single EXI stream. String tables are not represented in an EXI stream or exchanged
between EXI processors. A string table cannot be reused across multiple EXI streams;
therefore, EXI processors MUST use a string table that is equivalent to
the one that would have been newly created and pre-populated with initial
values for processing each EXI stream.
</p><div class="div3">
<h4><a name="stringTablePartitions" id="stringTablePartitions"></a>7.3.1 String Table Partitions</h4><p>The string table is organized into partitions
so that the indices assigned to compact identifiers can stay relatively small.
Smaller number of indices results in improved average compactness and the efficiency
of table operations. Each partition has a separate set of compact identifiers and
<a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> are assigned to specific partitions as described below. 
</p><p><a href="#key-uriContentItem" class="termref"><span class="arrow"></span><em>Uri</em><span class="arrow"></span></a> content items and the URI portion of 
<a href="#key-qnameContentItem" class="termref"><span class="arrow"></span><em>qname</em><span class="arrow"></span></a> content items are assigned to the uri
partition. The uri partition is optimized for frequent use of compact identifiers and is
pre-populated with initial entries as described in <a href="#initialUriValues"><b>D.1 Initial Entries in Uri Partition</b></a>.
When a schema is provided, the uri partition is also pre-populated with
the name of each
target
namespace URI declared in the schema,
plus some of the namespace URIs used in wildcard terms 
and attribute wildcards 
(see section <a href="#wildcardTerms"><b>8.5.4.1.7 Wildcard Terms</b></a> 
and <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a>, respectively 
for the condition),
appended in lexicographical order.</p><p><a href="#key-prefixContentItem" class="termref"><span class="arrow"></span><em>Prefix</em><span class="arrow"></span></a> content items are assigned to partitions based
on their associated namespace URI. Partitions containing
<em>prefix</em> content items are optimized for frequent use of compact identifiers and the
string table is pre-populated with entries as described in
<a href="#initialPrefixValues"><b>D.2 Initial Entries in Prefix Partitions</b></a>.</p><p>
The local-name portion of <a href="#key-qnameContentItem" class="termref"><span class="arrow"></span><em>qname</em><span class="arrow"></span></a>
content items are assigned to partitions based on the namespace URI of 
the <em>qname</em> content item of which the local-name is a part. 
Partitions containing local-names are optimized for frequent use of string 
literals and the string table is pre-populated with entries as described in 
<a href="#initialLocalNames"><b>D.3 Initial Entries in Local-Name Partitions</b></a>.
</p><p>
Each <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a>
content item is assigned to both the global value partition
and a "local" value partition based on the
<a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> 
of the attribute or element in context at the time
the value is added to the value partitions.
Partitions containing <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em>
<span class="arrow"></span></a> content items are optimized for frequent use of string literals and are initially empty.
<span class="termdef"><a name="key-globalID" id="key-globalID">[Definition:]&nbsp;&nbsp;</a>
The variable <b><em>globalID</em></b> is a non-negative integer representing the compact identifier of the next item added to the global value partition.
</span>

Its value is initially set to 0 (zero) and changes while processing an EXI stream per the rule described in <a href="#encodingOptimizedForMisses"><b>7.3.3 Partitions Optimized for Frequent use of String Literals</b></a>.

</p></div><div class="div3">
<h4><a name="encodingOptimizedForHits" id="encodingOptimizedForHits"></a>7.3.2 Partitions Optimized for Frequent use of Compact Identifiers</h4><p>String table partitions that are expected to contain a relatively
small number of entries used repeatedly throughout the document are
optimized for the frequent use of compact identifiers. This includes the <a href="#key-uriContentItem" class="termref"><span class="arrow"></span><em>uri</em><span class="arrow"></span></a> partition and
all partitions containing <a href="#key-prefixContentItem" class="termref"><span class="arrow"></span><em>prefix</em><span class="arrow"></span></a> content items. </p><p>When a string value is found in a partition optimized for frequent use of compact identifiers,
the string value is represented as the value (<em>i</em>+1)
encoded as an <em>n</em>-bit Unsigned Integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where
<em>i</em> is the value of the compact identifier, <em>n</em> is
&lceil; log<sub>2</sub> (<em>m</em>+1) &rceil; and <em>m</em> is the number of
entries in the string table partition at the time of the operation.
</p><p>When a string value is not found in a partition optimized for frequent use of compact identifiers,
the String value is represented as zero (0) encoded as an
<em>n</em>-bit Unsigned Integer, followed by the string literal
encoded as a String (<a href="#encodingString"><b>7.1.10 String</b></a>). After
encoding the String value, it is added to the string table partition
and assigned the next available compact identifier <em>m</em>.</p></div><div class="div3">
<h4><a name="encodingOptimizedForMisses" id="encodingOptimizedForMisses"></a>7.3.3 Partitions Optimized for Frequent use of String Literals</h4><p>The remaining string table partitions are optimized for
the frequent use of string literals. This includes all string table partitions containing
local-names
and all string table partitions containing <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content
items.</p><p>When a string value is found in the partitions containing
local-names, the
string value is represented as zero (0) encoded as an Unsigned Integer (see
<a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>) followed by 
the compact identifier of the string value. The compact identifier of the string
value is encoded as an <em>n</em>-bit unsigned integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where
<em>n</em> is &lceil; log<sub>2</sub> <em>m</em> &rceil; and <em>m</em> is
the number of entries in the string table partition at the time of the operation.</p><p>When a string value is not found in the partitions containing
local-names, its
string literal is encoded as a String (see <a href="#encodingString"><b>7.1.10 String</b></a>) with the length of the string incremented
by one. After encoding the string value, it is added to the string
table partition and assigned the next available compact
identifier <em>m</em>.</p><p>As described above, each <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> content item is assigned
to two partitions, a "local" value partition and the global
value partition. 
When a string value is found in the global or "local" partition, it is represented using a compact identifier. When a string value is found in the "local" value partition,
the string value may be represented as zero (0) encoded as an Unsigned Integer (see
<a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>) followed by the compact identifier
of the string value in the "local" value partition. 
When a string value is found in the global value partition, the String value may be represented as one (1) encoded as an
Unsigned Integer (see <a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>) followed by the compact
identifier of the String value in the global value
partition. The compact identifier is encoded as an <em>n</em>-bit
unsigned integer (<a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>), where <em>n</em> is &lceil; log<sub>2</sub><em>m</em> &rceil; and <em>m</em> is the number of entries in the
associated partition at the time of the operation.</p><p>When a string value <em>S</em> is not found in the global or "local" 
<em>value</em> partition, its string literal is encoded as a
String (see <a href="#encodingString"><b>7.1.10 String</b></a>) with the length
<em>L</em> + 2 (incremented by two) where <em>L</em> is the number of characters in the string value. 
If <a href="#key-valuePartitionCapacityOption" class="termref"><span class="arrow"></span>valuePartitionCapacity<span class="arrow"></span></a> is not zero, and 
<em>L</em> is greater than zero and no more than <a href="#key-valueMaxLengthOption" class="termref"><span class="arrow"></span>valueMaxLength<span class="arrow"></span></a>, the string <em>S</em> is added to the associated "local" value partition using the next available compact identifier <em>m</em> and added to the global value partition using the compact identifier <a href="#key-globalID" class="termref"><span class="arrow"></span><em>globalID</em><span class="arrow"></span></a>. When <em>S</em> is added to the global value partition and there was already a string <em>V</em> in the global value partition associated with the compact identifier <a href="#key-globalID" class="termref"><span class="arrow"></span><em>globalID</em><span class="arrow"></span></a>, the string <em>S</em> replaces the string <em>V</em> in the global table, and the string <em>V</em> is removed from its associated local value partition by rendering its compact identifier permanently unassigned. When the string value is added to the global value partition, the value of <a href="#key-globalID" class="termref"><span class="arrow"></span><em>globalID</em><span class="arrow"></span></a> is incremented by one (1). If the resulting value of <a href="#key-globalID" class="termref"><span class="arrow"></span><em>globalID</em><span class="arrow"></span></a> is equal to <a href="#key-valuePartitionCapacityOption" class="termref"><span class="arrow"></span>valuePartitionCapacity<span class="arrow"></span></a>, its value is reset to zero (0)
</p></div></div><div class="div2">
<h3><a name="datatypeRepresentationMap" id="datatypeRepresentationMap"></a>7.4 Datatype Representation Map</h3><p>By default, each typed value in an EXI stream is represented using its
default built-in EXI datatype representation (see <a href="#builtInEXITypes">Table 7-1</a>). 
However, <span class="termdef"><a name="key-datatypeRepresentationMaps" id="key-datatypeRepresentationMaps">[Definition:]&nbsp;&nbsp;</a><a href="#key-exiprocessor" class="termdef"><span class="arrow"></span>EXI processors<span class="arrow"></span></a> MAY provide the capability to specify alternate built-in EXI datatype representations or 
user-defined datatype representations for specific schema 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#datatype" class="termdefxspecref">datatypes</a><sup><small>XS2</small></sup>. 
This capability is called a <b>Datatype Representation Map</b></span>.
</p><div class="note"><p class="prefix"><b>Note:</b></p>
This feature is relevant only to simple types in the schema. 
EXI does not provide a way for applications to infuse custom representations of structured data bound to complex types into the format. 
</div><p>
EXI processors that support Datatype Representation Maps MAY provide implementation specific means to define and install user-defined datatype representations. EXI processors MAY also provide implementation specific means for applications or users to specify alternate built-in EXI datatype representations or user-defined datatype representations for representing specific schema datatypes. As with the default EXI datatype representations, alternate datatype representations are used for the associated XML Schema types specified in the Datatype Representation Map and XML Schema datatypes derived from those datatypes. When there are built-in or user-defined datatype representations associated with more than one XML Schema datatype in the type hierarchy of a particular datatype, the closest ancestor with an associated datatype representation is used to determine the EXI datatype representation.
</p><p>When an EXI processor encodes an EXI stream using 
a Datatype Representation Map and the <a href="#key-options" class="termref"><span class="arrow"></span>EXI Options<span class="arrow"></span></a> part of the header is present, the EXI options part MUST specify all alternate datatype representations used in the EXI stream.
An EXI processor that attempts to decode an
EXI stream that specifies a user-defined datatype representation in the EXI header that
it does not recognize MAY report a warning, but this is not an
error. However, when an EXI processor encounters a typed value that
was encoded by a user-defined datatype representation that it does not support, it MUST
report an error.</p><p>The EXI options header, when it appears in an EXI stream, MUST include a 
"datatypeRepresentationMap" element for each
schema datatype 
of which the descendant datatypes derived by restriction as well as itself are 
not represented using the default 
built-in EXI datatype representation. 

The "datatypeRepresentationMap" element includes two child elements. 
The <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of
the first child element identifies the schema datatype that is not
represented using the default 
built-in EXI datatype representation 

and the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the
second child element identifies the alternate 
built-in EXI datatype representation or user-defined datatype representation 
used to represent that type. 
Built-in EXI datatype representations are identified by the type identifiers in 
<a href="#builtInEXITypes">Table 7-1</a>. </p><p>For example, the following "datatypeRepresentationMap" element indicates all values of
type xsd:decimal are represented using the built-in exi:string datatype representation. In addition, all datatypes derived from xsd:decimal by restriction that do not have a closer ancestor in the type hierarchy with an associated datatype representation are represented using exi:string.
</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N71347" id="N71347"></a><i><span>Example 7-2. </span>datatypeRepresentationMap indicating all Decimal values are represented using
built-in String datatype representation</i></div><div class="exampleInner"><pre>
    &lt;exi:datatypeRepresentationMap xmlns:xsd="http://www.w3.org/2001/XMLSchema"&gt;
        &lt;xsd:decimal/&gt;
        &lt;exi:string/&gt;
    &lt;/exi:datatypeRepresentationMap&gt;
</pre></div></div><p>It is the responsibility of an EXI processor to interface with a particular implementation of 
built-in EXI datatype representations 

or user-defined 
datatype representations 

properly. In the example above, an EXI processor may need to provide a string value of the data being processed that is typed as xsd:decimal in order to interface with 
an implementation of built-in String datatype representation.

In such a case, some EXI processors may have started with a decimal value and such processors may well translate the value into a string before passing the data to 
the implementation of built-in String datatype representation 

while other EXI processors may already have a string value of the data so that it can pass the value directly to 
the implementation of built-in String datatype representation 

without any translation.
</p><p>As another example, the following 
"datatypeRepresentationMap" element indicates all
values of the used-defined 
simple type 
geo:geometricSurface 
and the datatypes derived from it by restriction 
are represented
using the user-defined datatype representation geo:geometricInterpolator: </p><div class="exampleOuter">
<div class="exampleHeader"><a name="N71357" id="N71357"></a><i><span>Example 7-3. </span>datatypeRepresentationMap illustrating a user-defined type represented by a user-defined datatype representation</i></div><div class="exampleInner"><pre>
    &lt;exi:datatypeRepresentationMap xmlns:geo="http://example.com/Geometry"&gt;
        &lt;geo:geometricSurface/&gt;
	&lt;geo:geometricInterpolator/&gt;
    &lt;/exi:datatypeRepresentationMap&gt;
</pre></div></div><div class="note"><p class="prefix"><b>Note:</b></p>
EXI only defines a way to indicate the use of user-defined datatype representations for representing values of specific datatypes. 
Datatype representations are referred to by their respective <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a> in "datatypeRepresentationMap" elements. A datatype representation is omnipresent only if its <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> is one of those that represent built-in EXI datatype representations. 
For datatype representations of other <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a>, EXI does not provide nor suggest a method by which they are identified and shared between EXI Processors. 
This suggests that the use of user-defined (i.e. custom) datatype representations 
needs to be restrained by weighing alternatives and considering the consequences of each in pros and cons, in order to avoid unruly proliferation of documents that use such datatype representations. 
Those applications that ever find Datatype Representation Map useful should make sure that they exchange such documents only among the parties that are pre-known or discovered to be able to process the user-defined datatype representations that are in use. Otherwise, if it is not for certain if a receiver understands the particular user-defined datatype representations, the sender should never attempt to send documents that use user-defined datatype representations to that recipient.
</div></div></div><div class="div1">
<h2><a name="grammars" id="grammars"></a>8. EXI Grammars</h2><p>EXI is a knowledge based encoding that uses a set of grammars to
determine which events are most likely to occur at any given point in
an EXI stream and encodes the most likely alternatives in fewer
bits. It does this by mapping the stream of events to a lower entropy
set of representative values and encoding those values using a set of
simple variable length codes or an EXI compression algorithm. </p><p>The result is a very simple, small algorithm that uniformly handles
schema-less encoding, schema-informed encoding, schema deviations,
and any combination thereof in EXI streams. These variations do
not require different algorithms or different parsers, they are simply
informed by different combinations of grammars. </p><p>The following sections describe the grammars used to inform the EXI encoding. </p><div class="note"><p class="prefix"><b>Note:</b></p>The grammar semantics in this specification are written for clarity and generality. They do not prescribe a particular implementation approach. </div><div class="div2">
<h3><a name="grammarNotation" id="grammarNotation"></a>8.1 Grammar Notation</h3><div class="div3">
<h4><a name="fixedEventCodes" id="fixedEventCodes"></a>8.1.1 Fixed Event Codes</h4><p>Each grammar production has an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a>, which is represented by a sequence of one to three parts separated by periods ("."). Each part is an unsigned integer. The following are examples of grammar productions with <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> as they appear in this specification. </p><div class="exampleOuter">
<div class="exampleHeader"><a name="N71408" id="N71408"></a><i><span>Example 8-1. </span>Example productions with fixed event codes</i></div><table width="95%"><thead><tr><th colspan="4">&nbsp;</th></tr><tr><td width="5%"></td><th colspan="2" align="left">Productions</th><th align="left">Event Codes</th></tr></thead><tbody><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>LeftHandSide</em><sub>&nbsp;1</sub> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">
Terminal<sub>&nbsp;1</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;1</sub></td><td>0</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;2</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;2</sub></td><td>1</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;3</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;3</sub></td><td>2.0</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;4</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;4</sub></td><td>2.1</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;5</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;5</sub></td><td>2.2.0</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;6</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;6</sub></td><td>2.2.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>LeftHandSide</em><sub>&nbsp;2</sub> :</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;1</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;1</sub></td><td>0</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;2</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;2</sub></td><td>1.0</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;3</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;3</sub></td><td>1.1</td></tr></tbody></table></div><p>The number of parts in a given <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> is called the event code's length. No two productions with the same non-terminal symbol on the left-hand side are permitted to have the same <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a>. </p></div><div class="div3">
<h4><a name="variableEventCodes" id="variableEventCodes"></a>8.1.2 Variable Event Codes</h4><p>Some non-terminal symbols are used on the right-hand side in a production without 
a terminal symbol prefixed to them, but with a parenthesized event code affixed instead. 
Such non-terminal symbols are macros and they are used to capture some recurring set of productions 
as 
symbols so that a symbol can be used in the grammar representation instead of including all the productions the macro represents in place every time it is used.
</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N71687" id="N71687"></a><i><span>Example 8-2. </span>Example productions that use macro non-terminal symbols</i></div><table width="95%"><thead><tr><td colspan="4">&nbsp;</td></tr></thead><tbody><tr><td width="5%"></td><td colspan="3">
<em>ABigProduction</em><sub>&nbsp;1</sub> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">
Terminal<sub>&nbsp;1</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;1</sub></td><td>0</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;2</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;2</sub></td><td>1</td></tr><tr><td></td><td></td><td>
<em>LEFTHANDSIDE <sub>1</sub></em> (2.0)</td><td>2.0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>ABigProduction</em><sub>&nbsp;2</sub> :</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;1</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;1</sub></td><td>0</td></tr><tr><td></td><td></td><td>
<em>LEFTHANDSIDE <sub>1</sub></em> (1.1)</td><td>1.1</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;2</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;2</sub></td><td>1.2</td></tr></tbody></table></div><p>
Because non-terminal macros are injected into the right-hand side of more than one production,
the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> of productions with these macro non-terminals on the left-hand side are not fixed, but will have different event code values depending on the context in which the macro non-terminal appears. This specification calls these variable event codes and uses variables in place of individual event code parts to indicate the event code parts are determined by the context. Below are some examples of variable event codes: </p><div class="exampleOuter">
<div class="exampleHeader"><a name="N71867" id="N71867"></a><i><span>Example 8-3. </span>Example non-terminal macros and its productions with variable event codes</i></div><table width="95%"><thead><tr><td colspan="4">&nbsp;</td></tr></thead><tbody><tr><td width="5%"></td><td colspan="3">
<em>LEFTHANDSIDE</em><sub>&nbsp;1</sub><em>&nbsp;(n.m)</em> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">
TERMINAL<sub>&nbsp;1</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;1</sub></td><td>
<em>n</em>.0</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;2</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;2</sub></td><td>
<em>n</em>.1</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;3</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;3</sub></td><td>
<em>n</em>. 
<em>m</em>+2</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;4</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;4</sub></td><td>
<em>n</em>. 
<em>m</em>+3</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;5</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;5</sub></td><td>
<em>n</em>. 
<em>m</em>+4.0</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;6</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;6</sub></td><td>
<em>n</em>. 
<em>m</em>+4.1</td></tr></tbody></table></div><p>Unless otherwise specified, the variable 
<em>n</em> evaluates to the first part of the 
<a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of the production in which the macro non-terminal 
<em>LEFTHANDSIDE</em><sub>&nbsp;1&nbsp;</sub> appears on the right-hand side. Similarly, the expression 
<em>n</em>. 
<em>m</em> represents the first two parts of the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of the production in which the macro non-terminal 
<em>LEFTHANDSIDE</em><sub>&nbsp;1&nbsp;</sub> appears on the right-hand side. </p><p>Non-terminal macros are used in this specification for notational convenience only.
They are not non-terminals, even though they are used in place of non-terminals.
Productions that use non-terminal macros on the right-hand side need to be expanded by macro substitution before such productions are interpreted.
Therefore, <em>ABigProduction</em><sub>&nbsp;1</sub> and <em>ABigProduction</em><sub>&nbsp;2&nbsp;</sub> shown in the preceding example are equivalent to the following set of productions obtained by expanding the non-terminal macro symbol <em>LEFTHANDSIDE</em><sub>&nbsp;1&nbsp;</sub> and evaluating the variable event codes.
</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N72105" id="N72105"></a><i><span>Example 8-4. </span>Expanded productions equivalent to the productions used above</i></div><table width="95%"><thead><tr><td colspan="4">&nbsp;</td></tr></thead><tbody><tr><td width="5%"></td><td colspan="3">
<em>ABigProduction</em><sub>&nbsp;1</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
Terminal<sub>&nbsp;1</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;1</sub></td><td>0</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;2</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;2</sub></td><td>1</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;1</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;1</sub></td><td>2.0</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;2</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;2</sub></td><td>2.1</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;3</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;3</sub></td><td>2.2</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;4</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;4</sub></td><td>2.3</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;5</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;5</sub></td><td>2.4.0</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;6</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;6</sub></td><td>2.4.1</td></tr><tr><td colspan="5">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="4">
<em>ABigProduction</em><sub>&nbsp;2</sub> :</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;1</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;1</sub></td><td>0</td></tr><tr><td></td><td></td><td width="75%">
TERMINAL<sub>&nbsp;1</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;1</sub></td><td>1.0</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;2</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;2</sub></td><td>1.1</td></tr><tr><td></td><td></td><td>
Terminal<sub>&nbsp;2</sub>
&nbsp;&nbsp;
<em>NonTerminal</em><sub>&nbsp;2</sub></td><td>1.2</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;3</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;3</sub></td><td>1.3</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;4</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;4</sub></td><td>1.4</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;5</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;5</sub></td><td>1.5.0</td></tr><tr><td></td><td></td><td>
TERMINAL<sub>&nbsp;6</sub>
&nbsp;&nbsp;<em>NONTERMINAL</em><sub>&nbsp;6</sub></td><td>1.5.1</td></tr></tbody></table></div></div></div><div class="div2">
<h3><a name="grammarEventCodes" id="grammarEventCodes"></a>8.2 Grammar Event Codes</h3><p>Each production rule in the EXI grammar includes an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> value that approximates the likelihood the associated production rule will be matched over the other productions with the same left-hand-side non-terminal symbol. Ultimately, the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> determine the value(s) by which each non-terminal symbol will be represented in the EXI stream. </p><p>To understand how a given <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> approximates the likelihood a given production will match, it is useful to visualize the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> for a set of production rules that have the same non-terminal symbol on the left-hand side as a tree. For example, the following set of productions: </p><div class="exampleOuter">
<div class="exampleHeader"><a name="N72528" id="N72528"></a><i><span>Example 8-5. </span>Example productions with event codes</i></div><table width="95%"><tbody><tr><td width="5%"></td><td colspan="4">
<em>ElementContent</em> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">EE</td><td>0</td></tr><tr><td></td><td></td><td>SE&nbsp;(*)&nbsp;&nbsp;<em>ElementContent</em></td><td>1.0</td></tr><tr><td></td><td></td><td>CH&nbsp;&nbsp;<em>ElementContent</em></td><td>1.1</td></tr><tr><td></td><td></td><td>ER&nbsp;&nbsp;<em>ElementContent</em></td><td>1.2</td></tr><tr><td></td><td></td><td>CM&nbsp;&nbsp;<em>ElementContent</em></td><td>1.3.0</td></tr><tr><td></td><td></td><td>PI&nbsp;&nbsp;<em>ElementContent</em></td><td>1.3.1</td></tr></tbody></table></div><p>represents a set of information items that might occur as element content after the start tag. Using the production <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a>, we can visualize this set of productions as follows: </p><div class="figure" style="text-align: center"><br><img src="eventCodeTree.png" alt="Event code tree for ElementContent grammar"><p><i><span>Figure 8-1. </span>Event code tree for ElementContent grammar</i></p><br></div><p>
where the 
terminal symbols 
are represented by the leaf nodes of the tree, and the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of each production rule 
defines a path from the root of the tree to the node 
that represents the terminal symbol that is on the right-hand side of the production. 
We call this the event code tree for a given set of productions. </p><p>An event code tree is similar to a Huffman tree <a href="#huffman">[Huffman Coding]</a> in that shorter paths are generally used for symbols that are considered more likely. However, event code trees are far simpler and less costly to compute and maintain. Event code trees are shallow and contain at most three levels. In addition, the length of each <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> in the event code tree is assigned statically without analyzing the data. This classification provides some of the benefits of a Huffman tree without the cost. </p></div><div class="div2">
<h3><a name="pruningProductions" id="pruningProductions"></a>8.3 Pruning Unneeded Productions</h3><p>As discussed in section 
<a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a>, applications MAY provide a set of fidelity options to specify the XML features they require. EXI processors MUST use these fidelity options to prune 
the productions of which the terminal symbols represent the events that are not required from the grammars, 
improving compactness and processing efficiency.</p><p>For example, the following set of productions represent the set of information items that might occur as element content after the start tag.</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N72687" id="N72687"></a><i><span>Example 8-6. </span>Example productions with full fidelity</i></div><table width="95%"><tbody><tr><td width="5%"></td><td colspan="3">
<em>ElementContent</em> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">EE</td><td>0</td></tr><tr><td></td><td></td><td>SE&nbsp;(*)&nbsp;&nbsp;<em>ElementContent</em></td><td>1.0</td></tr><tr><td></td><td></td><td>CH&nbsp;&nbsp;<em>ElementContent</em></td><td>1.1</td></tr><tr><td></td><td></td><td>ER&nbsp;&nbsp;<em>ElementContent</em></td><td>1.2</td></tr><tr><td></td><td></td><td>CM&nbsp;&nbsp;<em>ElementContent</em></td><td>1.3.0</td></tr><tr><td></td><td></td><td>PI&nbsp;&nbsp;<em>ElementContent</em></td><td>1.3.1</td></tr></tbody></table></div><p>If an application sets the fidelity options Preserve.comments, Preserve.pis and Preserve.dtd to false, the productions matching comment (CM), processing instruction (PI) and entity reference (ER) events are pruned from the grammar, producing the following set of productions: </p><div class="exampleOuter">
<div class="exampleHeader"><a name="N72809" id="N72809"></a><i><span>Example 8-7. </span>Example productions after pruning</i></div><table width="95%"><tbody><tr><td width="5%"></td><td colspan="4">
<em>ElementContent</em> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">EE</td><td>0</td></tr><tr><td></td><td></td><td>SE&nbsp;(*)&nbsp;&nbsp;<em>ElementContent</em></td><td>1.0</td></tr><tr><td></td><td></td><td>CH&nbsp;&nbsp;<em>ElementContent</em></td><td>1.1</td></tr></tbody></table></div><p>Removing these productions from the grammar tells EXI processors that comments and processing instructions will never occur in the EXI stream, which reduces the entropy of the stream allowing it to be encoded in fewer bits. </p><p>Each time a production is removed from a grammar, the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> of the other productions with the same non-terminal symbol on the left-hand side MUST be adjusted to keep them contiguous if its removal has left the remaining productions with non-contiguous event codes.</p></div><div class="div2">
<h3><a name="builtinGrammars" id="builtinGrammars"></a>8.4 Built-in XML Grammars</h3><p>This section describes the built-in XML grammars used by EXI when no schema information is available or when available schema information describes only portions of the EXI stream. </p><p>The built-in XML grammars are dynamic and continuously evolve to reflect knowledge learned while processing an EXI stream. New <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammars<span class="arrow"></span></a> are created to describe the content of newly encountered elements and new grammar productions are added to refine existing built-in grammars. Newly learned grammars and productions are used to more efficiently represent subsequent events in the EXI stream. All newly created <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammars<span class="arrow"></span></a> are <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammars<span class="arrow"></span></a>. 
</p><p><span class="termdef"><a name="key-global-element-grammar" id="key-global-element-grammar">[Definition:]&nbsp;&nbsp;</a>A <b>global element grammar</b> is a grammar describing the content of an element that has global scope (i.e. a global element).</span> At the onset of processing an EXI stream, the set of global element grammars is the set of all schema-informed element grammars derived from element declarations that have a {scope} property of <em>global</em>. Each <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> created while processing an EXI stream is added to the set of global element grammars. Each global element 
grammar 
has a unique <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a>.</p><div class="div3">
<h4><a name="builtinDocGrammars" id="builtinDocGrammars"></a>8.4.1 Built-in Document Grammar</h4><p>In the absence of schema information describing the content of the EXI stream, the following grammar describes the events that will occur in an <a href="#key-exidocument" class="termref"><span class="arrow"></span>EXI document<span class="arrow"></span></a>. </p><table width="100%"><tbody><tr><th align="left" colspan="3">Syntax</th><th align="left">Event Code</th></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>Document</em> :</td></tr><tr><td></td><td width="5%"></td><td width="60%">SD 
<em>DocContent</em></td><td width="30%">0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>DocContent</em> :</td></tr><tr><td></td><td></td><td>SE&nbsp;(*) 
<em>DocEnd</em></td><td>0</td></tr><tr><td></td><td></td><td>DT 
<em>DocContent</em></td><td>1.0</td></tr><tr><td></td><td></td><td>CM 
<em>DocContent</em></td><td>1.1.0</td></tr><tr><td></td><td></td><td>PI 
<em>DocContent</em></td><td>1.1.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>DocEnd</em> :</td></tr><tr><td></td><td></td><td>ED</td><td>0</td></tr><tr><td></td><td></td><td>CM 

<em>DocEnd</em></td><td>1.0</td></tr><tr><td></td><td></td><td>PI 
<em>DocEnd</em></td><td>1.1</td></tr></tbody></table><p></p><table><tbody><tr><th colspan="2" align="left">Semantics:</th></tr><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td><p>All productions in the built-in document grammars of the form 
<em>LeftHandSide</em> : SE&nbsp;(*) <em>RightHandSide</em>
are evaluated as follows: </p>
<ol class="enumar"><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*) </li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>Evaluate the remainder of event sequence using <em>RightHandSide</em>.</li></ol>
</td></tr></tbody></table></div><div class="div3">
<h4><a name="builtinFragGrammars" id="builtinFragGrammars"></a>8.4.2 Built-in Fragment Grammar</h4><p>In the absence of schema information describing the contents of an EXI stream, the following grammar describes the events that may occur in an <a href="#key-exifragment" class="termref"><span class="arrow"></span>EXI fragment<span class="arrow"></span></a>. The grammar below represents the initial set of productions in the built-in fragment grammar at the start of EXI stream processing. The associated semantics explain how the built-in fragment grammar evolves to more efficiently represent subsequent events in the EXI stream.</p><table width="100%"><thead><tr><th align="left" colspan="3">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>Fragment</em> :</td></tr><tr><td></td><td width="5%"></td><td width="60%">SD 
<em>FragmentContent</em></td><td width="30%">0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>FragmentContent</em> :</td></tr><tr><td></td><td></td><td>SE&nbsp;(*) 
<em>FragmentContent</em></td><td>0</td></tr><tr><td></td><td></td><td>ED</td><td>1</td></tr><tr><td></td><td></td><td>CM 
<em>FragmentContent</em></td><td>2.0</td></tr><tr><td></td><td></td><td>PI 
<em>FragmentContent</em></td><td>2.1</td></tr></tbody></table><p></p><table><tbody><tr><th colspan="2" align="left">Semantics:</th></tr><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
<p>All productions in the built-in fragment grammars of the form 
<em>LeftHandSide</em> : SE&nbsp;(*) <em>RightHandSide</em>
are evaluated as follows: </p>
<ol class="enumar"><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*) </li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>Create a production of the form <em>LeftHandSide</em> : SE (<em>qname</em>) <em>RightHandSide</em> with an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> 0</li><li>Increment the first part of the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of each production in the current grammar with the non-terminal <em>LeftHandSide</em> on the left-hand side</li><li>Add the production created in step 
3 
to the grammar</li><li>Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>Evaluate the remainder of event sequence using <em>RightHandSide</em>.</li></ol>
<p>All productions of the form <em>LeftHandSide</em> : SE (<em>qname</em>) <em>RightHandSide</em> that were previously added to the grammar upon the first occurrence of the element that has the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a>&nbsp;<em>qname</em> are evaluated as follows when they are matched: </p>
<ol class="enumar"><li>Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em></li><li>Evaluate the remainder of event sequence using <em>RightHandSide</em>.</li></ol>
</td></tr></tbody></table></div><div class="div3">
<h4><a name="builtinElemGrammars" id="builtinElemGrammars"></a>8.4.3 Built-in Element Grammar</h4><p><span class="termdef"><a name="key-builtin-elem-grammar" id="key-builtin-elem-grammar">[Definition:]&nbsp;&nbsp;</a>When no grammar exists for an element occurring in an EXI stream, a <b>built-in element grammar</b> is created for that element.</span> 
Built-in element grammars are initially generic and are progressively refined as the specific content for the associated element is learned. All built-in element grammars are <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a>s and can be uniquely identified by the qname of the global element they describe. At the outset of processing an EXI stream, the set of built-in element grammars is empty.</p><p>Below is the initial set of productions used for all newly created <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammars<span class="arrow"></span></a>. The semantics describe how productions are added to each <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> as the content of the associated element is learned.</p><table width="100%"><thead><tr><th align="left" colspan="3">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>StartTagContent</em> :</td></tr><tr><td></td><td width="5%"></td><td width="60%">EE</td><td width="30%">0.0</td></tr><tr><td></td><td></td><td>AT&nbsp;(*) 
<em>StartTagContent</em></td><td>0.1</td></tr><tr><td></td><td></td><td>NS 
<em>StartTagContent</em></td><td>0.2</td></tr><tr><td></td><td></td><td>SC 
<em>Fragment</em></td><td>0.3</td></tr><tr><td></td><td></td><td>
<em><b>ChildContentItems</b></em>&nbsp;<b>(0.4)</b></td><td></td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>ElementContent</em> :</td></tr><tr><td></td><td></td><td>EE</td><td>0</td></tr><tr><td></td><td></td><td>
<em>ChildContentItems</em> (1.0)</td><td></td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>ChildContentItems (n.m)</em> :</td></tr><tr><td></td><td></td><td>SE&nbsp;(*) <em>ElementContent</em></td><td>
<em>n</em>. 
<em>m</em></td></tr><tr><td></td><td></td><td>CH <em>ElementContent</em></td><td>
<em>n</em>.(<em>m</em>+1)</td></tr><tr><td></td><td></td><td>ER <em>ElementContent</em></td><td>
<em>n</em>.(<em>m</em>+2)</td></tr><tr><td></td><td></td><td>CM <em>ElementContent</em></td><td>
<em>n</em>.(<em>m</em>+3).0</td></tr><tr><td></td><td></td><td>PI <em>ElementContent</em></td><td>
<em>n</em>.(<em>m</em>+3).1</td></tr></tbody></table><p></p><table width="100%"><thead><tr><th align="left">Note:</th></tr></thead><tbody><tr><td>&nbsp;
</td></tr><tr><td>
<ul><li>
When the value of the <a href="#key-selfContained" class="termref"><span class="arrow"></span>selfContained option<span class="arrow"></span></a> is false, 
the production with the terminal symbol SC on the right-hand side is absent from the above grammar, and 
the use of the non-terminal macro <em>ChildContentItems</em> that has <em>StartTagContent</em> non-terminal on the left-hand side (shown in bold above) gets expanded with variable values (0.3) instead of (0.4) used above.
</li></ul>
</td></tr><tr id="builtInGrammarOrderNotes"><td>
<ul><li>
When a xsi:type attribute appears in an element where the <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> is in effect, it MUST occur before any other AT events of the same element 
unless it is known that xsi:type attribute will not impact grammar selection. 
</li></ul>
</td></tr><tr><td>
<ul><li>
When a xsi:nil attribute appears in an element where the <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> is in effect, it does not impact grammar selection and is not strictly required to occur before other AT events of the same element. 
</li></ul>
</td></tr></tbody></table><p></p><table><tbody><tr><th colspan="2" align="left">Semantics:</th></tr><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
<p>All productions in the <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> of the form 
<em>LeftHandSide</em>: AT&nbsp;(*) 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let 
<em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the attribute matched by AT&nbsp;(*) </li><li>Create a production of the form 
<em>LeftHandSide</em> : AT&nbsp;(<em>qname</em>) <em>RightHandSide</em>
with an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> 0 and increment the first part of the event code of each production in the current grammar with the non-terminal <em>LeftHandSide</em> on the left-hand side. Add this production to the grammar.</li><li>
If <em>qname</em> is xsi:type, let <em>target-type</em> be the value of the xsi:type attribute and assign it the QName datatype representation (see <a href="#encodingQName"><b>7.1.7 QName</b></a>). If there is no namespace in scope for the specified qname prefix, set the <em>uri</em> of <em>target-type</em> to empty ("") and the <em>localName</em> to the full lexical value of the QName, including the prefix. Encode <em>target-type</em> according to section <a href="#encodingValues"><b>7. Representing Event Content</b></a>. If a grammar can be found for the <em>target-type</em> type using the encoded <em>target-type</em> representation, evaluate the element contents using the grammar for <em>target-type</em> type instead of <em>RightHandSide</em>.

</li></ol>

<p>The production of the form <em>LeftHandSide</em> : AT (<em>xsi:type</em>) <em>RightHandSide</em> that was previously added to the grammar upon the first occurrence of the xsi:type attribute is evaluated as follows when it is matched: </p>
<ol class="enumar"><li>Let <em>target-type</em> be the value of the xsi:type attribute and assign it the QName datatype representation (see <a href="#encodingQName"><b>7.1.7 QName</b></a>).</li><li>If there is no namespace in scope for the specified <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> prefix, set the <em>uri</em> of <em>target-type</em> to empty ("") and the <em>localName</em> to the full lexical value of the QName, including the prefix. </li><li>Represent the value of <em>target-type</em> according to section <a href="#encodingValues"><b>7. Representing Event Content</b></a>.</li><li>
If a grammar can be found for the <em>target-type</em> type using the encoded <em>target-type</em> representation, 
evaluate the element contents using the grammar for <em>target-type</em> type instead of <em>RightHandSide</em>. </li></ol>

<p>All productions of the form <em>LeftHandSide</em> : SC <em>Fragment</em> are evaluated as follows: </p>
<ol class="enumar"><li>
Save the string table, grammars and any implementation-specific state learned while processing this EXI Body.
</li><li>Initialize the string table, grammars and any implementation-specific state learned while processing this EXI Body to the state they held just prior to processing this EXI Body.
</li><li>Skip to the next byte-aligned boundary in the stream 
if it is not already at such a boundary.
</li><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the SE event immediately preceding this SC event.</li><li>Let <em>content</em> be the sequence of events following this SC event that match the grammar for element <em>qname</em>, up to and including the terminating EE event.</li><li>Evaluate the sequence of events (SD, SE(<em>qname</em>), <em>content</em>, ED) according to the <em>Fragment</em> grammar (see <a href="#builtinFragGrammars"><b>8.4.2 Built-in Fragment Grammar</b></a>).
</li><li>Skip to the next byte-aligned boundary in the stream 
if it is not already at such a boundary.
</li><li>Restore the string table, grammars and implementation-specific state learned while processing this EXI Body to that saved in step 1 above.
</li></ol>

<p>All productions in the <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> of the form 
<em>LeftHandSide</em> : SE&nbsp;(*) <em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*) </li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>Create a production of the form <em>LeftHandSide</em> : SE (<em>qname</em>) <em>RightHandSide</em> with an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> 0</li><li>Increment the first part of the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of each production in the current grammar with the non-terminal <em>LeftHandSide</em> on the left-hand side</li><li>Add the production created in step 
3 
to the grammar</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>Evaluate the remainder of event sequence using <em>RightHandSide</em>.</li></ol>

<p>All productions of the form <em>LeftHandSide</em> : SE (<em>qname</em>) <em>RightHandSide</em> that were previously added to the grammar upon the first occurrence of the element that has the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a>&nbsp;<em>qname</em> are evaluated as follows when they are matched: </p>
<ol class="enumar"><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em></li><li>Evaluate the remainder of event sequence using <em>RightHandSide</em>.</li></ol>

<p>All productions in the <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> of the form 
<em>LeftHandSide</em> : CH 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>If a production of the form, 
<em>LeftHandSide</em> : CH 
<em>RightHandSide</em> with an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of length 1 does not exist in the current element grammar, create one with event code 0 and increment the first part of the event code of each production in the current grammar with the non-terminal 
<em>LeftHandSide</em> on the left-hand side. </li><li>Add the production created in step 1 to the grammar
</li><li>Evaluate the remainder of event sequence using <em>RightHandSide</em>.</li></ol>

<p>All productions in the <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a> of the form 
<em>LeftHandSide</em> : EE 
are evaluated as follows: </p>
<ol class="enumar"><li>If a production of the form, 
<em>LeftHandSide</em> : EE 
with an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> of length 1 does not exist in the current element grammar, create one with event code 0 and increment the first part of the event code of each production in the current grammar with the non-terminal 
<em>LeftHandSide</em> on the left-hand side. </li><li>Add the production created in step 1 to the grammar
</li></ol>
</td></tr></tbody></table></div></div><div class="div2">
<h3><a name="informedGrammars" id="informedGrammars"></a>8.5 Schema-informed Grammars</h3><p>This section describes the schema-informed grammars used by EXI when schema information is available to describe the contents of the <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a>. 
Schema information used for processing an EXI stream is either indicated by the header option <a href="#key-schemaIdOption" class="termref"><span class="arrow"></span>schemaId<span class="arrow"></span></a>, or communicated out-of-band in the absence of <a href="#key-schemaIdOption" class="termref"><span class="arrow"></span>schemaId<span class="arrow"></span></a>. 
</p><p>Schema-informed grammars accept all XML documents and fragments regardless of whether and how closely they match the schema. The <a href="#key-exiencoder" class="termref"><span class="arrow"></span>EXI stream encoder<span class="arrow"></span></a> encodes individual events using schema-informed grammars where they are available and falls back to the built-in XML grammars where they are not. In general, events for which a schema-informed grammar exists will be encoded more efficiently. </p><p>Unlike built-in XML grammars, schema-informed grammars are static and do not evolve, which permits the reuse of schema-informed grammars across the processing of multiple EXI streams. This is a single outstanding difference between the two grammar systems.</p><p>It is important to note that schema-informed and built-in grammars are often used together within the context of a single <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a>. While processing a schema-informed grammar, built-in grammars may be created to represent schema deviations or elements that match wildcards declared in the schema. Even though these built-in grammars occur in the context of a schema-informed stream, they are still dynamic and evolve to represent content learned while processing the EXI stream as is described in <a href="#builtinGrammars"><b>8.4 Built-in XML Grammars</b></a>. 
</p><div class="div3">
<h4><a name="informedDocGrammars" id="informedDocGrammars"></a>8.5.1 Schema-informed Document Grammar</h4><p>When schema information is available to describe the contents of an <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a>, the following grammar describes the events that will occur in an <a href="#key-exidocument" class="termref"><span class="arrow"></span>EXI document<span class="arrow"></span></a>. </p><table width="100%"><thead><tr><th align="left" colspan="3">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>Document</em> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">SD 
<em>DocContent</em></td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>DocContent</em> :</td></tr><tr><td></td><td></td><td>SE (G <sub>0</sub>) <em>DocEnd</em></td><td>0</td></tr><tr><td></td><td></td><td>SE (G <sub>1</sub>) <em>DocEnd</em></td><td>1</td></tr><tr><td></td><td></td><td>&nbsp;&nbsp;⋮</td><td>⋮</td></tr><tr><td></td><td></td><td>SE (G <sub><em>n</em>&minus;1</sub>) <em>DocEnd</em></td><td><em>n</em>&minus;1</td></tr><tr><td></td><td></td><td>SE&nbsp;(*) 
<em>DocEnd</em></td><td>
<em>n</em></td></tr><tr><td></td><td></td><td>DT 
<em>DocContent</em></td><td>
(<em>n</em>+1).0</td></tr><tr><td></td><td></td><td>CM 
<em>DocContent</em></td><td>
(<em>n</em>+1).1.0</td></tr><tr><td></td><td></td><td>PI 
<em>DocContent</em></td><td>
(<em>n</em>+1).1.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<table><tr><th colspan="2" align="left">Note:</th></tr></table></td></tr><tr><td></td><td colspan="3"><ul><li>The variable 
<em>n</em> in the grammar above is the number of global elements declared in the schema. 
G&nbsp;<sub>0</sub>, G&nbsp;<sub>1</sub>, ... G&nbsp;<sub><em>n</em>&minus;1</sub> represent all the <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a> of global elements sorted lexicographically, first by local-name, then by uri.</li></ul>
</td></tr><tr><td></td><td colspan="3">
<em>DocEnd</em> :</td></tr><tr><td></td><td></td><td>ED</td><td>0</td></tr><tr><td></td><td></td><td>CM 
<em>DocEnd</em></td><td>1.0</td></tr><tr><td></td><td></td><td>PI 
<em>DocEnd</em></td><td>1.1</td></tr></tbody></table><p></p><table><tbody><tr><th colspan="2" align="left">Semantics:</th></tr><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
<p>
In a schema-informed grammar, all productions of the form 
<em>LeftHandSide</em> : SE&nbsp;(*) 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*) </li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>
Evaluate the remainder of event sequence using <em>RightHandSide</em></li></ol>
</td></tr></tbody></table></div><div class="div3">
<h4><a name="informedFragGrammars" id="informedFragGrammars"></a>8.5.2 Schema-informed Fragment Grammar</h4><p>When schema information is available to describe the contents of an <a href="#key-existream" class="termref"><span class="arrow"></span>EXI stream<span class="arrow"></span></a>, the following grammar describes the events that will occur in an <a href="#key-exifragment" class="termref"><span class="arrow"></span>EXI fragment<span class="arrow"></span></a>. </p><table width="100%"><thead><tr><th align="left" colspan="3">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>Fragment</em> :</td></tr><tr><td></td><td width="5%"></td><td width="75%">SD 
<em>FragmentContent</em></td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>FragmentContent</em> :</td></tr><tr><td></td><td></td><td>SE (F <sub>0</sub>) <em>FragmentContent</em></td><td>0</td></tr><tr><td></td><td></td><td>SE (F <sub>1</sub>) <em>FragmentContent</em></td><td>1</td></tr><tr><td></td><td></td><td>&nbsp;&nbsp;⋮</td><td>⋮</td></tr><tr><td></td><td></td><td>SE (F <sub><em>n</em>&minus;1</sub>) <em>FragmentContent</em></td><td><em>n</em>&minus;1</td></tr><tr><td></td><td></td><td>SE&nbsp;(*) 
<em>FragmentContent</em></td><td><em>n</em></td></tr><tr><td></td><td></td><td>ED</td><td>
<em>n</em>+1</td></tr><tr><td></td><td></td><td>CM 
<em>FragmentContent</em></td><td>(<em>n</em>+2).0</td></tr><tr><td></td><td></td><td>PI 
<em>FragmentContent</em></td><td>(<em>n</em>+2).1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<table><tr><th colspan="2" align="left">Note:</th></tr></table></td></tr><tr><td></td><td colspan="3">
<ul><li>The variable <em>n</em> in the grammar above represents the number of unique element <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a> declared in the schema. The variables F&nbsp;<sub>0&nbsp;</sub>, F&nbsp;<sub>1&nbsp;</sub>, ... F&nbsp;<sub>n&minus;1</sub> represent these <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a> sorted lexicographically, first by local-name, then by uri. If there is more than one element declared with the same <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a>, the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> is included only once. 
If all such elements have the same schema type name and {nillable} property value, their content is evaluated according to the specific grammar for that element declaration. 
Otherwise, their content is evaluated according to the relaxed Element Fragment grammar described in <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>.</li></ul>
</td></tr></tbody></table><table><tbody><tr><th colspan="2" align="left">Semantics:</th></tr><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
<p>
In a schema-informed grammar, all productions of the form 
<em>LeftHandSide</em> : SE&nbsp;(*) 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let 
<em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*) </li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>
Evaluate the remainder of event sequence using <em>RightHandSide</em></li></ol>
</td></tr></tbody></table></div><div class="div3">
<h4><a name="informedElementFragGrammar" id="informedElementFragGrammar"></a>8.5.3 Schema-informed Element Fragment Grammar</h4><p><span class="termdef"><a name="key-informed-elem-fragment-grammar" id="key-informed-elem-fragment-grammar">[Definition:]&nbsp;&nbsp;</a>
When schema information is available to describe the contents of an <a href="#key-existream" class="termdef"><span class="arrow"></span>EXI stream<span class="arrow"></span></a> and more than one element is declared with the same <a href="#key-qname" class="termdef"><span class="arrow"></span>qname<span class="arrow"></span></a>, 
but not all such elements have the same type name and {nillable} property value, 
the <b>Schema-informed Element Fragment Grammar</b> are used for processing the events that may occur in such elements when they occur inside an EXI fragment or EXI Element Fragment. 
</span>
The schema-informed element fragment grammar consists of <em>ElementFragment</em> and <em>ElementFragmentTypeEmpty</em> which are defined below. <em>ElementFragment</em> is a grammar that accounts both element declarations and attribute declarations in the schemas, whereas <em>ElementFragmentTypeEmpty</em> is a grammar that regards only attribute declarations.
</p><table width="100%"><thead><tr><th align="left" colspan="3">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>ElementFragment</em><sub>&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td width="75%">AT&nbsp;(<sub>&nbsp;</sub>A<sub>&nbsp;0&nbsp;</sub>) [schema-typed value] <em>ElementFragment</em><sub>&nbsp;0</sub></td><td>0</td></tr><tr><td></td><td></td><td>AT&nbsp;(<sub>&nbsp;</sub>A<sub>&nbsp;1&nbsp;</sub>) [schema-typed value] <em>ElementFragment</em><sub>&nbsp;0</sub></td><td>1</td></tr><tr><td></td><td></td><td>&nbsp;&nbsp;⋮</td><td>⋮</td></tr><tr><td></td><td></td><td>AT&nbsp;(<sub>&nbsp;</sub>A<sub>&nbsp;<em>n</em>&minus;1&nbsp;</sub>) [schema-typed value] <em>ElementFragment</em><sub>&nbsp;0</sub></td><td><em>n</em>&minus;1</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<sub>&nbsp;</sub>*<sub>&nbsp;</sub>) <em>ElementFragment</em><sub>&nbsp;0</sub>
</td><td><em>n</em></td></tr><tr><td></td><td></td><td>SE (<sub>&nbsp;</sub>F<sub>0&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td><em>n</em>+1</td></tr><tr><td></td><td></td><td>SE (<sub>&nbsp;</sub>F<sub>1&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td><em>n</em>+2</td></tr><tr><td></td><td></td><td>&nbsp;&nbsp;⋮</td><td>⋮</td></tr><tr><td></td><td></td><td>SE (<sub>&nbsp;</sub>F<sub><em>m</em>-1&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td><em>n</em>+<em>m</em></td></tr><tr><td></td><td></td><td>
SE&nbsp;(<sub>&nbsp;</sub>*<sub>&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td><em>n</em>+<em>m</em>+1</td></tr><tr><td></td><td></td><td>EE</td><td>
<em>n</em>+<em>m</em>+2</td></tr><tr><td></td><td></td><td>CH [untyped&nbsp;value] 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>
<em>n</em>+<em>m</em>+3</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>ElementFragment</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>SE (<sub>&nbsp;</sub>F<sub>0&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td><em>0</em></td></tr><tr><td></td><td></td><td>SE (<sub>&nbsp;</sub>F<sub>1&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>&nbsp;&nbsp;⋮</td><td>⋮</td></tr><tr><td></td><td></td><td>SE (<sub>&nbsp;</sub>F<sub><em>m</em>-1&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td><em>m</em>-1</td></tr><tr><td></td><td></td><td>
SE&nbsp;(<sub>&nbsp;</sub>*<sub>&nbsp;</sub>) 
<em>ElementFragment</em><sub>&nbsp;2
</sub>
</td><td><em>m</em></td></tr><tr><td></td><td></td><td>EE</td><td>
<em>m</em>+1</td></tr><tr><td></td><td></td><td>CH [untyped&nbsp;value] 
<em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>
<em>m</em>+2</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>ElementFragment</em><sub>&nbsp;2</sub> :
</td></tr><tr><td></td><td></td><td>
SE (<sub>&nbsp;</sub>F<sub>0&nbsp;</sub>) <em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>
<em>0</em>
</td></tr><tr><td></td><td></td><td>
SE (<sub>&nbsp;</sub>F<sub>1&nbsp;</sub>) <em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;⋮
</td><td>
⋮
</td></tr><tr><td></td><td></td><td>
SE (<sub>&nbsp;</sub>F<sub><em>m</em>-1&nbsp;</sub>) <em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>
<em>m</em>-1
</td></tr><tr><td></td><td></td><td>
SE&nbsp;(<sub>&nbsp;</sub>*<sub>&nbsp;</sub>) <em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>
<em>m</em>
</td></tr><tr><td></td><td></td><td>
EE
</td><td>
<em>m</em>+1
</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>ElementFragment</em><sub>&nbsp;2</sub>
</td><td>
<em>m</em>+2
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>ElementFragmentTypeEmpty</em><sub>&nbsp;0</sub> :
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<sub>&nbsp;</sub>A <sub>0&nbsp;</sub>) [schema-typed value] <em>ElementFragmentTypeEmpty</em><sub>&nbsp;0</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<sub>&nbsp;</sub>A <sub>1&nbsp;</sub>) [schema-typed value] <em>ElementFragmentTypeEmpty</em><sub>&nbsp;0</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;⋮
</td><td>⋮</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<sub>&nbsp;</sub>A <sub><em>n</em>&minus;1&nbsp;</sub>) [schema-typed value] <em>ElementFragmentTypeEmpty</em><sub>&nbsp;0</sub>
</td><td><em>n</em>&minus;1</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<sub>&nbsp;</sub>*<sub>&nbsp;</sub>) <em>ElementFragmentTypeEmpty</em><sub>&nbsp;0</sub>
</td><td><em>n</em></td></tr><tr><td></td><td></td><td>
EE
</td><td>
<em>n</em>+1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>ElementFragmentTypeEmpty</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<table><tr><th colspan="2" align="left">Note:</th></tr></table></td></tr><tr><td></td><td colspan="3">
<ul><li>The variable <em>n</em> in the grammar above represents 
the number of unique <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a> given to explicitly declared attributes in the schema. 
The variables A<sub>&nbsp;0</sub>&nbsp;, A<sub>&nbsp;1&nbsp;</sub>, ... A<sub>&nbsp;<em>n</em>&minus;1&nbsp;</sub> represent these qnames sorted lexicographically, first by local-name, then by uri. If there is more than one attribute declared with the same <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a>, the qname is included only once. 
If all such attributes have the same schema type name, their <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> is represented using that type. 
Otherwise, their <a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>value</em><span class="arrow"></span></a> is represented as a String.</li></ul>
<ul><li>The variable <em>m</em> in the grammar above represents the number of unique element <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a> declared in the schema. The variables F<sub>0&nbsp;</sub>, F<sub>1&nbsp;</sub>, ... F<sub><em>m</em>-1&nbsp;</sub> represent these qnames sorted lexicographically, first by local-name, then by uri. If there is more than one element declared with the same <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a>, the qname is included only once. 
If all such elements have the same type name and {nillable} property value, their content is evaluated according to specific grammar for that element declaration. 
Otherwise, their content is evaluated according to the relaxed Element Fragment grammar described above.
</li></ul>

</td></tr></tbody></table><table><tbody><tr><th colspan="2" align="left">Semantics:</th></tr><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
<p>
In a schema-informed grammar, all productions of the form 
<em>LeftHandSide</em> : SE&nbsp;(*) 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let 
<em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*) </li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>
Evaluate the remainder of event sequence using <em>RightHandSide</em></li></ol>
<p>All productions in the schema-informed element fragment grammar of the form 
<em>LeftHandSide</em>: AT&nbsp;(*) 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let 
<em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the attribute matched by AT&nbsp;(*) </li><li></li><li>If a global attribute definition exists for <em>qname</em>, let <em>global-type</em> be the datatype of the global attribute. If the attribute value can be represented using the datatype representation associated with <em>global-type</em>, it SHOULD be represented  using the datatype representation associated with <em>global-type</em> (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>). If the attribute value is not represented using the datatype representation associated with <em>global-type</em>, represent the 
attribute event 
using the AT&nbsp;(*) [untyped&nbsp;value] terminal (see <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>).
</li></ol>
<div class="note"><p class="prefix"><b>Note:</b></p>
When a schema-informed grammar is in effect, xsi:type and xsi:nil attributes MUST NOT be represented using AT(*) terminal.
</div>
</td></tr></tbody></table><p>As with all schema informed element grammars, the schema-informed element fragment grammar is augmented with additional productions that describe events that may occur in an EXI stream, but are not explicitly declared in the schema. The process for augmenting the grammar is described in <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>. 
For the purposes of this process, the schema-informed element fragment grammar is treated as though it is created from an element declaration with a {nillable} property value of true and a type declaration that has named sub-types, and <em>ElementFragmentTypeEmpty</em> is used to serve as the <a href="#key-type-empty" class="termref"><span class="arrow"></span><em>TypeEmpty</em><span class="arrow"></span></a> of the type in the process.
</p><p>The <a href="#key-contentIndex" class="termref"><span class="arrow"></span><em>content</em><span class="arrow"></span></a> index of grammars 
<em>ElementFragment</em> 
and <em>ElementFragmentTypeEmpty</em> 
are both 1 (one). 

</p></div><div class="div3">
<h4><a name="informedElemGrammars" id="informedElemGrammars"></a>8.5.4 Schema-informed Element and Type Grammars</h4><p><span class="termdef"><a name="key-informedElementGrammar" id="key-informedElementGrammar">[Definition:]&nbsp;&nbsp;</a>When one or more XML Schema is available to describe the contents of an EXI stream, a <b>schema-informed element grammar</b> <em>Element</em><sub>&nbsp;i&nbsp;</sub> is derived for each element declaration <em>E</em><sub>&nbsp;i&nbsp;</sub> described by the schemas, where 0 &le; <em>i</em> &lt; <em>n</em> and <em>n</em> is the number of element declarations in the schema.</span>
</p><p><span class="termdef"><a name="key-informedTypeGrammar" id="key-informedTypeGrammar">[Definition:]&nbsp;&nbsp;</a>When one or more XML Schema is available to describe the contents of an EXI stream, a <b>schema-informed type grammar</b> <em>Type</em><sub>&nbsp;i&nbsp;</sub> is derived 
for each named type declaration <em>T</em><sub>&nbsp;i&nbsp;</sub> described by the schemas as well as for each of the <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-primitive-datatypes" class="termdefxspecref">built-in primitive types</a><sup><small>XS2</small></sup> and <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-derived" class="termdefxspecref">built-in derived types</a><sup><small>XS2</small></sup>, the <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#key-urType" class="termdefxspecref">complex ur-type</a><sup><small>XS1</small></sup> and the <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-anySimpleType" class="termdefxspecref">simple ur-type</a><sup><small>XS2</small></sup> defined by XML Schema specification <a href="#schema1">[XML Schema Structures]</a><a href="#schema2">[XML Schema Datatypes]</a>, where 0 &le; <em>i</em> &lt; <em>n</em> and <em>n</em> is the total number of such available types.
</span>
</p><p>Each schema-informed element grammar and type grammar is constructed according to the following four steps:</p><ol><li>Create a proto-grammar that describes the content model according to available schema information (see section <a href="#protoGrammars"><b>8.5.4.1 EXI Proto-Grammars</b></a>). 
</li><li>Normalize the proto-grammar into an EXI grammar (see section <a href="#normalizedGrammars"><b>8.5.4.2 EXI Normalized Grammars</b></a>).</li><li>Assign <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> to each production in the normalized EXI grammar (see section <a href="#eventCodeAssignment"><b>8.5.4.3 Event Code Assignment</b></a>). 
</li><li>Add additional productions to the normalized EXI grammar to represent events that may occur in the EXI stream, but are not described by the schema, such as comments, processing-instructions, schema-deviations, etc. (see section <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>). 
</li></ol><p>Each element grammar <em>Element</em><sub>&nbsp;i&nbsp;</sub> includes a sequence of <em>n</em> non-terminals <em>Element</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub>, where 0 &le; <em>j</em> &lt; <em>n</em>. The content of the entire element is described by the first non-terminal <em>Element</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub>. The remaining non-terminals describe portions of the element content. Likewise, each type grammar <em>Type</em><sub>&nbsp;i&nbsp;</sub> includes a sequence of <em>n</em> non-terminals <em>Type</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub> and the content of the entire type is described by the first non-terminal <em>Type</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub>.</p><p>The algorithms expressed in this section provide a concise and formal description of the EXI grammars for a given set of XML Schema definitions. More efficient algorithms likely exist for generating these EXI grammars and EXI implementations are free to use any algorithm that produces grammars and <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> that generate EXI encodings that match those produced by the grammars described here. </p><p>
An example is provided in the appendix (see <a href="#grammarExamples"><b>H Schema-informed Grammar Examples</b></a>) that demonstrates the process described in this section to generate a complete schema-informed element grammar from an element declaration
in a schema.
</p><div class="div4">
<h5><a name="protoGrammars" id="protoGrammars"></a>8.5.4.1 EXI Proto-Grammars</h5><p>This section describes the process for creating the EXI proto-grammars from XML Schema declarations and definitions. EXI proto-grammars differ from normalized EXI grammars in that they may contain productions of the form:</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>LeftHandSide</em> :</td></tr><tr><td></td><td width="5%"></td><td><em>RightHandSide</em></td></tr></tbody></table><p>where <em>LeftHandSide</em> and <em>RightHandSide</em> are both non-terminals. Whereas, all productions in a normalized EXI grammar contain exactly one terminal symbol and at most one non-terminal symbol on the right-hand side. This is a restricted form of Greibach normal form <a href="#greibach">[Greibach Normal Form]</a>. </p><p>EXI proto-grammars are derived from XML Schema in a straight-forward manner and can easily be normalized with simple algorithm (see <a href="#normalizedGrammars"><b>8.5.4.2 EXI Normalized Grammars</b></a>).
</p><div class="div5">
<h6><a name="grammarConcatOperator" id="grammarConcatOperator"></a>8.5.4.1.1 Grammar Concatenation Operator</h6><p>Proto-grammars are specified in a modular, constructive fashion. XML Schema components such as terms, particles, attribute uses are transformed each into a distinct proto-grammar, leveraging proto-grammars of their sub-components. At various stages of proto-grammar construction, two or more of proto-grammars are concatenated one after another to form more composite grammars.
</p><p>The grammar concatenation operator &oplus; is a binary, associative operator that creates a new grammar from its left and right grammar operands. The new grammar accepts any set of symbols accepted by its left operand followed by any set of symbols accepted by its right operand.
</p><p>Given a left operand <em>Grammar<sup>&nbsp;L</sup></em> and a right operand <em>Grammar<sup>&nbsp;R</sup></em>, the following operation
</p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>Grammar<sup>&nbsp;L</sup></em> &oplus; <em>Grammar<sup>&nbsp;R</sup></em>
</td></tr></tbody></table><p>creates a combined grammar by replacing each production of the form
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Grammar<sup>&nbsp;L</sup></em><sub>k</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table><p>where 0 &le; <em>k</em> &lt; <em>n</em> and <em>n</em> is the number of non-terminals that occur on the left-hand side of productions in <em>Grammar<sup>&nbsp;L</sup></em>, with a production of the form
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Grammar<sup>&nbsp;L</sup></em><sub>k</sub> : 
</td></tr><tr><td></td><td width="5%"></td><td>
<em>Grammar<sup>&nbsp;R</sup></em><sub>0</sub>
</td></tr></tbody></table><p>connecting each accept state of <em>Grammar<sup>&nbsp;L</sup></em> with the start state of <em>Grammar<sup>&nbsp;R</sup></em>.
</p></div><div class="div5">
<h6><a name="elementGrammars" id="elementGrammars"></a>8.5.4.1.2 Element Grammars</h6><p>This section describes the process for creating an EXI element grammar from an XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cElement_Declarations" class="">element declaration</a><sup><small>XS1</small></sup>. </p><p>Given an element declaration <em>E</em><sub>&nbsp;i&nbsp;</sub>, with properties {name}, {target&nbsp;namespace}, {type&nbsp;definition}, {scope} and {nillable}, create a corresponding EXI grammar <em>Element</em><sub>&nbsp;i&nbsp;</sub> for evaluating the contents of elements in the specified {scope} with <em>qname</em>&nbsp;local-name = {name} and <em>qname</em>&nbsp;uri  = {target&nbsp;namespace} 
where <em>qname</em> is the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the elements. 
</p><p>Let <em>T</em><sub>&nbsp;j</sub> be the {type&nbsp;definition} of <em>E</em><sub>&nbsp;i&nbsp;</sub> and <em>Type</em><sub>&nbsp;j&nbsp;</sub> be the type grammar created from <em>T</em><sub>&nbsp;j&nbsp;</sub>. The grammar <em>Element</em><sub>&nbsp;i&nbsp;</sub> describing the content model of <em>E</em><sub>&nbsp;i&nbsp;</sub> is created as follows.
</p><table width="100%"><thead><tr><th>Syntax:</th><th colspan="2">&nbsp;</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="2">
<em>Element</em><sub>&nbsp;i&nbsp;,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>Type</em><sub>&nbsp;j&nbsp;,&nbsp;0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><div class="div5">
<h6><a name="typeGrammars" id="typeGrammars"></a>8.5.4.1.3 Type Grammars</h6><p>Given an XML Schema type definition <em>T</em><sub>&nbsp;i&nbsp;</sub> 
with properties {name} and {target&nbsp;namespace}, 
two type grammars are created, which are denoted by <em>Type</em><sub>&nbsp;i&nbsp;</sub> and <em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub>. <span class="termdef"><a name="key-type" id="key-type">[Definition:]&nbsp;&nbsp;</a><b><em>Type</em></b><sub>&nbsp;i</sub> is a grammar that fully reflects the type definition of <em>T</em><sub>&nbsp;i&nbsp;</sub></span>, whereas <span class="termdef"><a name="key-type-empty" id="key-type-empty">[Definition:]&nbsp;&nbsp;</a><b><em>TypeEmpty</em></b><sub>&nbsp;i</sub> is a grammar that 
regards 
only the attribute uses and attribute wildcards of <em>T</em><sub>&nbsp;i&nbsp;</sub>, if any</span>.
</p><p>The grammar <em>Type</em><sub>&nbsp;i&nbsp;</sub> is used for evaluating the content of elements that are defined to be of type <em>T</em><sub>&nbsp;i&nbsp;</sub> in the schema. 
<span class="termdef"><a name="key-globalTypeGrammars" id="key-globalTypeGrammars">[Definition:]&nbsp;&nbsp;</a><em>Type</em><sub>&nbsp;i&nbsp;</sub> is a <b>global type grammar</b> when <em>T</em><sub>&nbsp;i&nbsp;</sub> is a named type.
</span> 
<em>Type</em><sub>&nbsp;i&nbsp;</sub>, when it is a global type grammar, can additionally be used as the effective grammar designated by a xsi:type attribute with the attribute value that is a <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> with local-name = {name} and uri = {target&nbsp;namespace}.
<em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub> is used in place of <em>Type</em><sub>&nbsp;i&nbsp;</sub> when the element instance that is being evaluated has a xsi:nil attribute with the value <em>true</em>.
</p><p>
<span class="termdef"><a name="key-contentIndex" id="key-contentIndex">[Definition:]&nbsp;&nbsp;</a>For each type grammar <em>Type</em><sub>&nbsp;i&nbsp;</sub>, an unique index number <b><em>content</em></b> is determined such that all non-terminal symbols of indices smaller than <em>content</em> have at least one 
AT terminal symbol 
and the rest of the non-terminal symbols in <em>Type</em><sub>&nbsp;i&nbsp;</sub> do not have 
AT terminal symbols 
on their right-hand side, where indices are assigned to non-terminal symbols in ascending order with the entry non-terminal symbol of <em>Type</em><sub>&nbsp;i&nbsp;</sub> being assigned index 0 (zero).</span>
There is also a <em>content</em> index associated with each <em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub> where its value is determined in the same manner as for <em>Type</em><sub>&nbsp;i&nbsp;</sub>.
</p><p>
Sections <a href="#simpleTypeGrammars"><b>8.5.4.1.3.1 Simple Type Grammars</b></a> and <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a> describe the processes for creating <em>Type</em><sub>&nbsp;i&nbsp;</sub> and <em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub> from XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#Simple_Type_Definitions" class="">simple type definitions</a><sup><small>XS1</small></sup> and <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#Complex_Type_Definitions" class="">complex type definitions</a><sup><small>XS1</small></sup> defined in schemas as well as <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-primitive-datatypes" class="">built-in primitive types</a><sup><small>XS2</small></sup>, <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-derived" class="">built-in derived types</a><sup><small>XS2</small></sup> and <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-anySimpleType" class="">simple ur-type</a><sup><small>XS2</small></sup> defined by XML Schema specification <a href="#schema2">[XML Schema Datatypes]</a>.

Section <a href="#anyTypeGrammar"><b>8.5.4.1.3.3 Complex Ur-Type Grammar</b></a> defines the grammar used for processing instances of element contents of type <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#d0e9252" class="">xsd:anyType</a><sup><small>XS1</small></sup>.
</p><div class="div6">

<h6><a name="simpleTypeGrammars" id="simpleTypeGrammars"></a>8.5.4.1.3.1 Simple Type Grammars</h6>
<p>This section describes the process for creating an EXI type grammar from an XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#Simple_Type_Definitions" class="">simple type definition</a><sup><small>XS1</small></sup>.</p>

<p>Given a simple type definition <em>T</em><sub>&nbsp;i&nbsp;</sub>, 
 create two new EXI grammars <a href="#key-type" class="termref"><span class="arrow"></span><em>Type</em><span class="arrow"></span></a><sub>&nbsp;i</sub> and <a href="#key-type-empty" class="termref"><span class="arrow"></span><em>TypeEmpty</em><span class="arrow"></span></a><sub>&nbsp;i</sub> 
following the procedure described below. 
</p>
<p>Add the following grammar productions to <em>Type</em><sub>&nbsp;i&nbsp;</sub> and  <em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub> : </p>

<table width="100%"><thead><tr><th>Syntax:</th><th colspan="2">&nbsp;</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="2">
<em>Type</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>CH [schema-typed value] <em>Type</em><sub>&nbsp;i,&nbsp;1&nbsp;</sub></td></tr><tr><td></td><td colspan="2">
<em>Type</em><sub>&nbsp;i,&nbsp;1&nbsp;</sub> :</td></tr><tr><td></td><td></td><td>EE</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>TypeEmpty</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table>
<table><tbody><tr><th align="left">Note:</th></tr><tr><td></td><td>
Productions of the form <em>LeftHandSide</em> : CH [schema-typed value] <em>RightHandSide</em> represent 
typed character data that can be represented using the EXI datatype representation associated with the simple type definition (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>).

Character data that can be represented using the EXI datatype representation associated with the simple type definition SHOULD be represented this way. Character data that is not represented using the EXI datatype representation associated with the simple type definition is represented by productions of the form <em>LeftHandSide</em> : CH [untyped&nbsp;value] <em>RightHandSide</em> described in section <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>.
</td></tr></tbody></table>
<p>
The <a href="#key-contentIndex" class="termref"><span class="arrow"></span><em>content</em><span class="arrow"></span></a> index of grammar <em>Type</em><sub>&nbsp;i&nbsp;</sub> 
and <em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub> 
created from an XML Schema simple type definition is always 0 (zero).
</p>

</div><div class="div6">

<h6><a name="complexTypeGrammars" id="complexTypeGrammars"></a>8.5.4.1.3.2 Complex Type Grammars</h6>
<p>This section describes the process for creating an EXI type grammar from an XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#Complex_Type_Definitions" class="">complex type definition</a><sup><small>XS1</small></sup>.</p>
<p>Given a complex type definition <em>T</em><sub>&nbsp;i&nbsp;</sub>, with properties {name}, {target&nbsp;namespace}, 
{attribute uses}, {attribute wildcard} and {content type}, 
 create two EXI grammars <a href="#key-type" class="termref"><span class="arrow"></span><em>Type</em><span class="arrow"></span></a><sub>&nbsp;i&nbsp;</sub> and <a href="#key-type-empty" class="termref"><span class="arrow"></span><em>TypeEmpty</em><span class="arrow"></span></a><sub>&nbsp;i&nbsp;</sub> 
following the procedure described below. 
</p>
<p>Generate a grammar <em>Attribute</em><sub>&nbsp;i&nbsp;</sub>, for each attribute use <em>A</em><sub>&nbsp;i</sub> in {attribute uses} according to section <a href="#attributeUses"><b>8.5.4.1.4 Attribute Uses</b></a>.
</p>
<p>Sort the attribute use grammars first by qname local-name, then by qname uri to form a sequence of grammars <em>G</em><sub>&nbsp;0&nbsp;</sub>, <em>G</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>G</em><sub>&nbsp;n&minus;1&nbsp;</sub>, where <em>n</em> is the number of attribute uses in {attribute uses}. 
</p>
<p>
If an {attribute wildcard} is specified, increment <em>n</em> and generate an additional attribute use grammar <em>G</em><sub>&nbsp;n&minus;1&nbsp;</sub> as follows:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;n&minus;1,&nbsp;0&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>EE</td></tr></tbody></table>
<p>
When the {attribute wildcard}'s {namespace&nbsp;constraint} is <em>any</em>, or 
a pair of <em>not</em> and either a namespace name or the special value 
<em>absent</em> indicating no namespace, 
add the following production to each grammar 
<em>G</em><sub>&nbsp;i&nbsp;</sub> 
generated above, 
where 0&nbsp;&le;&nbsp;<em>i</em>&nbsp;&lt;&nbsp;<em>n</em> :
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>AT&nbsp;(*) <em>G</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub></td></tr></tbody></table>

<p>
Otherwise, that is, when {namespace&nbsp;constraint} is a set of values whose members are namespace names or the special value <em>absent</em> indicating no namespace, 
add the following production to each grammar 
<em>G</em><sub>&nbsp;i&nbsp;</sub> 
generated above
where 0&nbsp;&le;&nbsp;<em>i</em>&nbsp;&lt;&nbsp;<em>n</em> :
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>AT(<em>uri<sub>x</sub></em> : *) <em>G</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub></td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td colspan="3">
<p>
where <em>uri</em><sub><em>x</em></sub> is a member value of {namespace&nbsp;constraint}, 
provided that it is the empty string (i.e. "") that is used as <em>uri</em><sub><em>x</em></sub> when the member value is the special value <em>absent</em>. 
Each <em>uri<sub>&nbsp;x&nbsp;</sub></em> is used to augment the uri partition of the String table.
Section <a href="#stringTablePartitions"><b>7.3.1 String Table Partitions</b></a> describes how these <em>uri</em> strings are put into String table for pre-population.
</p>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td colspan="3">

<table><tbody><tr><th align="left">Note:</th></tr><tr><td>&nbsp;</td></tr><tr><td>
<p>
When xsi:type and/or xsi:nil attributes appear in an element where schema-informed grammars are in effect, they MUST occur before any other AT events of the same element, with xsi:type placed before xsi:nil when they both occur.
</p>
</td></tr></tbody></table>

</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td colspan="3">


<table><tbody><tr><th align="left">Semantics:</th></tr><tr><td>&nbsp;</td></tr><tr><td>
<p>
In complex type grammars, 
all productions of the form 
<em>LeftHandSide</em>: AT&nbsp;(*) 
<em>RightHandSide</em> and <em>LeftHandSide</em>: AT(<em>uri</em><sub><em>x</em></sub> : *) 
<em>RightHandSide</em> 
that stem from attribute wildcards 
are evaluated as follows: </p>
</td></tr></tbody></table>

<ol class="enumar"><li>Let 
<em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the attribute matched by AT&nbsp;(*) or AT(<em>uri</em><sub><em>x</em></sub>&nbsp;:&nbsp;*)</li><li>If a global attribute definition exists for <em>qname</em>, let <em>global-type</em> be the datatype of the global attribute. If the attribute value can be represented using the datatype representation associated with <em>global-type</em>, it SHOULD be represented  using the datatype representation associated with <em>global-type</em> (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>). If the attribute value is not represented using the datatype representation associated with <em>global-type</em>, represent the 
attribute event 
using the AT&nbsp;(*) [untyped&nbsp;value] terminal (see <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>).
</li></ol>
<div class="note"><p class="prefix"><b>Note:</b></p>
When a schema-informed grammar is in effect, xsi:type and xsi:nil attributes MUST NOT be represented using AT(*) terminal.
</div>
</td></tr></tbody></table>

<p>
The grammar <em>TypeEmpty</em><sub>&nbsp;i</sub> is created by combining the sequence of attribute use grammars 
terminated by an empty {content type} grammar 
as follows:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td>
<em>TypeEmpty</em><sub>&nbsp;i</sub> = <em>G</em><sub>&nbsp;0</sub> &oplus; <em>G</em><sub>&nbsp;1</sub> &oplus; &hellip; &oplus; <em>G</em><sub>&nbsp;n&minus;1</sub> 
&oplus; <em>Content</em><sub>&nbsp;i</sub>
</td></tr></tbody></table>
<p>
where the grammar <em>Content</em><sub>&nbsp;i</sub> is created as follows: 
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Content</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table>

<p>
The <a href="#key-contentIndex" class="termref"><span class="arrow"></span><em>content</em><span class="arrow"></span></a> index of grammar <em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub> is the index of its last non-terminal symbol.
</p>

<p>
The grammar <em>Type</em><sub>&nbsp;i</sub> is generated as follows.
</p>

<p>If {content type} is a simple type definition
<em>T</em><sub>&nbsp;j</sub>
, generate a grammar <em>Content</em><sub>&nbsp;i</sub>
as <em>Type</em><sub>&nbsp;j</sub>
according to section <a href="#simpleTypeGrammars"><b>8.5.4.1.3.1 Simple Type Grammars</b></a>. 
If {content type} has a content model particle, generate a grammar <em>Content</em><sub>&nbsp;i</sub> according to section <a href="#particles"><b>8.5.4.1.5 Particles</b></a>.
Otherwise, if {content type} is <em>empty</em>, 
create a grammar <em>Content</em><sub>&nbsp;i</sub> as follows:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Content</em><sub>&nbsp;i</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table>

<p>
If {content type} is a content model particle with mixed content, add a production for each non-terminal <em>Content</em><sub>&nbsp;i&nbsp;,&nbsp;j&nbsp;</sub> in <em>Content</em><sub>&nbsp;i&nbsp;</sub> as follows:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Content</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>CH 
[untyped&nbsp;value] 
<em>Content</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub></td></tr></tbody></table>

<table width="100%"><thead><tr><th align="left" colspan="2">Note:</th></tr></thead><tbody><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;</td><td>
The value of each Characters event that has an [untyped&nbsp;value] is represented as a String (see <a href="#encodingString"><b>7.1.10 String</b></a>).
</td></tr></tbody></table>

<p>Then, create a copy <em>H</em><sub>&nbsp;i&nbsp;</sub> of each attribute use grammar <em>G</em><sub>&nbsp;i&nbsp;</sub> and create the grammar <em>Type</em><sub>&nbsp;i</sub> by combining this sequence of attribute use grammars and the <em>Content</em><sub>&nbsp;i</sub> grammar using the grammar concatenation operator defined in section <a href="#grammarConcatOperator"><b>8.5.4.1.1 Grammar Concatenation Operator</b></a> as follows:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td>
<em>Type</em><sub>&nbsp;i</sub> = <em>H</em><sub>&nbsp;0</sub> &oplus; <em>H</em><sub>&nbsp;1</sub> &oplus; &hellip; &oplus; <em>H</em><sub>&nbsp;n&minus;1</sub> &oplus; <em>Content</em><sub>&nbsp;i</sub>
</td></tr></tbody></table>
<p>
The <a href="#key-contentIndex" class="termref"><span class="arrow"></span><em>content</em><span class="arrow"></span></a> index of grammar <em>Type</em><sub>&nbsp;i&nbsp;</sub> created from an XML Schema complex type definition is the index of the first non-terminal symbol of <em>Content</em><sub>&nbsp;i</sub> within the context of <em>Type</em><sub>&nbsp;i&nbsp;</sub>.
</p>

</div><div class="div6">

<h6><a name="anyTypeGrammar" id="anyTypeGrammar"></a>8.5.4.1.3.3 Complex Ur-Type Grammar</h6>
<p>
XML Schema <a href="#schema1">[XML Schema Structures]</a> defines a 
<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#key-urType" class="">complex ur-type</a><sup><small>XS1</small></sup>
called <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#d0e9252" class="">xsd:anyType</a><sup><small>XS1</small></sup>, which is the default type for declared elements when no type is specified in the declaration. The type xsd:anyType can  be used as the type of declared elements in schemas, or as the explicit type given to elements by means of xsi:type attribute in <a href="#key-schemainformed-existream" class="termref"><span class="arrow"></span>schema-informed EXI streams<span class="arrow"></span></a>.
</p>
<p>When schemas are available to describe the body of an EXI stream, create 
grammars 
<a href="#key-type" class="termref"><span class="arrow"></span><em>Type</em><span class="arrow"></span></a><sub>&nbsp;ur-type</sub> and <a href="#key-type-empty" class="termref"><span class="arrow"></span><em>TypeEmpty</em><span class="arrow"></span></a><sub>&nbsp;ur-type</sub> that are used to process the element contents of type <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#d0e9252" class="">xsd:anyType</a><sup><small>XS1</small></sup> as shown below. 
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Type</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
AT&nbsp;(*) &nbsp;<em>Type</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
SE(*) &nbsp;<em>Type</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;1</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td></td><td></td><td>
CH &nbsp;<em>Type</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Type</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;1</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(*) &nbsp;<em>Type</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;1</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td></td><td></td><td>
CH &nbsp;<em>Type</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>TypeEmpty</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;0</sub> :
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) &nbsp;<em>TypeEmpty</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>TypeEmpty</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table>

<table width="100%"><thead><tr><th colspan="2" align="left">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
<p>In a schema-informed grammar, all productions of the form 
<em>LeftHandSide</em>: AT&nbsp;(*) 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let 
<em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the attribute matched by AT&nbsp;(*) </li><li>If a global attribute definition exists for <em>qname</em>, let <em>global-type</em> be the datatype of the global attribute. If the attribute value can be represented using the datatype representation associated with <em>global-type</em>, it SHOULD be represented  using the datatype representation associated with <em>global-type</em> (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>). If the attribute value is not represented using the datatype representation associated with <em>global-type</em>, represent the 
attribute event 
using the AT&nbsp;(*) [untyped&nbsp;value] terminal (see <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>).
</li></ol>
<div class="note"><p class="prefix"><b>Note:</b></p>
When a schema-informed grammar is in effect, xsi:type and xsi:nil attributes MUST NOT be represented using AT(*) terminal.
</div>

<p>
In a schema-informed grammar, all productions of the form 
<em>LeftHandSide</em> : SE&nbsp;(*) 
<em>RightHandSide</em> are evaluated as follows: </p>
<ol class="enumar"><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*) </li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>
Evaluate the remainder of event sequence using <em>RightHandSide</em></li></ol>
</td></tr></tbody></table>
<p>
The <a href="#key-contentIndex" class="termref"><span class="arrow"></span><em>content</em><span class="arrow"></span></a> index of 
grammars 
<em>Type</em><sub>&nbsp;ur-type</sub> 
and <em>TypeEmpty</em><sub>&nbsp;ur-type</sub> 
are both 1 (one). 
</p>
</div></div><div class="div5">
<h6><a name="attributeUses" id="attributeUses"></a>8.5.4.1.4 Attribute Uses</h6><p>
Given an attribute use <em>A</em><sub>&nbsp;i</sub> with properties {required} and {attribute&nbsp;declaration}, where {attribute&nbsp;declaration} has properties {name}, {target&nbsp;namespace}, {type&nbsp;definition} and {scope}, generate a new EXI grammar <em>Attribute</em><sub>&nbsp;i&nbsp;</sub> for evaluating attributes in the specified {scope} with <em>qname</em> local-name = {name} and <em>qname</em> uri = {target&nbsp;namespace}
where <em>qname</em> is the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the attributes. 
Add the following grammar productions to <em>Attribute</em><sub>&nbsp;i&nbsp;</sub>:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Attribute</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>AT(<em>qname</em>) [schema-typed value] <em>Attribute</em><sub>&nbsp;i,&nbsp;1&nbsp;</sub></td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Attribute</em><sub>&nbsp;i,&nbsp;1&nbsp;</sub> :</td></tr><tr><td></td><td></td><td>EE</td></tr></tbody></table><p>If the {required} property of <em>A</em><sub>&nbsp;i</sub> is false, add the following grammar production to indicate this attribute occurrence may be omitted from the content model.
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Attribute</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>EE</td></tr></tbody></table><table><tbody><tr><th align="left">Note:</th></tr><tr><td></td><td>
Productions of the form <em>LeftHandSide</em> : AT(<em>qname</em>) [schema-typed value] <em>RightHandSide</em> represent typed attributes that occur in schema-valid contexts with values that can be represented using the EXI datatype representation associated with the attribute's {type&nbsp;definition} (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>).
Attributes that occur in schema-valid contexts that can be represented using the EXI datatype representation associated with the attribute's {type&nbsp;definition}, SHOULD be represented this way. Attributes that are not represented this way, are represented using the alternate forms of AT events described in section <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>.
</td></tr></tbody></table></div><div class="div5">
<h6><a name="particles" id="particles"></a>8.5.4.1.5 Particles</h6><p>Given 
an XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cParticles" class="">particle</a><sup><small>XS1</small></sup> 
<em>P</em><sub>&nbsp;i</sub> with {min&nbsp;occurs}, {max&nbsp;occurs} and {term} properties, generate a grammar <em>Particle</em><sub>&nbsp;i</sub> for evaluating instances of <em>P</em><sub>&nbsp;i</sub> as follows.
</p><p>If {term} is an element declaration, generate the grammar <em>Term</em><sub>&nbsp;0</sub> according to section <a href="#elementTerms"><b>8.5.4.1.6 Element Terms</b></a>. If {term} is a wildcard, generate the grammar <em>Term</em><sub>&nbsp;0</sub> according to section <a href="#wildcardTerms"><b>8.5.4.1.7 Wildcard Terms</b></a> Wildcard Terms. If {term} is a model group, generate the grammar <em>Term</em><sub>&nbsp;0</sub> according to section <a href="#modelGroupTerms"><b>8.5.4.1.8 Model Group Terms</b></a>.
</p><p>Create {min&nbsp;occurs} copies of <em>Term</em><sub>&nbsp;0&nbsp;</sub>.
</p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>G</em><sub>&nbsp;0&nbsp;</sub>, <em>G</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>G</em><sub>&nbsp;{min&nbsp;occurs}-1&nbsp;</sub>
</td></tr></tbody></table><p>If {max&nbsp;occurs} is not unbounded, create {max&nbsp;occurs} &ndash; {min&nbsp;occurs} additional copies of <em>Term</em><sub>&nbsp;0&nbsp;</sub>,  </p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>G</em><sub>&nbsp;{min&nbsp;occurs}&nbsp;</sub>, <em>G</em><sub>&nbsp;{min&nbsp;occurs}+1&nbsp;</sub>, &hellip;, <em>G</em><sub>&nbsp;{max&nbsp;occurs}-1</sub>
</td></tr></tbody></table><p>Add the following productions to each of the grammars that do not already have a production of this form.
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub> :</td></tr><tr><td></td><td width="5%"></td><td>EE &nbsp;&nbsp;&nbsp;&nbsp;where {min&nbsp;occurs}&nbsp;&le;&nbsp;<em>i</em>&nbsp;&lt;&nbsp;{max&nbsp;occurs}</td></tr></tbody></table><p>indicating these instances of <em>Term</em><sub>&nbsp;0</sub> may be omitted from the content model. Then, create the grammar for <em>Particle</em><sub>&nbsp;i</sub> using the grammar concatenation operator defined in section <a href="#grammarConcatOperator"><b>8.5.4.1.1 Grammar Concatenation Operator</b></a> as follows:
</p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>Particle</em><sub>&nbsp;i</sub> = <em>G</em><sub>&nbsp;0</sub> &oplus; <em>G</em><sub>&nbsp;1</sub> &oplus; &hellip; &oplus; <em>G</em><sub>&nbsp;{max&nbsp;occurs}-1</sub>
</td></tr></tbody></table><p>
Otherwise, if {max&nbsp;occurs} is unbounded, generate one additional copy of <em>Term</em><sub>&nbsp;0&nbsp;</sub>, <em>G</em><sub>&nbsp;{min&nbsp;occurs}</sub> and replace all productions of the form: 
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;{min&nbsp;occurs},&nbsp;k</sub> :</td></tr><tr><td></td><td width="5%"></td><td>EE</td></tr></tbody></table><p>
with productions of the form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;{min&nbsp;occurs},&nbsp;k</sub> :</td></tr><tr><td></td><td width="5%"></td><td><em>G</em><sub>&nbsp;{min&nbsp;occurs},&nbsp;0</sub></td></tr></tbody></table><p>indicating this term may be repeated indefinitely. Then if there is no production of the form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;{min&nbsp;occurs},&nbsp;0</sub> : </td></tr><tr><td></td><td width="5%"></td><td>EE</td></tr></tbody></table><p>add one after the other productions with the non-terminal <em>G</em><sub>&nbsp;{min&nbsp;occurs},&nbsp;0</sub> on the left-hand side, indicating this term may be omitted from the content model. Then, create the grammar for <em>Particle</em><sub>&nbsp;i</sub> using the grammar concatenation operator defined in section <a href="#grammarConcatOperator"><b>8.5.4.1.1 Grammar Concatenation Operator</b></a> as follows:
</p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>Particle</em><sub>&nbsp;i</sub> = <em>G</em><sub>&nbsp;0</sub> &oplus; <em>G</em><sub>&nbsp;1</sub> &oplus; &hellip; &oplus; <em>G</em><sub>&nbsp;{min&nbsp;occurs}</sub>
</td></tr></tbody></table></div><div class="div5">
<h6><a name="elementTerms" id="elementTerms"></a>8.5.4.1.6 Element Terms</h6><p>
Given a particle {term} <em>PT</em><sub>&nbsp;i</sub> that is an XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cElement_Declarations" class="">element declaration</a><sup><small>XS1</small></sup> 
with properties {name}, 
{substitution&nbsp;group&nbsp;affiliation} 
and {target&nbsp;namespace}, let <em>S</em> be the set of element declarations that directly or indirectly reaches the element declaration <em>PT</em><sub>&nbsp;i</sub> through the chain of {substitution&nbsp;group&nbsp;affiliation} property of the elements, plus <em>PT</em><sub>&nbsp;i</sub> itself if was not in the set. Sort the element declarations in <em>S</em> lexicographically first by {name} then by {target&nbsp;namespace}, which makes a sorted list of element declarations <em>E<sub>&nbsp;0&nbsp;</sub></em>, <em>E<sub>&nbsp;1&nbsp;</sub></em>, &hellip; <em>E<sub>&nbsp;n&minus;1&nbsp;</sub></em> where <em>n</em> is the cardinality of <em>S</em>. Then create the grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub> with the following grammar productions:
</p><table width="100%"><thead><tr><th align="left" colspan="3">Syntax:</th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>qname</em><sub>&nbsp;0&nbsp;</sub>) <em>ParticleTerm</em><sub>&nbsp;i,&nbsp;1</sub>
</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>qname</em><sub>&nbsp;1&nbsp;</sub>) <em>ParticleTerm</em><sub>&nbsp;i,&nbsp;1</sub>
</td></tr><tr><td></td><td></td><td>&nbsp;&nbsp;&nbsp;&nbsp;⋮</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>qname</em><sub>&nbsp;n&minus;1&nbsp;</sub>) <em>ParticleTerm</em><sub>&nbsp;i,&nbsp;1</sub></td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="3">Note:</th></tr></thead><tbody><tr><td>&nbsp;</td><td colspan="2">&nbsp;</td></tr><tr><td></td><td colspan="2">
In the productions above, <em>qname<sub>&nbsp;x&nbsp;</sub></em> (where 0 &le;&nbsp;<em>x</em> &lt; n) represents a <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of which local-name and uri are {name} property and {target&nbsp;namespace} property of the element declaration <em>E<sub>&nbsp;x&nbsp;</sub></em>, respectively.</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="3">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td colspan="2">&nbsp;</td></tr><tr><td></td><td colspan="2">
In a schema-informed grammar, all productions of the form <em>LeftHandSide</em> : SE(<em>qname</em>) <em>RightHandSide</em> are evaluated as follows:
<ol class="enumar"><li>Evaluate the element contents using the SE(<em>qname</em>) grammar.</li><li>Evaluate the remainder of the event sequence using <em>RightHandSide</em></li></ol>

</td></tr></tbody></table></div><div class="div5">
<h6><a name="wildcardTerms" id="wildcardTerms"></a>8.5.4.1.7 Wildcard Terms</h6><p>
Given a particle {term} <em>PT</em><sub>&nbsp;i&nbsp;</sub> that is an XML Schema <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#Wildcards" class="">wildcard</a><sup><small>XS1</small></sup>
with property {namespace&nbsp;constraint}, a grammar that reflects the wildcard definition is created as follows.
</p><p>
Create a grammar <em>ParticleTerm</em><sub>&nbsp;i</sub> containing the following grammar production:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;1</sub> : 
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table><p>When the wildcard's {namespace&nbsp;constraint} is 
<em>any</em>, or a pair of <em>not</em> and either a namespace name or the special value <em>absent</em> indicating no namespace, 
add the following production to <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub>.
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
SE(*) <em>ParticleTerm</em><sub>&nbsp;i,&nbsp;1</sub>
</td></tr></tbody></table><p>
Otherwise, that is, when {namespace&nbsp;constraint} is a set of values whose members are namespace names or the special value <em>absent</em> indicating no namespace, 

add the following production to <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub>:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>uri<sub>&nbsp;x&nbsp;</sub></em>:&nbsp;*) <em>ParticleTerm</em><sub>&nbsp;i,&nbsp;1</sub>

</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table><p>
for each member value <em>uri</em><sub><em>x</em></sub> in {namespace&nbsp;constraint}, 

provided that it is the empty string (i.e. "") that is used as <em>uri</em><sub><em>x</em></sub> when the member value is the special value <em>absent</em>. 

Each <em>uri<sub>&nbsp;x&nbsp;</sub></em> is used to augment the uri partition of the String table.
Section <a href="#stringTablePartitions"><b>7.3.1 String Table Partitions</b></a> describes how these <em>uri</em> strings are put into String table for pre-population.
</p><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
In a schema-informed grammar, all productions of the form <em>LeftHandSide</em> : Terminal <em>RightHandSide</em> where Terminal is one of SE&nbsp;(*) or SE&nbsp;(<em>uri<sub>&nbsp;x&nbsp;</sub></em>:&nbsp;*) are evaluated as follows:
<ol class="enumar"><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*)
or SE(<em>uri<sub>&nbsp;x&nbsp;</sub></em>:&nbsp;*)
</li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>Evaluate the remainder of the event sequence using <em>RightHandSide</em></li></ol>
</td></tr></tbody></table></div><div class="div5">
<h6><a name="modelGroupTerms" id="modelGroupTerms"></a>8.5.4.1.8 Model Group Terms</h6><div class="div6">

<h6><a name="sequenceGroupTerms" id="sequenceGroupTerms"></a>8.5.4.1.8.1 Sequence Model Groups</h6>
<p>Given a particle {term} <em>PT</em><sub>&nbsp;i</sub> that is a model group with {compositor} equal to "sequence" and a list of <em>n</em> {particles} <em>P</em><sub>&nbsp;0&nbsp;</sub>, <em>P</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>P</em><sub>&nbsp;n&minus;1&nbsp;</sub>, create a grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub> as follows:
</p>
<p>If the value of <em>n</em> is 0, add the following productions to the grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub>.
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table>
<p>Otherwise, generate a sequence of grammars <em>Particle</em><sub>&nbsp;0&nbsp;</sub>, <em>Particle</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>Particle</em><sub>&nbsp;n&minus;1&nbsp;</sub> corresponding to the list of particles <em>P</em><sub>&nbsp;0&nbsp;</sub>, <em>P</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>P</em><sub>&nbsp;n&minus;1&nbsp;</sub> according to section <a href="#particles"><b>8.5.4.1.5 Particles</b></a>. Then combine the sequence of grammars using the grammar concatenation operator defined in section <a href="#grammarConcatOperator"><b>8.5.4.1.1 Grammar Concatenation Operator</b></a> as follows:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td>
<em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub> = <em>Particle</em><sub>&nbsp;0</sub> &oplus; <em>Particle</em><sub>&nbsp;1</sub> &oplus; &hellip; &oplus; <em>Particle</em><sub>&nbsp;n&minus;1</sub></td></tr></tbody></table>
</div><div class="div6">

<h6><a name="choiceGroupTerms" id="choiceGroupTerms"></a>8.5.4.1.8.2 Choice Model Groups</h6>
<p>Given a particle {term} <em>PT</em><sub>&nbsp;i</sub> that is a model group with {compositor} equal to "choice" and a list of <em>n</em> {particles} <em>P</em><sub>&nbsp;0&nbsp;</sub>, <em>P</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>P</em><sub>&nbsp;n&minus;1&nbsp;</sub>, create a grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub> as follows:
</p>
<p>
If the value of <em>n</em> is 0, add the following productions to the grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub>.
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table>
<p>Otherwise, generate a sequence of grammar productions <em>Particle</em><sub>&nbsp;0&nbsp;</sub>, <em>Particle</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>Particle</em><sub>&nbsp;n&minus;1</sub> corresponding to the list of particles <em>P</em><sub>&nbsp;0&nbsp;</sub>, <em>P</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>P</em><sub>&nbsp;n&minus;1</sub> according to section <a href="#particles"><b>8.5.4.1.5 Particles</b></a>. Then create the grammar <em>ParticleTerm</em><sub>&nbsp;i</sub> with the following grammar productions:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>Particle</em><sub>&nbsp;0,&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
</td></tr><tr><td></td><td></td><td>
<em>Particle</em><sub>&nbsp;1,&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td></tr><tr><td></td><td></td><td>
<em>Particle</em><sub>&nbsp;n&minus;1,&nbsp;0</sub>
</td></tr></tbody></table>
<p>
indicating the grammar for the term may accept any one of the given {particles}.
</p>
</div><div class="div6">

<h6><a name="allGroupTerms" id="allGroupTerms"></a>8.5.4.1.8.3 All Model Groups</h6>
<p>
Given a particle {term} <em>PT</em><sub>&nbsp;i</sub> that is a model group with {compositor} equal to "all" and a list of <em>n</em> &nbsp; {&nbsp;particles&nbsp;} <em>P</em><sub>&nbsp;0&nbsp;</sub>, <em>P</em><sub>&nbsp;1&nbsp;</sub>, ..., <em>P</em><sub>&nbsp;n&minus;1&nbsp;</sub>, create a grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub> as follows:
</p>
<p>
Add the following production to the grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub>.
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table>

<p>If the value of <em>n</em> is not 0, generate a sequence of grammar productions <em>Particle</em><sub>&nbsp;0&nbsp;</sub>, <em>Particle</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>Particle</em><sub>&nbsp;n&minus;1</sub> corresponding to the list of particles <em>P</em><sub>&nbsp;0&nbsp;</sub>, <em>P</em><sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>P</em><sub>&nbsp;n&minus;1&nbsp;</sub> according to section <a href="#particles"><b>8.5.4.1.5 Particles</b></a>. 
</p>

<p>Replace all productions of the form:</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Particle</em><sub>&nbsp;j&nbsp;,&nbsp;k</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
EE
</td></tr></tbody></table>
<p>
with productions of the form:
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Particle</em><sub>&nbsp;j&nbsp;,&nbsp;k</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub>
</td></tr></tbody></table>
<p>
where 0 &le;&nbsp;<em>j</em> &lt; <em>n</em>, and 0 &le;&nbsp;<em>k</em> &lt; <em>m</em> with <em>m</em> denoting the number non-terminals in the grammar <em>Particle</em><sub>&nbsp;j&nbsp;</sub>.
</p>
<p>
Add the following productions to the grammar <em>ParticleTerm</em><sub>&nbsp;i&nbsp;</sub>. 
</p>
<table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>ParticleTerm</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>Particle</em><sub>&nbsp;0,&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
</td></tr><tr><td></td><td></td><td>
<em>Particle</em><sub>&nbsp;1,&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td></tr><tr><td></td><td></td><td>
<em>Particle</em><sub>&nbsp;n&minus;1,&nbsp;0</sub>
</td></tr></tbody></table>

<div class="note"><p class="prefix"><b>Note:</b></p>
The grammar above can accept any sequence of the given {particles} in any order. This grammar is intentionally simple and succinct, enabling high-performance, low-footprint implementations on a wide range of devices, including those with very limited memory resources. More elaborate and precise grammars for the "all" group are possible; however, the associated improvement in precision is not sufficient to justify their code-footprint and memory resource requirements.  
</div>
</div></div></div><div class="div4">
<h5><a name="normalizedGrammars" id="normalizedGrammars"></a>8.5.4.2 EXI Normalized Grammars</h5><p>This section describes the process for converting an EXI proto-grammar 
generated 
from an XML Schema in accordance with section <a href="#protoGrammars"><b>8.5.4.1 EXI Proto-Grammars</b></a> into an EXI normalized grammar. Each production in an EXI normalized grammar has exactly one non-terminal symbol on the left-hand side and one terminal symbol on the right-hand side followed by at most one non-terminal symbol on the right-hand side. In addition, EXI normalized grammars contain no two grammar productions with the same non-terminal on the left-hand side and the same terminal symbol on the right-hand side. This is a restricted form of Greibach normal form <a href="#greibach">[Greibach Normal Form]</a>. 
</p><p>EXI proto-grammars differ from normalized EXI grammars in that they may contain productions of the form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>LeftHandSide</em> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>RightHandSide</em>
</td></tr></tbody></table><p>where <em>LeftHandSide</em> and <em>RightHandSide</em> are both non-terminals. Therefore, the first step of the normalization process focuses on replacing productions in this form with productions that conform to the EXI normalized grammar rules. This process can produce a grammar that has more than one production with the same non-terminal on the left-hand side and the same terminal symbol on the right-hand side. Therefore, the second step focuses on eliminating such productions.
</p><p>The first step of the normalization process is described in Section <a href="#eliminatingProductions"><b>8.5.4.2.1 Eliminating Productions with no Terminal Symbol</b></a>. The second step is described in section <a href="#eliminatingSymbols"><b>8.5.4.2.2 Eliminating Duplicate Terminal Symbols</b></a>. Once these two steps are completed, the grammar will be an EXI normalized grammar.
</p><div class="div5">
<h6><a name="eliminatingProductions" id="eliminatingProductions"></a>8.5.4.2.1 Eliminating Productions with no Terminal Symbol</h6><p>
Given an EXI proto-grammar <em>G</em><sub>&nbsp;i&nbsp;</sub>, with non-terminals <em>G</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub>, <em>G</em><sub>&nbsp;i,&nbsp;1&nbsp;</sub>, &hellip;, <em>G</em><sub>&nbsp;i,&nbsp;n&minus;1&nbsp;</sub>, replace each production of the form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>G</em><sub>&nbsp;i,&nbsp;k</sub>&nbsp;&nbsp;&nbsp;&nbsp;where 0&nbsp;&le;&nbsp;<em>j</em> &lt; <em>n</em> and 0&nbsp;&le;&nbsp;<em>k</em> &lt; <em>n</em>
</td></tr></tbody></table><p>with a set of productions:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;1</sub>
</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td></tr><tr><td></td><td></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;m-1</sub>
</td></tr></tbody></table><p>where <em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;0&nbsp;</sub>, <em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;1&nbsp;</sub>, &hellip;, <em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;m-1</sub> represents the right-hand side of each  production in <em>G</em><sub>&nbsp;i</sub> that has the non-terminal <em>G</em><sub>&nbsp;i,&nbsp;k</sub> on the left-hand side and <em>m</em> is the number of such productions. 
</p><p>
Remove such productions if any among <em>G</em><sub>&nbsp;i,&nbsp;j</sub> : <em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;h</sub> where 0 &le;&nbsp;<em>h</em> &lt; <em>m</em> of which the right-hand side either is identical to the left-hand side, or has previously been replaced while applying the process described in this section to productions with <em>G</em><sub>&nbsp;i,&nbsp;j</sub> on the left-hand side.
</p><p>Repeat this process until there are no more 
productions 
of the form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>G</em><sub>&nbsp;i,&nbsp;k</sub>&nbsp;&nbsp;&nbsp;&nbsp;where 0&nbsp;&le;&nbsp;<em>j</em> &lt; <em>n</em> and 0&nbsp;&le;&nbsp;<em>k</em> &lt; <em>n</em>
</td></tr></tbody></table><p>in the grammar <em>G</em><sub>&nbsp;i&nbsp;</sub>. 
</p></div><div class="div5">
<h6><a name="eliminatingSymbols" id="eliminatingSymbols"></a>8.5.4.2.2 Eliminating Duplicate Terminal Symbols</h6><p>Given an EXI proto-grammar <em>G</em><sub>&nbsp;i&nbsp;</sub>, with non-terminals <em>G</em><sub>&nbsp;i,&nbsp;0&nbsp;</sub>, <em>G</em><sub>&nbsp;i,&nbsp;1&nbsp;</sub>, &hellip;, <em>G</em><sub>&nbsp;i,&nbsp;n&minus;1&nbsp;</sub>, identify all pairs of productions that have the same non-terminal on the left-hand side and the same terminal symbol on the right-hand side of the form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;j</sub> : 
</td></tr><tr><td></td><td width="5%"></td><td>
Terminal <em>G</em><sub>&nbsp;i,&nbsp;k</sub>
</td></tr><tr><td></td><td></td><td>
Terminal <em>G</em><sub>&nbsp;i,&nbsp;l</sub>
</td></tr></tbody></table><p>where <em>k</em> &nbsp;&ne;&nbsp; <em>l</em> and Terminal represents a particular terminal symbol and replace them with a single production:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;j</sub> : 
</td></tr><tr><td></td><td width="5%"></td><td>
Terminal <em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;⊔&nbsp;l</sub>
</td></tr></tbody></table><p>
where <em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;⊔&nbsp;l</sub> is a distinct non-terminal that accepts the inputs accepted by <em>G</em><sub>&nbsp;i,&nbsp;k</sub> and the inputs accepted by <em>G</em><sub>&nbsp;i,&nbsp;l&nbsp;</sub>.

Here the notation "&nbsp;&nbsp;k&nbsp;⊔&nbsp;l&nbsp;&nbsp;" denotes a union set of integers and is used to uniquely identify the index of such a non-terminal.
</p><p>
When <em>G</em><sub>&nbsp;i&nbsp;</sub> is a type grammar, if both <em>k</em> and <em>l</em> are smaller than <a href="#key-contentIndex" class="termref"><span class="arrow"></span><em>content</em><span class="arrow"></span></a> index of <em>G</em><sub>&nbsp;i&nbsp;</sub>, k&nbsp;⊔&nbsp;l is also considered to be smaller than <em>content</em> for the purpose of index comparison purposes. Otherwise, if either  <em>k</em> or <em>l</em> is not smaller than <em>content</em>, k&nbsp;⊔&nbsp;l is considered to be larger than <em>content</em>.
</p><p>
 If the non-terminal <em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;⊔&nbsp;l</sub> does not exist, create it as follows: 
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;⊔&nbsp;l</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;1</sub>
</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td></tr><tr><td></td><td></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;m-1</sub>
</td></tr><tr><td></td><td></td><td>
</td></tr><tr><td></td><td></td><td>
&nbsp;
</td></tr><tr><td></td><td></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;l&nbsp;</sub>)<sub>&nbsp;0</sub>
</td></tr><tr><td></td><td></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;l&nbsp;</sub>)<sub>&nbsp;1</sub>
</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td></tr><tr><td></td><td></td><td>
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;l&nbsp;</sub>)<sub>&nbsp;n&minus;1</sub>
</td></tr></tbody></table><p>where <em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;0</sub>,
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;1</sub>,
&hellip;,
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;k&nbsp;</sub>)<sub>&nbsp;m-1</sub>
and
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;l&nbsp;</sub>)<sub>&nbsp;0</sub>, 
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;l&nbsp;</sub>)<sub>&nbsp;1</sub>,
&hellip;,
<em>RHS</em>(<em>G</em><sub>&nbsp;i,&nbsp;l&nbsp;</sub>)<sub>&nbsp;n&minus;1</sub>
represent the right-hand side of each  production in the Grammar <em>G</em><sub>&nbsp;i</sub> that has the non-terminals <em>G</em><sub>&nbsp;j,&nbsp;k</sub> and <em>G</em><sub>&nbsp;j,&nbsp;l</sub> on the left-hand side respectively and <em>m</em> and <em>n</em> are the number of such productions. 
</p><p>Repeat this process until there are no more productions in the grammar <em>G</em><sub>&nbsp;i</sub> of the form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;j</sub> : 
</td></tr><tr><td></td><td width="5%"></td><td>
Terminal <em>G</em><sub>&nbsp;i,&nbsp;k</sub>
</td></tr><tr><td></td><td></td><td>
Terminal <em>G</em><sub>&nbsp;i,&nbsp;l</sub>
</td></tr></tbody></table><p>Then, identify any identical productions of the following form: 
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>G</em><sub>&nbsp;i,&nbsp;j</sub> : 
</td></tr><tr><td></td><td width="5%"></td><td>
Terminal <em>G</em><sub>&nbsp;i,&nbsp;k</sub>
</td></tr><tr><td></td><td></td><td>
Terminal <em>G</em><sub>&nbsp;i,&nbsp;k</sub>
</td></tr></tbody></table><p>
where 0 &le; <em>k</em> &lt; <em>n</em>, <em>n</em> is the number of productions in <em>G</em><sub>&nbsp;i</sub> and Terminal represents a specific terminal symbol, then remove one of them until there are no more productions remaining in the grammar <em>G</em><sub>&nbsp;i</sub> of this form.
</p></div></div><div class="div4">
<h5><a name="eventCodeAssignment" id="eventCodeAssignment"></a>8.5.4.3 Event Code Assignment</h5><p>This section describes the process for assigning unique <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> to each production in a normalized EXI grammar. Given a normalized EXI grammar <em>G</em><sub>&nbsp;i&nbsp;</sub>, apply the following process to each unique non-terminal <em>G</em><sub>&nbsp;i,&nbsp;j</sub> that occurs on the left-hand side of the productions in <em>G</em><sub>&nbsp;i</sub> where 0&nbsp;&le;&nbsp;<em>j</em> &lt; <em>n</em> and <em>n</em> is the number of such non-terminals in <em>G</em><sub>&nbsp;i&nbsp;</sub>. 
</p><p>Sort all productions with <em>G</em><sub>&nbsp;i,&nbsp;j</sub> on the left-hand side in the following order:
</p><ol class="enumar"><li>
all productions with AT(<em>qname</em>) on the right-hand side
sorted lexicographically by <em>qname</em> local-name, then by <em>qname</em> uri, followed by
</li><li>
all productions with AT(<em>uri<sub>x</sub></em> : *) on the right-hand side sorted lexicographically by <em>uri</em>, followed by
</li><li>
any production with AT&nbsp;(*) on the right-hand side, followed by
</li><li>
all productions with SE(<em>qname</em>) on the right-hand side sorted in schema order, followed by
</li><li>
all productions with SE(<em>uri<sub>x</sub></em> : *) on the right-hand side sorted in schema order, followed by
</li><li>
any production with SE(*) on the right-hand side, followed by
</li><li>
any production with EE on the right-hand side, followed by
</li><li>
any production with CH on the right-hand side.
</li></ol><p>
In step 4 and step 5, the schema order of productions with SE(<em>qname</em>) and SE(<em>uri<sub>x</sub></em> : *) on the right-hand side is determined by the order of the corresponding particles in the schema after any references to named model groups in the schema are expanded in place with the group definitions themselves. A content model of a complex type can be seen as a tree that consists of particles where particles of either element declaration terms or wildcard terms appear as leaves, and the order is assigned to those leaf particles by traversing the tree by depth-first method.
</p><p>Given the sorted list of productions <em>P</em><sub>&nbsp;0&nbsp;</sub>, <em>P</em><sub>&nbsp;1&nbsp;</sub>, &hellip; <em>P</em><sub>&nbsp;n</sub> with the non-terminal <em>G</em><sub>&nbsp;i,&nbsp;j</sub> on the left-hand side, assign <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> to each of the productions as follows:
</p><table width="100%"><thead><tr><th colspan="2" align="left">Productions</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%"></td><td></td><td></td></tr><tr><td></td><td>
<em>P</em><sub>&nbsp;0</sub>
</td><td>
0
</td></tr><tr><td></td><td>
<em>P</em><sub>&nbsp;1</sub>
</td><td>
1
</td></tr><tr><td></td><td>
⋮
</td><td>
⋮
</td></tr><tr><td></td><td>
<em>P</em><sub>&nbsp;n&minus;1</sub>
</td><td>
<em>n</em>&minus;1
</td></tr></tbody></table></div><div class="div4">
<h5><a name="undeclaredProductions" id="undeclaredProductions"></a>8.5.4.4 Undeclared Productions</h5><p>The normalized element and type grammars 
generated 
from a schema describe the sequences of child elements, attributes and character events that may occur in a particular EXI stream. However, there are additional events that may occur in an EXI stream that are not described by the schema, for example events representing comments, processing-instructions, schema deviations, etc. 
</p><p>
This section first describes the process for, in cases with <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> value set to false, augmenting the normalized element and type grammars with productions that describe events that may occur in the EXI stream, but are not explicitly declared in the schema. It then describes the way, in cases with <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> value set to true, normalized element and type grammars are supplemented with productions to be prepared for the occurrences of xsi:type and xsi:nil attributes that are permitted by the schema. 
</p><p>
In the normalized grammars, terminal symbols AT and CH represent attribute and character events that can be represented by the EXI datatype representations associated with their schema datatypes (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>).
When the <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> is false, additional untyped AT and CH terminal symbols are added that can be used for representing attributes and character events that cannot be represented by the associated EXI datatype representations (e.g., schema-invalid values). The following table shows the notation used for such AT and CH terminals along with their definitions.
</p><table width="100%" border="1"><colgroup align="left" span="1"></colgroup><colgroup span="1"></colgroup><thead><tr><th align="center">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Notation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</th><th>Definition</th></tr></thead><tbody><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;AT&nbsp;(<em>qname</em>)&nbsp;[untyped&nbsp;value]</td><td>Terminal symbol that matches an attribute 
 
event with <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> <em>qname</em> and an untyped value.</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;AT&nbsp;(*) [untyped&nbsp;value]</td><td>Terminal symbol that matches an attribute 
 
event with any <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> and an untyped value.</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;CH [untyped&nbsp;value]</td><td>Terminal symbol that matches a characters 

event with an untyped value.</td></tr></tbody></table><div class="div5">
<h6><a name="addingProductions" id="addingProductions"></a>8.5.4.4.1 Adding Productions when Strict is False</h6><p>This section describes the process for augmenting the normalized grammars when the value of the <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> is false. For each normalized element grammar <em>Element</em><sub>&nbsp;i&nbsp;</sub>, create a copy <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub> of <em>Element</em><sub>&nbsp;i,&nbsp;content</sub> where the index "content" is the <a href="#key-contentIndex" class="termref"><span class="arrow"></span><em>content</em><span class="arrow"></span></a> of the type of the element from which <em>Element</em><sub>&nbsp;i&nbsp;</sub> was created. Then, apply the following procedures.</p><p>Add the following production to each non-terminal <em>Element</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub> that does not already include a production of the form <em>Element</em><sub>&nbsp;i,&nbsp;j</sub> : EE, such that 0 &le; j &le; content. 
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
EE
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><p>Let <em>E</em><sub>&nbsp;i</sub> be the element declaration from which <em>Element</em><sub>&nbsp;i</sub> was created and <em>T</em><sub>&nbsp;k</sub> be the {type&nbsp;definition} of <em>E</em><sub>&nbsp;i&nbsp;</sub>. Let 
<a href="#key-type" class="termref"><span class="arrow"></span>
<em>Type</em><sub>&nbsp;k</sub> 
<span class="arrow"></span></a>
and 
<a href="#key-type-empty" class="termref"><span class="arrow"></span>
<em>TypeEmpty</em><sub>&nbsp;k</sub> 
<span class="arrow"></span></a>
be the type grammars created from <em>T</em><sub>&nbsp;k</sub> (see section <a href="#typeGrammars"><b>8.5.4.1.3 Type Grammars</b></a>). Add the following productions to <em>Element</em><sub>&nbsp;i&nbsp;</sub>.  
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
AT(xsi:type) <em>Element</em><sub>&nbsp;i,&nbsp;0</sub> 
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td></td><td></td><td width="50%">
AT(xsi:nil) <em>Element</em><sub>&nbsp;i,&nbsp;0</sub>
</td><td>
<em>n</em>.(<em>m</em>+1)
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<p>
where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th colspan="2" align="left">Note:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
When xsi:type and/or xsi:nil attributes appear in an element where schema-informed grammars are in effect, they MUST occur before any other 
attribute 
events of the same element, with xsi:type placed before xsi:nil when they both occur.
</td></tr><tr><td>&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
All productions of the form <em>LeftHandSide</em> : AT&nbsp;(xsi:type) <em>RightHandSide</em> are evaluated as follows:
<ol class="enumar"><li>Let <em>target-type</em> be the value of the xsi:type attribute and assign it the QName datatype representation (see <a href="#encodingQName"><b>7.1.7 QName</b></a>).</li><li>If there is no namespace in scope for the specified <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> prefix, set the <em>uri</em> of <em>target-type</em> to empty ("") and the <em>localName</em> to the full lexical value of the QName, including the prefix. </li><li>Represent the value of <em>target-type</em> according to section <a href="#encodingValues"><b>7. Representing Event Content</b></a>.</li><li>
If a grammar can be found for the <em>target-type</em> type using the encoded <em>target-type</em> representation, 
evaluate the element contents using the grammar for <em>target-type</em> type instead of <em>RightHandSide</em>. </li></ol>
</td></tr><tr><td></td><td>
In a schema-informed grammar, all productions of the form <em>LeftHandSide</em> : AT&nbsp;(xsi:nil) <em>RightHandSide</em> are evaluated as follows: 
<ol class="enumar"><li>
Let <em>nil</em> be the value of the xsi:nil attribute.
</li><li>If <em>nil</em> is a valid Boolean, assign it the Boolean datatype representation (see <a href="#encodingBoolean"><b>7.1.2 Boolean</b></a>) and encode it according to section <a href="#encodingValues"><b>7. Representing Event Content</b></a>. If <em>nil</em> is not a valid Boolean, represent the 
xsi:nil attribute 
event using the AT&nbsp;(*) [untyped&nbsp;value] terminal (see <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>). 
</li><li>
If the value of <em>nil</em> is true, evaluate the element contents using the grammar 
<em>TypeEmpty</em><sub>&nbsp;k</sub> 
defined above rather than <em>RightHandSide</em>. 
</li></ol>
</td></tr></tbody></table><p>
For each non-terminal <em>Element</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub>, such that 0 &le; j &le; content&nbsp;, with zero or more productions of the following form:
</p><table width="100%"><tbody><tr><td width="5%"></td><td colspan="2">
<em>Element</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
AT&nbsp;(<em>qname</em><sub>&nbsp;0&nbsp;</sub>) [schema-typed value] 
<em>NonTerminal</em><sub>&nbsp;0&nbsp;</sub>
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<em>qname</em><sub>&nbsp;1&nbsp;</sub>) [schema-typed value]
<em>NonTerminal</em><sub>&nbsp;1&nbsp;</sub>
</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<em>qname</em><sub>&nbsp;<em>x</em>-1&nbsp;</sub>) [schema-typed value]
<em>NonTerminal</em><sub>&nbsp;x-1&nbsp;</sub>
</td></tr></tbody></table><p>where <em>x</em> represents the number of attributes declared in the schema for this context, add the following productions:
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
AT&nbsp;(*) <em>Element</em><sub>&nbsp;i,&nbsp;j</sub>
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<em>qname</em><sub>&nbsp;0&nbsp;</sub>) [untyped&nbsp;value] <em>NonTerminal</em><sub>&nbsp;0&nbsp;</sub>
</td><td>
<em>n</em>.(<em>m</em>+1).0
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<em>qname</em><sub>&nbsp;1&nbsp;</sub>) [untyped&nbsp;value] <em>NonTerminal</em><sub>&nbsp;1&nbsp;</sub>
</td><td>
<em>n</em>.(<em>m</em>+1).1
</td></tr><tr><td></td><td></td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td><td>
&nbsp;&nbsp;&nbsp;&nbsp;⋮
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(<em>qname</em><sub>&nbsp;<em>x</em>-1&nbsp;</sub>) [untyped&nbsp;value] <em>NonTerminal</em><sub>&nbsp;x-1&nbsp;</sub>
</td><td>
<em>n</em>.(<em>m</em>+1).(<em>x</em>-1)
</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) [untyped&nbsp;value] <em>Element</em><sub>&nbsp;i,&nbsp;j</sub>
</td><td>
<em>n</em>.(<em>m</em>+1).(<em>x</em>)
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left">Note:</th></tr></thead><tbody><tr><td>&nbsp;
</td></tr><tr><td>
<ul><li>
The value of each 
attribute 
event that has an [untyped&nbsp;value] is represented as a String (see <a href="#encodingString"><b>7.1.10 String</b></a>).
</li></ul>
</td></tr><tr><td>
<ul><li>
Like an element, an attribute may occur in a schema-invalid context, have a untyped (e.g., schema-invalid) value or both. However, unlike an element whose occurrence and value are represented by separate SE and CH events, the occurrence and value of an attribute are represented by a single AT event. Consequently, four kinds of AT 
terminal symbols 
are needed for the four possible representations of an attribute event 
in schema-informed grammars. 
The table below shows these four kinds of AT terminal symbols 
along with the equivalent combinations of SE and CH 
terminal symbols 
for representing elements. 
<p></p><a name="table-at-terminals" id="table-at-terminals"></a><table border="1" width="95%"><caption>Table 8-1. 
Equivalent terminal symbols 
for different attribute and element representations</caption><colgroup width="20%" span="1"></colgroup><colgroup width="40%" span="1"></colgroup><colgroup width="40%" span="1"></colgroup><thead><tr><th>&nbsp;</th><th>Schema-typed value</th><th>Untyped value</th></tr></thead><tbody><tr><th>Schema-valid occurrence</th><td>
<table border="0"><tr><td>AT&nbsp;(<em>qname</em>) [schema-typed value]</td></tr><tr><td>SE&nbsp;(<em>qname</em>) CH [schema-typed value]</td></tr></table></td><td>
<table border="0"><tr><td>AT&nbsp;(<em>qname</em>) [untyped&nbsp;value]</td></tr><tr><td>SE&nbsp;(<em>qname</em>) CH [untyped&nbsp;value]</td></tr></table></td></tr><tr><th>Schema-invalid occurrence</th><td>
<table border="0"><tr><td>AT&nbsp;(*)</td></tr><tr><td>SE&nbsp;(*) CH [schema-typed value]</td></tr></table></td><td>
<table><tr><td>AT&nbsp;(*) [untyped&nbsp;value]</td></tr><tr><td>SE&nbsp;(*) CH [untyped&nbsp;value]</td></tr></table>
</td></tr></tbody></table><p>
Note that an attribute matching AT&nbsp;(*) terminal without [untyped&nbsp;value] predication 
in schema-informed grammars bears an untyped value unless there is a global attribute 
definition available for <em>qname</em> where <em>qname</em> is the 
<a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the attribute. 
When a global attribute definition is available for <em>qname</em>, the attribute 
value is represented according to the datatype of the global attribute.
</p><p>
In the above table, AT&nbsp;(*) terminal without [untyped&nbsp;value] predication is shown 
only in the bottom left cell for simplicity. To be more precise, it might well extend into the 
bottom right cell because attributes matching the terminal bear schema-typed values in
some cases or untyped values in others depending on the availability of a global 
attribute definition that denotes the attribute.
</p></li></ul>
</td></tr><tr><td>
<ul><li>
When xsi:type and/or xsi:nil attributes appear in an element where schema-informed grammars are in effect, they MUST occur before any other 
attribute 
events of the same element, with xsi:type placed before xsi:nil when they both occur.
</li></ul>
</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
In a schema-informed grammar, 
all productions of the form <em>LeftHandSide</em> : AT&nbsp;(*) are evaluated as follows: 
<ol class="enumar"><li>
Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the attribute matched by AT&nbsp;(*)
</li><li>If a global attribute definition exists for <em>qname</em>, let <em>global-type</em> be the datatype of the global attribute. If the attribute value can be represented using the datatype representation associated with <em>global-type</em>, it SHOULD be represented  using the datatype representation associated with <em>global-type</em> (see <a href="#encodingValues"><b>7. Representing Event Content</b></a>). If the attribute value is not represented using the datatype representation associated with <em>global-type</em>, represent the 
attribute event 
using the AT&nbsp;(*) [untyped&nbsp;value] terminal (see <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a>).
</li></ol>
</td></tr><tr><td colspan="2">
<div class="note"><p class="prefix"><b>Note:</b></p>
When a schema-informed grammar is in effect, xsi:type and xsi:nil attributes MUST NOT be represented using AT(*) terminal. AT(*) [untyped value] terminal, on the other hand, can be used to represent an xsi:nil attribute when there is a production of the form <em>LeftHandSide</em> : AT&nbsp;(xsi:nil) where <em>LeftHandSide</em> is the left-hand side non-terminal of the AT(*) [untyped value] terminal in question, and the value of the xsi:nil attribute is unable to be represented using AT&nbsp;(xsi:nil) terminal. AT(*) [untyped value] terminal MUST NOT be used to represent xsi:type attributes.
</div>
</td></tr></tbody></table><p>
Add the following production to <em>Element</em><sub>&nbsp;i&nbsp;</sub>. 
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
NS <em>Element</em><sub>&nbsp;i,&nbsp;0</sub> 
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><p>
When the value of the <a href="#key-selfContained" class="termref"><span class="arrow"></span>selfContained option<span class="arrow"></span></a> is true, add the following production to <em>Element</em><sub>&nbsp;i&nbsp;</sub>. 
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
SC <em>Fragment</em> 
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr></tbody></table><p></p><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
All productions of the form <em>LeftHandSide</em> : SC <em>Fragment</em> are evaluated as follows: 
<ol class="enumar"><li>
Save the string table, grammars and any implementation-specific state learned while processing this EXI Body.
</li><li>Initialize the string table, grammars and any implementation-specific state learned while processing this EXI Body to the state they held just prior to processing this EXI Body.
</li><li>Skip to the next byte-aligned boundary in the stream 
if it is not already at such a boundary.
</li><li>Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the SE event immediately preceding this SC event.</li><li>Let <em>content</em> be the sequence of events following this SC event that match the grammar for element <em>qname</em>, up to and including the terminating EE event.</li><li>Evaluate the sequence of events (SD, SE(<em>qname</em>), <em>content</em>, ED) according to the <em>Fragment</em> grammar. (see <a href="#informedFragGrammars"><b>8.5.2 Schema-informed Fragment Grammar</b></a>)
</li><li>Skip to the next byte-aligned boundary in the stream 
if it is not already at such a boundary.
</li><li>Restore the string table, grammars and implementation-specific state learned while processing this EXI Body to that saved in step 1 above.
</li></ol>
</td></tr></tbody></table><p>
Add the following productions to each non-terminal <em>Element</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub>, such that 0 &le; j &le; content&nbsp;.
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
SE&nbsp;(*) <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub>
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub>
</td><td>
<em>n</em>.(<em>m</em>+1)
</td></tr><tr><td></td><td></td><td>
ER <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub>
</td><td>
<em>n</em>.(<em>m</em>+2)
</td></tr><tr><td></td><td></td><td>
CM <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub>
</td><td>
<em>n</em>.(<em>m</em>+3).0
</td></tr><tr><td></td><td></td><td>
PI <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub>
</td><td>
<em>n</em>.(<em>m</em>+3).1
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left">Note:</th></tr></thead><tbody><tr><td>&nbsp;
</td></tr><tr><td>
<ul><li>
Productions of the form <em>LeftHandSide</em> : CH [untyped&nbsp;value] <em>RightHandSide</em> match untyped character data represented as a String in the EXI stream (e.g., schema-invalid values). Character data represented using the datatype representation associated with the schema datatype of the character data are matched by productions of the form <em>LeftHandSide</em> : CH [schema-typed value] <em>RightHandSide</em> described in section <a href="#simpleTypeGrammars"><b>8.5.4.1.3.1 Simple Type Grammars</b></a>.
</li></ul>
</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
In a schema-informed grammar, all productions of the form <em>LeftHandSide</em> : SE&nbsp;(*) <em>RightHandSide</em>  are evaluated as follows:
<ol class="enumar"><li>
Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*)
</li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>
Evaluate the remainder of the event sequence using <em>RightHandSide</em></li></ol>
</td></tr></tbody></table><p>Add the following production to <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub> and to each non-terminal <em>Element</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub> that does not already include a production of the form <em>Element</em><sub>&nbsp;i,&nbsp;j</sub> : EE, such that content &lt; <em>j</em> &lt; <em>n</em>, where <em>n</em> is the number of non-terminals in <em>Element</em><sub>&nbsp;i&nbsp;</sub>. 
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
EE
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><p>Add the following productions to <em>Element</em><sub>&nbsp;i,&nbsp;content2</sub> and to each non-terminal <em>Element</em><sub>&nbsp;i,&nbsp;j&nbsp;</sub>, such that content &lt; <em>j</em> &lt; <em>n</em>, where <em>n</em> is the number of non-terminals in <em>Element</em><sub>&nbsp;i&nbsp;</sub>. 
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;j</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
SE&nbsp;(*) <em>Element</em><sub>&nbsp;i,&nbsp;j</sub>
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td></td><td></td><td>
CH [untyped value] <em>Element</em><sub>&nbsp;i,&nbsp;j</sub>
</td><td>
<em>n</em>.(<em>m</em>+1)
</td></tr><tr><td></td><td></td><td>
ER <em>Element</em><sub>&nbsp;i,&nbsp;j</sub>
</td><td>
<em>n</em>.(<em>m</em>+2)
</td></tr><tr><td></td><td></td><td>
CM <em>Element</em><sub>&nbsp;i,&nbsp;j</sub>
</td><td>
<em>n</em>.(<em>m</em>+3).0
</td></tr><tr><td></td><td></td><td>
PI <em>Element</em><sub>&nbsp;i,&nbsp;j</sub>
</td><td>
<em>n</em>.(<em>m</em>+3).1
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td>
</td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td>&nbsp;</td><td></td></tr><tr><td></td><td>
In a schema-informed grammar, all productions of the form <em>LeftHandSide</em> : SE&nbsp;(*) <em>RightHandSide</em>  are evaluated as follows:
<ol class="enumar"><li>
Let <em>qname</em> be the <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> of the element matched by SE&nbsp;(*)
</li><li>
If a <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> does not exist for element <em>qname</em>, create one according to section <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>. 
</li><li>
Evaluate the element content using the <a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammar<span class="arrow"></span></a> for element <em>qname</em>.
</li><li>
Evaluate the remainder of the event sequence using <em>RightHandSide</em></li></ol>
</td></tr></tbody></table><p>Apply the process described above for element grammars to each normalized type grammar 
<a href="#key-type" class="termref"><span class="arrow"></span><em>Type</em><sub>&nbsp;i&nbsp;</sub><span class="arrow"></span></a> and
<a href="#key-type-empty" class="termref"><span class="arrow"></span><em>TypeEmpty</em><sub>&nbsp;i&nbsp;</sub><span class="arrow"></span></a>.
</p></div><div class="div5">
<h6><a name="addingProductionsStrict" id="addingProductionsStrict"></a>8.5.4.4.2 Adding Productions when Strict is True</h6><p>This section describes the process for augmenting the normalized grammars when the value of the <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> is true. For each normalized element grammar <em>Element</em><sub>&nbsp;i&nbsp;</sub>, apply the following procedures.</p><p>Let <em>E</em><sub>&nbsp;i</sub> be the element declaration from which <em>Element</em><sub>&nbsp;i</sub> was created and <em>T</em><sub>&nbsp;k</sub> be the {type&nbsp;definition} of <em>E</em><sub>&nbsp;i&nbsp;</sub>. If <em>T</em><sub>&nbsp;k</sub> 
either has named sub-types or is a simple type definition of which {variety} is <em>union</em>, 
add the following production to <em>Element</em><sub>&nbsp;i&nbsp;</sub>.  
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
AT(xsi:type) <em>Element</em><sub>&nbsp;i,&nbsp;0</sub> 
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td colspan="2">&nbsp;
</td></tr><tr><td colspan="2">
All productions of the form <em>LeftHandSide</em> : AT&nbsp;(xsi:type) <em>RightHandSide</em> are evaluated as follows: 
</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td><td>
<ol class="enumar"><li>Let <em>target-type</em> be the value of the xsi:type attribute and assign it the QName datatype representation (see <a href="#encodingQName"><b>7.1.7 QName</b></a>).</li><li>If there is no namespace in scope for the specified <a href="#key-qname" class="termref"><span class="arrow"></span>qname<span class="arrow"></span></a> prefix, set the <em>uri</em> of <em>target-type</em> to empty ("") and the <em>localName</em> to the full lexical value of the QName, including the prefix. </li><li>Represent the value of <em>target-type</em> according to section <a href="#encodingValues"><b>7. Representing Event Content</b></a>.</li><li>
If a grammar can be found for the <em>target-type</em> type using the encoded <em>target-type</em> representation, 
evaluate the element contents using the grammar for <em>target-type</em> type instead of <em>RightHandSide</em>. </li></ol>
</td></tr></tbody></table><p>
Let 
<a href="#key-type" class="termref"><span class="arrow"></span>
<em>Type</em><sub>&nbsp;k</sub> 
<span class="arrow"></span></a>
and 
<a href="#key-type-empty" class="termref"><span class="arrow"></span>
<em>TypeEmpty</em><sub>&nbsp;k</sub> 
<span class="arrow"></span></a>
be the type grammars created from <em>T</em><sub>&nbsp;k</sub> (see section <a href="#typeGrammars"><b>8.5.4.1.3 Type Grammars</b></a>). If the {nillable} property of <em>E</em><sub>&nbsp;i</sub> is true, add the following production to <em>Element</em><sub>&nbsp;i&nbsp;</sub>.
</p><table width="100%"><thead><tr><th colspan="3" align="left">Syntax</th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%">&nbsp;</td><td width="5%"></td><td></td><td></td></tr><tr><td></td><td colspan="3">
<em>Element</em><sub>&nbsp;i,&nbsp;0</sub> :
</td></tr><tr><td></td><td></td><td width="50%">
AT(xsi:nil) <em>Element</em><sub>&nbsp;i,&nbsp;0</sub>
</td><td>
<em>n</em>.<em>m</em>
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<p>where <em>n</em>.<em>m</em> represents the next available <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> with length 2. 
</p>
</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><table width="100%"><thead><tr><th align="left" colspan="2">Semantics:</th></tr></thead><tbody><tr><td colspan="2">&nbsp;
</td></tr><tr><td colspan="2">
In a schema-informed grammar, all productions of the form <em>LeftHandSide</em> : AT&nbsp;(xsi:nil) <em>RightHandSide</em> are evaluated as follows: 
</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td><td>
<ol class="enumar"><li>
Let <em>nil</em> be the value of the xsi:nil attribute.
</li><li>If <em>nil</em> is a valid Boolean, assign it the Boolean datatype representation (see 
<a href="#encodingBoolean"><b>7.1.2 Boolean</b></a>) and encode it according to section <a href="#encodingValues"><b>7. Representing Event Content</b></a>. Otherwise, the value of the <em>nil</em> is schema-invalid and cannot be represented when the value of the <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> is true. 
</li><li>
If the value of <em>nil</em> is true, evaluate the element contents using the grammar 
<em>TypeEmpty</em><sub>&nbsp;k</sub> 
defined above rather than <em>RightHandSide</em>. 
</li></ol>
</td></tr></tbody></table><a name="strictRestrictions" id="strictRestrictions"></a><table width="100%"><thead><tr><th colspan="2" align="left">Note:</th></tr></thead><tbody><tr><td colspan="2">&nbsp;
</td></tr><tr><td colspan="2">
<ul><li>
When xsi:type or xsi:nil attributes appear in an element where schema-informed grammars are in effect with <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> value <em>true</em>, they MUST occur before any other attribute events of the same element.
</li></ul>
</td></tr><tr><td colspan="2">
<ul><li>
There are several restrictions peculiar to schema-informed element and type grammars created with <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> value <em>true</em> in the ability to represent a small number of uncommon element information item formulations yet valid to the schemas. This is a consequence of intentional grammar simplification aimed to make the grammars compact enough for and the amount of footprint necessary to process the grammars amenable even to extremely resource-deprived devices. Itemized below are such restrictions. Those restrictions need to be given heed to in the process of making a decision to choose the right <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> value that works best for each use case.
</li></ul>
</td></tr><tr><td>&nbsp;&nbsp;&nbsp;&nbsp;</td><td>
<ul type="circle"><li>
It is not possible to use xsi:type and xsi:nil attributes together on the same element. 
This is due to the fact that xsi:type specifies a target type definition, but xsi:nil is only permitted on nillable elements, not type definitions.
</li></ul>
</td></tr><tr><td></td><td>
<ul type="circle"><li>
It is not possible to use xsi:type for explicitly denoting the natural type (i.e. the type immediately given to an element definition in the schema) of the element unless such a type has named sub-types or is a simple type definition of which {variety} is <em>union</em>.
</li></ul>
</td></tr><tr><td></td><td>
<ul type="circle"><li>
Namespace declarations are not available instream. A consequence of this is that instream namespace declarations otherwise available when <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> value is <em>false</em> cannot be turned to for helping decompose <a href="http://www.w3.org/TR/2006/REC-xml-names-20060816/#dt-qualname" class="">qualified names</a><sup><small>NS</small></sup> in AT or CH values into pairs of uri and local-name, including xsi:type attribute values encoded with the <a href="#key-preserveLexicalValuesOption" class="termref"><span class="arrow"></span>Preserve.lexicalValues<span class="arrow"></span></a> option value <em>true</em> wherein the qualified names are represented using String datatype representation (see <a href="#encodingString"><b>7.1.10 String</b></a>) instead of QName datatype representation (see <a href="#encodingQName"><b>7.1.7 QName</b></a>).
</li></ul>
</td></tr><tr><td></td><td>
<ul type="circle"><li>
The attributes xsi:schemaLocation and xsi:noNamespaceSchemaLocation can appear only when they match specific schema declarations (i.e., wildcards or ur-types). 
</li></ul>
</td></tr></tbody></table></div></div></div></div></div><div class="div1">
<h2><a name="compression" id="compression"></a>9. EXI Compression</h2><p>
The use of EXI compression increases compactness utilizing additional computational resources. EXI compression combines knowledge of XML with a widely adopted, standard compression algorithm to achieve higher compression ratios than would be achievable by applying compression to the entire stream.</p><p>
EXI compression is applied when <a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression<span class="arrow"></span></a> is turned on or when <a href="#key-alignmentOption" class="termref"><span class="arrow"></span>alignment <span class="arrow"></span></a> is set to <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a>. Byte-aligned representations of <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> are more amenable to compression algorithms compared to unaligned representations because most compression algorithms operate on series of bytes to identify redundancies in the octets. Therefore, when EXI compression is used, <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and <a href="#key-content-item" class="termref"><span class="arrow"></span>content items<span class="arrow"></span></a> of EXI events are encoded as aligned bytes in accordance with <a href="#encodingEventCodes"><b>6.2 Representing Event Codes</b></a> and <a href="#encodingValues"><b>7. Representing Event Content</b></a>.</p><p>EXI compression splits a sequence of EXI events into a number of contiguous blocks of events.
Events that belong to the same block are transformed into lower entropy groups of similar values called <em>channels</em>, which are individually well suited for standard compression algorithms. To reduce compression overhead, smaller channels are combined before compressing them, while larger channels are compressed independently. The criteria EXI compression uses to define and combine channels is intentionally simple to facilitate implementation, reduce processing overhead, and avoid the need to encode channel ordering or grouping information in the format. The figure below presents a schematic view of the steps involved in EXI compression.
</p><div class="figure" style="text-align: center"><br><img src="compression.png" alt="EXI Compression Overview"><p><i><span>Figure 9-1. </span>EXI Compression Overview</i></p><br></div><p>In the following sections, <a href="#blocks"><b>9.1 Blocks</b></a> defines blocks and explains how EXI events are partitioned into blocks.
Section <a href="#channels"><b>9.2 Channels</b></a> defines channels, their organization as well as how a group of channels correlate to its corresponding block of events.
Section <a href="#CompressedStreams"><b>9.3 Compressed Streams</b></a> describes how some channels are combined as needed in preparation for applying compression algorithms on channels.
</p><div class="div2">
<h3><a name="blocks" id="blocks"></a>9.1 Blocks</h3><p>EXI compression partitions the sequence of EXI events into a sequence of one or more non-overlapping blocks. Each block preceding the final block contains the minimum set of consecutive events that result in exactly <a href="#key-blockSizeOption" class="termref"><span class="arrow"></span>blockSize<span class="arrow"></span></a>&nbsp;<em>values</em> in its value channels (see <a href="#ValueChannels"><b>9.2.2 Value Channels</b></a>), where blockSize is the block size of the EXI stream (see <a href="#options"><b>5.4 EXI Options</b></a>). The final block contains 
less than the minimum set of consecutive events that result in blockSize <em>values</em> in its value channels. 
</p></div><div class="div2">
<h3><a name="channels" id="channels"></a>9.2 Channels</h3><p>Events inside each block are multiplexed into channels. The first channel of each block is the structure channel described in Section <a href="#StructureChannel"><b>9.2.1 Structure Channel</b></a>. The remaining channels in each block are value channels described in Section <a href="#ValueChannels"><b>9.2.2 Value Channels</b></a>.
The diagram below presents an exemplary view of the transformation in which events within a block are multiplexed into channels in one way and channels are demultiplexed into events in the other way.</p><div class="figure" style="text-align: center"><br><img src="channels.png" alt="Multiplexing EXI events into channels"><p><i><span>Figure 9-2. </span>Multiplexing EXI events into channels</i></p><br></div><div class="div3">
<h4><a name="StructureChannel" id="StructureChannel"></a>9.2.1 Structure Channel</h4><p>The structure channel of each block defines the overall order and structure of the events in that block. It contains the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and associated content for each event in the block, except for Attribute (AT) and Character (CH) 
<a href="#key-valueContentItem" class="termref"><span class="arrow"></span><em>values</em><span class="arrow"></span></a>, 
which are stored in the value channels. In addition, there are two kinds of attribute events whose <em>values</em> are stored in the structure channel instead of in value channels. The <em>value</em> of each xsi:type attribute is stored in the structure channel. 
The <em>value</em> of each xsi:nil attribute that matches a schema-informed grammar production 
that does not include the AT (*) [untyped value] terminal is also stored in the structure channel. These attribute events are intrinsic to the grammar system thus are essential in processing the structure channel because their values affect the grammar to be used for processing the rest of the elements on which they appear. All <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and content in the structure stream occur in the same order as they occur in the EXI event sequence.</p></div><div class="div3">
<h4><a name="ValueChannels" id="ValueChannels"></a>9.2.2 Value Channels</h4><p>The <em>values</em> of the Attribute (AT) and Character (CH) events in each block are organized into separate channels based on the <em>qname</em> of the associated attribute or element. Specifically, the <em>value</em> of each Attribute (AT) event is placed in the channel identified by the <em>qname</em> of the Attribute and the <em>value</em> of each Character (CH) event is placed in the channel identified by the <em>qname</em> of its parent Start Element (SE) event. Each block contains exactly one channel for each distinct element or attribute <em>qname</em> that occurs in the block. The <em>values</em> in each channel occur in the order they occur in the EXI event sequence.</p></div></div><div class="div2">
<h3><a name="CompressedStreams" id="CompressedStreams"></a>9.3 Compressed Streams</h3><p>The channels in a block are further organized into compressed streams. Smaller channels are combined into the same compressed stream, while others are each compressed separately. Below are the rules applied within the scope of a block used to determine the channels to be combined together, the order of the compressed streams and the order amongst the channels that are combined into the same compressed stream.</p><p>If the value channels of the block contain at most 100 <em>values</em>, the block will contain only 1 compressed stream containing the structure channel followed by all of the value channels. The order of the value channels within the compressed stream is defined by the order in which the first <em>value</em> in each channel occurs in the EXI event sequence.</p><p>If the value channels of the block contain more than 100 <em>values</em>, the first compressed stream contains only the structure channel. The second compressed stream contains all value channels that contain at most 100 <em>values</em>. And the remaining compressed streams each contain only one channel, each having more than 100 <em>values</em>. The order of the value channels within the second compressed stream is defined by the order in which the first <em>value</em> in each channel occurs in the EXI event sequence. Similarly, the order of the compressed streams following the second compressed stream in the block is defined by the order in which the first <em>value</em> of the channel inside each compressed stream occurs in the EXI event sequence.</p><div class="note"><p class="prefix"><b>Note:</b></p>EXI compression changes the order in which <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> and <em>value</em>s are read and written to and from an EXI stream.

<a href="#key-exiprocessor" class="termref"><span class="arrow"></span>EXI processors<span class="arrow"></span></a> must encode and decode <em>value</em>s in this revised order so order sensitive constructs like the string table (see <a href="#stringTable"><b>7.3 String Table</b></a>) work properly.</div><p>
When the value of the <a href="#key-compressionOption" class="termref"><span class="arrow"></span>compression<span class="arrow"></span></a> option is set to true, each compressed stream in a block is stored using the standard DEFLATE Compressed Data Format defined by RFC 1951 <a href="#RFC1951">[IETF RFC 1951]</a>. Otherwise, when the value of the <a href="#key-alignmentOption" class="termref"><span class="arrow"></span>alignment <span class="arrow"></span></a> option is set to <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a>, each compressed stream in a block is stored directly without the DEFLATE algorithm.</p><div class="note"><p class="prefix"><b>Note:</b></p>
Some EXI events have zero-byte representations and are not explicitly represented in the EXI stream. If all the events in a channel have zero-byte representations, the channel has a zero-byte representation and is not explicitly represented in a compressed stream. Implementations must take care to avoid creating an empty DEFLATE stream when all the channels that would have otherwise been organized into a compressed stream are implicit. E.g., this can occur if the final block contains only zero-length EE and ED events.
</div></div></div><div class="div1">
<h2><a name="conformance" id="conformance"></a>10. Conformance</h2><div class="div2">
<h3><a name="streamConformance" id="streamConformance"></a>10.1 EXI Stream Conformance</h3><p>
<span class="termdef"><a name="key-conformantExiStream" id="key-conformantExiStream">[Definition:]&nbsp;&nbsp;</a>A <b>conformant EXI stream</b> consists of a sequence of octets that follows the syntax of <a href="#key-existream" class="termdef"><span class="arrow"></span>EXI stream<span class="arrow"></span></a> that is defined in this document. </span>
<span class="termdef"><a name="key-extendedExiStream" id="key-extendedExiStream">[Definition:]&nbsp;&nbsp;</a>
EXI format provides a way to involve user-defined datatype representations in EXI streams processing, which is an extension point that, when used in conjunction with relevant datatype representations specifications external to this document, leads to the formulation of <b>Extended EXI streams</b>.
</span>
</p><p>
Conformance of extended EXI streams is relative to the syntax defined by the relevant user-defined datatype representations specifications. The definitions of user-defined datatype representations syntax are out of the scope of this document. 

<span class="termdef"><a name="key-conformantExtendedExiStream" id="key-conformantExtendedExiStream">[Definition:]&nbsp;&nbsp;</a>
An extended EXI stream is a <b>conformant extended EXI stream</b> if replacing value items represented using user-defined datatype representations with their intrinsic representations would make the stream a <a href="#key-conformantExiStream" class="termdef"><span class="arrow"></span>conformant EXI stream<span class="arrow"></span></a>. 
</span>

An extended EXI stream described as an "EXI stream with regards to datatype representations <em>S</em>&nbsp;" where <em>S</em> is the set of datatype representations can be processed by an <a href="#key-exidecoder" class="termref"><span class="arrow"></span>EXI stream decoder<span class="arrow"></span></a> only if the processor has the shared knowledge about each one of the datatype representations in the set <em>S</em>. 
</p><p>The structural syntax of <a href="#key-existream" class="termref"><span class="arrow"></span>EXI streams<span class="arrow"></span></a> and <a href="#key-extendedExiStream" class="termref"><span class="arrow"></span>extended EXI streams<span class="arrow"></span></a> is described by the abstract EXI grammar system defined in this document. Although this document specifies the normative way in which XML Schema schemas are mapped into the EXI grammar system to make schema-informed grammars, EXI allows the use of other schema languages to process EXI streams or extended EXI streams so far as there is a well known EXI grammar binding of the schema language and the binding preserves the semantics of the EXI grammar system. EXI streams or extended EXI streams generated using schemas of such schema language are still conformant. The definitions of grammar bindings for schema languages other than XML Schema are out of the scope of this document, and each schema language community is encouraged to define its own binding in order to make it possible to harness the utmost efficiency out of EXI when schemas of the language are available.
</p></div><div class="div2">
<h3><a name="processorConformance" id="processorConformance"></a>10.2 EXI Processor Conformance</h3><p>
The conformance of EXI Processors is defined separately for each of the two processor roles, <a href="#key-exiencoder" class="termref"><span class="arrow"></span>EXI stream encoders<span class="arrow"></span></a> and <a href="#key-exidecoder" class="termref"><span class="arrow"></span>EXI stream decoders<span class="arrow"></span></a>; the conformance of the former is described in terms of the conformance of the <a href="#key-existream" class="termref"><span class="arrow"></span>EXI streams<span class="arrow"></span></a> or <a href="#key-extendedExiStream" class="termref"><span class="arrow"></span>extended EXI streams<span class="arrow"></span></a> that they produce, while that of the latter is based on the set of format features that EXI stream decoders are prepared 
for in the processing of 
<a href="#key-conformantExiStream" class="termref"><span class="arrow"></span>conformant EXI streams<span class="arrow"></span></a> or <a href="#key-conformantExtendedExiStream" class="termref"><span class="arrow"></span>conformant extended EXI streams<span class="arrow"></span></a>.
</p><p>
An <a href="#key-exiencoder" class="termref"><span class="arrow"></span>EXI stream encoder<span class="arrow"></span></a> is conformant if and only if it is capable of generating <a href="#key-conformantExiStream" class="termref"><span class="arrow"></span>conformant EXI streams<span class="arrow"></span></a> or <a href="#key-conformantExtendedExiStream" class="termref"><span class="arrow"></span>conformant extended EXI streams<span class="arrow"></span></a> given any input structured data it is made to work on.
On the other hand, <a href="#key-exidecoder" class="termref"><span class="arrow"></span>EXI stream decoders<span class="arrow"></span></a> MUST support all format features described in this document as they are explained, except for the capability of handling 
<a href="#key-datatypeRepresentationMaps" class="termref"><span class="arrow"></span>Datatype Representation Map<span class="arrow"></span></a> 
which is an optional feature. 
EXI stream decoders that do not implement 
<a href="#key-datatypeRepresentationMaps" class="termref"><span class="arrow"></span>Datatype Representation Map<span class="arrow"></span></a> 
feature MUST report an error with a meaningful message upon encountering a <a href="#key-datatypeRepresentationOption" class="termref"><span class="arrow"></span>"datatypeRepresentationMap"<span class="arrow"></span></a> element while processing <a href="#key-optionsDoc" class="termref"><span class="arrow"></span>EXI options documents<span class="arrow"></span></a> in <a href="#key-exiheader" class="termref"><span class="arrow"></span>EXI headers<span class="arrow"></span></a>.
</p><p>Except where required for interoperability with limited computing platforms (e.g, mobile and  embedded devices), this specification avoids placing arbitrary limits on the magnitude of specific numeric values required for implementation. So, in theory it is possible for EXI grammars, event codes, strings, enumeration lists, etc. to be arbitrarily large. In practice, however, it is not the intent of this specification to require conforming implementations to adopt exotic or inefficient numeric representations for handling arbitrarily large EXI documents and grammars on specific platforms. 
</p></div></div></div><div class="back"><div class="div1">
<h2><a name="References" id="References"></a>A References</h2><div class="div2">
<h3><a name="Normative-References" id="Normative-References"></a>A.1 Normative References</h3><dl><dt class="label"><a name="RFC1951" id="RFC1951"></a>IETF RFC 1951</dt><dd>
	    <a href="http://www.ietf.org/rfc/rfc1951.txt"><cite>DEFLATE Compressed Data Format Specification version 1.3</cite></a>, P. Deutsch, Author. Internet
	    Engineering Task Force, May 1996. Available at
	    http://www.ietf.org/rfc/rfc1951.txt.
	  </dd><dt class="label"><a name="RFC2119" id="RFC2119"></a>IETF RFC 2119</dt><dd>
	    <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate
	    Requirement Levels</cite></a>, S. Bradner, Author. Internet
	    Engineering Task Force, June 1999. Available at
	    http://www.ietf.org/rfc/rfc2119.txt.
	  </dd><dt class="label"><a name="RFC3023" id="RFC3023"></a>IETF RFC 3023</dt><dd>
	    <a href="http://www.ietf.org/rfc/rfc3023.txt"><cite>XML Media Types</cite></a>, 
	    M. Murata, S. St.Laurent and D. Kohn, Author. Internet
	    Engineering Task Force, January 2001. Available at
	    http://www.ietf.org/rfc/rfc3023.txt.
	  </dd><dt class="label"><a name="ISO10646" id="ISO10646"></a>ISO/IEC 10646</dt><dd>
	    <cite>ISO/IEC 10646-1:2000. Information technology &mdash; Universal Multiple-Octet Coded Character Set (UCS) &mdash; Part 1: Architecture and Basic Multilingual Plane</cite> and <cite>ISO/IEC 10646-2:2001. Information technology &mdash; Universal Multiple-Octet Coded Character Set (UCS) &mdash; Part 2: Supplementary Planes</cite>, as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. [Geneva]: International Organization for Standardization. (See <a href="http://www.iso.org">http://www.iso.org</a> for the latest version.)
</dd><dt class="label"><a name="Unicode" id="Unicode"></a>UNICODE</dt><dd>
      <a href="http://www.unicode.org/"><cite>The Unicode Standard</cite></a>, The Unicode Consortium
</dd><dt class="label"><a name="XML10" id="XML10"></a>XML 1.0</dt><dd>
	    <a href="http://www.w3.org/TR/2008/REC-xml-20081126/"><cite>
Extensible Markup Language (XML) 1.0 (Fifth Edition)
</cite></a>,
	    T.  Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, Editors.
	    World Wide Web Consortium, 10 February 1998, revised 26 November 2008.
	    This version is http://www.w3.org/TR/2008/REC-xml-20081126.
	    The latest version is available at
	    <a href="http://www.w3.org/TR/REC-xml/">
	    http://www.w3.org/TR/REC-xml</a>.
	  </dd><dt class="label"><a name="XML11" id="XML11"></a>XML 1.1</dt><dd>
	    <a href="http://www.w3.org/TR/2006/REC-xml11-20060816/"><cite>
Extensible Markup Language (XML) 1.1 (Second Edition)
</cite></a>,
	    T.  Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, and J. Cowan, Editors.
	    World Wide Web Consortium, 04 February 2004, revised 16 August 2006.
	    This version is http://www.w3.org/TR/2006/REC-xml11-20060816.
	    The latest version is available at
	    <a href="http://www.w3.org/TR/xml11/">
	    http://www.w3.org/TR/xml11</a>.
	  </dd><dt class="label"><a name="XMLNS10" id="XMLNS10"></a>Namespaces in XML</dt><dd>
	    <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/"><cite>Namespaces in XML 1.0 (Third Edition)</cite></a>,
	    T. Bray, D. Hollander, A. Layman, R. Tobin, and H. Thompson, Editors.
	    World Wide Web Consortium, 14 January 1999, revised 8 December 2009.
	    This version is http://www.w3.org/TR/2009/REC-xml-names-20091208/᠎.
	    The latest version is available at
	    <a href="http://www.w3.org/TR/xml-names/">
	    http://www.w3.org/TR/xml-names/</a>.
	  </dd><dt class="label"><a name="XMLInfoset" id="XMLInfoset"></a>XML Information Set</dt><dd>
	    <a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204/"><cite>XML Information Set (Second Edition)</cite></a>,
	    J. Cowan and R. Tobin, Editors. World Wide Web Consortium,
	    24 October 2001, revised 4 February 2004.
	    This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204.
	    The latest version is available at
	    <a href="http://www.w3.org/TR/xml-infoset/">
	    http://www.w3.org/TR/xml-infoset</a>.
	  </dd><dt class="label"><a name="schema1" id="schema1"></a>XML Schema Structures</dt><dd>
	    <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>XML Schema Part 1: Structures Second
	    Edition</cite></a>, H. Thompson, D. Beech, M. Maloney, and
	    N. Mendelsohn, Editors. World Wide Web Consortium, 2 May
	    2001, revised 28 October 2004. 
	    This version is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028.
	    The latest version is available at
	    <a href="http://www.w3.org/TR/xmlschema-1/">
	    http://www.w3.org/TR/xmlschema-1</a>.
	  </dd><dt class="label"><a name="schema2" id="schema2"></a>XML Schema Datatypes</dt><dd>
	    <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes Second
	    Edition</cite></a>, P. Byron and A. Malhotra,
	    Editors. World Wide Web Consortium, 2 May 2001, revised 28
	    October 2004.
	    This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028.
	    The latest version is available at
	    <a href="http://www.w3.org/TR/xmlschema-2/">
	    http://www.w3.org/TR/xmlschema-2</a>.
	  </dd></dl></div><div class="div2">
<h3><a name="Informative-References" id="Informative-References"></a>A.2 Other References</h3><dl><dt class="label"><a name="efx" id="efx"></a>Efficient XML</dt><dd>
	  <a href="http://www.w3.org/TR/2007/WD-exi-measurements-20070725/#contributions-efx"><cite>Efficient XML</cite></a>, part of <a href="#eximeas">[EXI Measurements Note]</a> independently referenced.
	  The latest version is available at
	  <a href="http://www.w3.org/TR/exi-measurements/#contributions-efx">
	  http://www.w3.org/TR/exi-measurements/#contributions-efx</a>.
	</dd><dt class="label"><a name="exieval" id="exieval"></a>EXI Evaluation Note</dt><dd>
	  <a href="http://www.w3.org/TR/2008/WD-exi-evaluation-20080728/"><cite>Efficient XML Interchange Evaluation</cite></a>, 
	  Carine Bournez, Editor. 
	  World Wide Web Consortium. 
	  The latest version is available at 
	  <a href="http://www.w3.org/TR/exi-evaluation/">
	  http://www.w3.org/TR/exi-evaluation/</a>.
	</dd><dt class="label"><a name="exiimpacts" id="exiimpacts"></a>EXI Impacts Note</dt><dd>
	  <a href="http://www.w3.org/TR/2008/WD-exi-impacts-20080903/"><cite>Efficient XML Interchange (EXI) Impacts</cite></a>, 
	  Jaakko Kangasharju, Editor. 
	  World Wide Web Consortium. 
	  The latest version is available at 
	  <a href="http://www.w3.org/TR/exi-impacts/">
	  http://www.w3.org/TR/exi-impacts/</a>.
	</dd><dt class="label"><a name="eximeas" id="eximeas"></a>EXI Measurements Note</dt><dd>
	  <a href="http://www.w3.org/TR/2007/WD-exi-measurements-20070725/"><cite>Efficient XML Interchange Measurements Note</cite></a>,
	  Greg White, Jaakko Kangasharju, Don Brutzman and Stephen Williams, Editors.
	  World Wide Web Consortium.
	  The latest version is available at
	  <a href="http://www.w3.org/TR/exi-measurements/">
	  http://www.w3.org/TR/exi-measurements/</a>.
	</dd><dt class="label"><a name="exiprimer" id="exiprimer"></a>EXI Primer</dt><dd>
	  <a href="http://www.w3.org/TR/2009/WD-exi-primer-20091208/"><cite>
	  Efficient XML Interchange (EXI) Primer
	  </cite></a>,
	  Daniel Peintner, Santiago Pericas-Geertsen, Editors.
	  World Wide Web Consortium.
	  The latest version is available at
	  <a href="http://www.w3.org/TR/exi-primer/">
	  http://www.w3.org/TR/exi-primer/</a>.
	</dd><dt class="label"><a name="greibach" id="greibach"></a>Greibach Normal Form</dt><dd>
	  <cite>
	  A New Normal-Form Theorem for Context-Free Phrase Structure Grammars
          </cite>, 
	  Sheila A. Greibach, Author.
	  Journal of the ACM Volume 12&nbsp; Issue 1, January 1965, pp. 42&ndash;52.
	</dd><dt class="label"><a name="huffman" id="huffman"></a>Huffman Coding</dt><dd>
	  <a href="http://compression.ru/download/articles/huff/huffman_1952_minimum-redundancy-codes.pdf"><cite>A Method for the Construction of
	  Minimum-Redundancy Codes</cite></a>, D. A. Huffman,
	  Author. Proceedings of the I.R.E., September 1952, pp.
	  1098-1102.
	</dd><dt class="label"><a name="ieeefloat" id="ieeefloat"></a>IEEE 754-2008</dt><dd>
	    <a href="http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4610935"><cite>IEEE Standard for Floating-Point Arithmetic</cite></a>
	</dd><dt class="label"><a name="relaxng" id="relaxng"></a>ISO/IEC 19757-2:2008</dt><dd>
	    <a href="http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52348"><cite>Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG</cite></a>
	  </dd><dt class="label"><a name="soap12" id="soap12"></a>SOAP 1.2</dt><dd>
	  <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/"><cite>SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)</cite></a>, 
          M. Gudgin, M. Hadley, N. Mendelsohn,
	  J-J. Moreau, H. Frystyk Nielsen, A. Karmarkar, and Y. Lafon, Editors. World Wide Web
	  Consortium, 24 June 2003, revised 27 April 2007.
	  This version is http://www.w3.org/TR/2007/REC-soap12-part1-20070427/᠎.
	  The latest version is available at 
	  <a href="http://www.w3.org/TR/soap12-part1/">
	  http://www.w3.org/TR/soap12-part1/</a>.
	</dd><dt class="label"><a name="xbcmeas" id="xbcmeas"></a>XBC Measurement Methodologies</dt><dd>
	  <a href="http://www.w3.org/TR/2005/NOTE-xbc-measurement-20050331/"><cite>XML Binary Characterization Measurement
	  Methodologies</cite></a>, S. D. Williams and P. Haggar,
	  Editors. World Wide Web Consortium, 31 March 2005.
	  This version is http://www.w3.org/TR/2005/NOTE-xbc-measurement-20050331/.
	  The latest version is available at
	  <a href="http://www.w3.org/TR/xbc-measurement/">
	  http://www.w3.org/TR/xbc-measurement</a>.
	</dd><dt class="label"><a name="xbcusecases" id="xbcusecases"></a>XBC Use Cases</dt><dd>
	  <a href="http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/"><cite>XML Binary Characterization Use Cases</cite></a>,
	  Mike Cokus and Santiago Pericas-Geertsen, Editors.
	  World Wide Web Consortium, 31 March 2005.
	  This version is http://www.w3.org/TR/2005/NOTE-xbc-use-cases-20050331/.
	  The latest version is available at
	  <a href="http://www.w3.org/TR/xbc-use-cases/">
	  http://www.w3.org/TR/xbc-use-cases</a>.
	</dd><dt class="label"><a name="xbcproperties" id="xbcproperties"></a>XBC Properties</dt><dd>
	  <a href="http://www.w3.org/TR/2005/NOTE-xbc-properties-20050331/"><cite>XML Binary Characterization Properties</cite></a>,
	  Mike Cokus and Santiago Pericas-Geertsen, Editors.
	  World Wide Web Consortium, 31 March 2005.
	  This version is http://www.w3.org/TR/2005/NOTE-xbc-properties-20050331/
	  The latest version is available at
	  <a href="http://www.w3.org/TR/xbc-properties/">
	  http://www.w3.org/TR/xbc-properties/</a>.
	</dd></dl></div></div><div class="div1">
<h2><a name="InfosetMapping" id="InfosetMapping"></a>B Infoset Mapping</h2><p>
    This appendix contains the mappings between the XML Information
    Set <a href="#XMLInfoset">[XML Information Set]</a> model and the EXI format.
    Starting from the document information item,
    each <b>information item</b> definition is mapped to its respective
    unordered set of EXI event types 
(see <a href="#eventTypes">Table 4-1</a>). 
The actual order amongst information set items when it is relevant reflects the occurrence order of EXI events or their references in an EXI stream that correlate to the infoset items. As used in the XML Information
    Set specification, the Infoset property names are shown in square
    brackets, <strong>[thus]</strong>.
  </p><div class="note"><p class="prefix"><b>Note:</b></p><p>As has been prescribed in section <a href="#principles"><b>2. Design Principles</b></a>, EXI is designed to be compatible with the XML Information Set. While this approach is both legitimate and practical for designing a succinct format interoperable with XML family of specifications and technologies, it entails that some lexical constructs of XML not recognized by the XML Information Set are not represented by EXI, either. Examples of such unrepresented lexical constructs of XML include white space outside the document element, white space within tags, the kind of quotation marks (single or double) used to quote attribute values, and the boundaries of CDATA marked sections.
</p><p>
    No constructs in EXI format facilitate the representation of 
    <strong>[character encoding scheme]</strong>,
    <strong>[standalone]</strong> and <strong>[version]</strong> 
    properties which are available in the definition of Document Information Item of XML Information Set 
    (see <a href="#DocumentInformationItem"><b>B.1 Document Information Item</b></a>). EXI is made agnostic about 
    <strong>[character encoding scheme]</strong> and <strong>[version]</strong> 
    properties as they are in XML Information Set, and considers them to be the properties of 
    XML serializers in use. EXI forgoes <strong>[standalone]</strong> property 
    because simply having no references to any external markup declarations practically 
    serves the purpose with less complexity.
</p></div><div class="div2">
<h3><a name="DocumentInformationItem" id="DocumentInformationItem"></a>B.1 Document Information Item</h3><p>
	A document information item maps to a pair of 
Start Document (SD) 
and 
End Document (ED) events 
with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-1. Mapping between the document information item properties to EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[children]</strong></td><td>CM* PI* DT? [SE, EE]</td></tr><tr><td><strong>[document element]</strong></td><td>[SE, EE]</td></tr><tr><td><strong>[notations]</strong></td><td>Computed based on <em>text</em> content item of DT 
to which each notation information set item maps.</td></tr><tr><td><strong>[unparsed entities]</strong></td><td>Computed based on <em>text</em> content item of DT 
to which each unparsed entity information set item maps.</td></tr><tr><td><strong>[base URI]</strong></td><td>The base URI of the EXI stream</td></tr><tr><td><strong>[character encoding scheme]</strong></td><td>N/A</td></tr><tr><td><strong>[standalone]</strong></td><td>Not available</td></tr><tr><td><strong>[version]</strong></td><td>Not available</td></tr><tr><td><strong>[all declarations processed]</strong></td><td>True if all declarations contained directly or indirectly in DT are processed, otherwise false, which is the processor quality as opposed to the information provided by the format.</td></tr></tbody></table></div><div class="div2">
<h3><a name="ElementInformationItem" id="ElementInformationItem"></a>B.2 Element Information Items</h3><p>
	An element information item maps to a pair of a 
Start Element (SE) 
event and the corresponding 
End Element (EE) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-2. Mapping of the element information item properties to EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[namespace name]</strong></td><td>SE</td></tr><tr><td><strong>[local name]</strong></td><td>SE</td></tr><tr><td><strong>[prefix]</strong></td><td>SE</td></tr><tr><td><strong>[children]</strong></td><td>[SE, EE]* PI* CM* CH* ER*</td></tr><tr><td><strong>[attributes]</strong></td><td>AT*</td></tr><tr><td><strong>[namespace attributes]</strong></td><td>NS*</td></tr><tr><td><strong>[in-scope namespaces]</strong></td><td>
	      The namespace information items computed using the <strong>[namespace attributes]</strong>
	      properties of this information item and its ancestors
	    </td></tr><tr><td><strong>[base URI]</strong></td><td>The base URI of the element information item</td></tr><tr><td><strong>[parent]</strong></td><td>Computed based on the last SE event encountered that did
	    not get a matching EE event if any, or computed based on the SD event</td></tr></tbody></table></div><div class="div2">
<h3><a name="AttributeInformationItem" id="AttributeInformationItem"></a>B.3 Attribute Information Item</h3><p>
	An attribute information item maps to an 
Attribute (AT) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-3. Mapping of the attribute information item properties to EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[namespace name]</strong></td><td>AT</td></tr><tr><td><strong>[local name]</strong></td><td>AT</td></tr><tr><td><strong>[prefix]</strong></td><td>AT</td></tr><tr><td><strong>[normalized value]</strong></td><td>The <em>value</em> of AT</td></tr><tr><td><strong>[specified]</strong></td><td>True if the item maps to AT, otherwise false</td></tr><tr><td><strong>[attribute type]</strong></td><td>
	      Computed based on AT and DT
	    </td></tr><tr><td><strong>[references]</strong></td><td>
	      Computed based on <strong>[attribute type]</strong> and <em>value</em> of AT
	    </td></tr><tr><td><strong>[owner element]</strong></td><td>Computed based on the last SE event encountered that did
	    not get a matching EE event</td></tr></tbody></table></div><div class="div2">
<h3><a name="ProcessingInstructionInformationItem" id="ProcessingInstructionInformationItem"></a>B.4 Processing Instruction Information Item</h3><p>
	A processing instruction information maps to a 
Processing Instruction (PI) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-4. Mapping of the processing instruction information item properties to EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[target]</strong></td><td>PI</td></tr><tr><td><strong>[content]</strong></td><td>PI</td></tr><tr><td><strong>[base URI]</strong></td><td>The base URI of the processing information item</td></tr><tr><td><strong>[notation]</strong></td><td>
	      Computed based on the availability of the internal DTD subset
	    </td></tr><tr><td><strong>[parent]</strong></td><td>Computed based on the last SE event encountered that did
	    not get a matching EE event type</td></tr></tbody></table></div><div class="div2">
<h3><a name="UnexpandedEntityInformationItem" id="UnexpandedEntityInformationItem"></a>B.5 Unexpanded Entity Reference Information item</h3><p>
	An unexpanded entity reference information item maps to an 
Entity Reference (ER) event 
with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-5. Mapping of the entity reference information item properties to
	the EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[name]</strong></td><td>ER</td></tr><tr><td><strong>[system identifier]</strong></td><td>Based on the availability of the internal DTD subset</td></tr><tr><td><strong>[public identifier]</strong></td><td>Based on the availability of the internal DTD subset</td></tr><tr><td><strong>[declaration base URI]</strong></td><td>The base URI of the unexpanded entity reference information item</td></tr><tr><td><strong>[parent]</strong></td><td>Computed based on the last SE event encountered that did
	    not get a matching EE event type</td></tr></tbody></table></div><div class="div2">
<h3><a name="CharacterInformationItem" id="CharacterInformationItem"></a>B.6 Character Information item</h3><p>
	A character information item maps to the individual characters contained in a 
Characters (CH) 
event following a SE event that did not get a matching EE event.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-6. Mapping of the character information item properties and the EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[character code]</strong></td><td>Each character in CH</td></tr><tr><td><strong>[element content whitespace]</strong></td><td>Computed based on <strong>[parent]</strong> and DT</td></tr><tr><td><strong>[parent]</strong></td><td>Computed based on the last SE event encountered that did
	    not get a matching EE event</td></tr></tbody></table></div><div class="div2">
<h3><a name="CommentInformationItem" id="CommentInformationItem"></a>B.7 Comment Information item</h3><p>
	A comment information item maps to a 
Comment (CM) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-7. Mapping of the comment information item properties and the EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[content]</strong></td><td><em>text</em> content item of CM</td></tr><tr><td><strong>[parent]</strong></td><td>Computed based on the last SE event encountered that did
	    not get a matching EE event, or the SD event</td></tr></tbody></table></div><div class="div2">
<h3><a name="DocumentTypeDeclaractionInformationItem" id="DocumentTypeDeclaractionInformationItem"></a>B.8 Document Type Declaration Information item</h3><p>
	A document type declaration information item maps to a 
DOCTYPE (DT) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-8. Mapping of the document type declaration information item properties to the EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[system identifier]</strong></td><td>DT</td></tr><tr><td><strong>[public identifier]</strong></td><td>DT</td></tr><tr><td><strong>[children]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[parent]</strong></td><td>Computed based on the SD event</td></tr></tbody></table></div><div class="div2">
<h3><a name="UnparsedEntityInformationItem" id="UnparsedEntityInformationItem"></a>B.9 Unparsed Entity Information Item</h3><p>
	An unparsed entity information item maps to part of the
	<em>text</em> content item of 
DOCTYPE (DT) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-9. Mapping of the unparsed entity information item properties to EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[name]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[system identifier]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[public identifier]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[declaration base URI]</strong></td><td>The base URI of the unparsed entity information item</td></tr><tr><td><strong>[notation name]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[notation]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr></tbody></table></div><div class="div2">
<h3><a name="NotationMapping" id="NotationMapping"></a>B.10 Notation Information Item</h3><p>
	An notation information item maps to part of the
	<em>text</em> content item of 
DOCTYPE (DT) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-10. Mapping of the notation information item properties to EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[name]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[system identifier]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[public identifier]</strong></td><td>Computed based on <em>text</em> content item of DT</td></tr><tr><td><strong>[declaration base URI]</strong></td><td>The base URI of the notation information item</td></tr></tbody></table></div><div class="div2">
<h3><a name="NamespaceInformationItem" id="NamespaceInformationItem"></a>B.11 Namespace Information Item</h3><p>
	An namespace information item 
maps to a Namespace Declaration (NS) 
event with each of its properties subject to further mapping as shown in the following table.
      </p><table border="1" cellpadding="3" width="100%"><caption>Table B-11. Mapping of the namespace information item properties to EXI event types</caption><thead><tr><th width="35%">Property</th><th width="60%">EXI event types</th></tr></thead><tbody><tr><td><strong>[prefix]</strong></td><td>NS</td></tr><tr><td><strong>[namespace name]</strong></td><td>NS</td></tr></tbody></table></div></div><div class="div1">
<h2><a name="optionsSchema" id="optionsSchema"></a>C XML Schema for EXI Options Document</h2><p>The following schema describes the EXI options header. It is
designed to produce smaller headers for option combinations used when
compactness is critical.</p><div class="exampleInner"><pre>
&lt;xsd:schema targetNamespace="http://www.w3.org/2009/exi"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            elementFormDefault="qualified"&gt;

  &lt;xsd:element name="header"&gt;
    &lt;xsd:complexType&gt;
      &lt;xsd:sequence&gt;
        &lt;xsd:element name="lesscommon" minOccurs="0"&gt;
          &lt;xsd:complexType&gt;
            &lt;xsd:sequence&gt;
              &lt;xsd:element name="uncommon" minOccurs="0"&gt;
                &lt;xsd:complexType&gt;
                  &lt;xsd:sequence&gt;
                    &lt;xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded" 
                             processContents="skip" /&gt;
                    &lt;xsd:element name="alignment" minOccurs="0"&gt;
                      &lt;xsd:complexType&gt;
                        &lt;xsd:choice&gt;
                          &lt;xsd:element name="byte"&gt;
                            &lt;xsd:complexType /&gt;
                          &lt;/xsd:element&gt;
                          &lt;xsd:element name="pre-compress"&gt;
                            &lt;xsd:complexType /&gt;
                          &lt;/xsd:element&gt;
                        &lt;/xsd:choice&gt;
                      &lt;/xsd:complexType&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="selfContained" minOccurs="0"&gt;
                      &lt;xsd:complexType /&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="valueMaxLength" minOccurs="0"&gt;
                      &lt;xsd:simpleType&gt;
                        &lt;xsd:restriction base="xsd:unsignedInt" /&gt; 
                      &lt;/xsd:simpleType&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="valuePartitionCapacity" minOccurs="0"&gt;
                      &lt;xsd:simpleType&gt;
                        &lt;xsd:restriction base="xsd:unsignedInt" /&gt; 
                      &lt;/xsd:simpleType&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="datatypeRepresentationMap" 
                                 minOccurs="0" maxOccurs="unbounded"&gt;
                      &lt;xsd:complexType&gt;
                        &lt;xsd:sequence&gt;
                          &lt;!-- schema datatype --&gt;
                          &lt;xsd:any namespace="##other" processContents="skip" /&gt; 
                          &lt;!-- datatype representation --&gt;
                          &lt;xsd:any processContents="skip" /&gt; 
                        &lt;/xsd:sequence&gt;
                      &lt;/xsd:complexType&gt;
                    &lt;/xsd:element&gt;
                  &lt;/xsd:sequence&gt;
                &lt;/xsd:complexType&gt;
              &lt;/xsd:element&gt;
              &lt;xsd:element name="preserve" minOccurs="0"&gt;
                &lt;xsd:complexType&gt;
                  &lt;xsd:sequence&gt;
                    &lt;xsd:element name="dtd" minOccurs="0"&gt;
                      &lt;xsd:complexType /&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="prefixes" minOccurs="0"&gt;
                      &lt;xsd:complexType /&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="lexicalValues" minOccurs="0"&gt;
                      &lt;xsd:complexType /&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="comments" minOccurs="0"&gt;
                      &lt;xsd:complexType /&gt;
                    &lt;/xsd:element&gt;
                    &lt;xsd:element name="pis" minOccurs="0"&gt;
                      &lt;xsd:complexType /&gt;
                    &lt;/xsd:element&gt;
                  &lt;/xsd:sequence&gt;
                &lt;/xsd:complexType&gt;
              &lt;/xsd:element&gt;
              &lt;xsd:element name="blockSize" minOccurs="0"&gt;
                &lt;xsd:simpleType&gt;
                  &lt;xsd:restriction base="xsd:unsignedInt"&gt;
                    &lt;xsd:minInclusive value="1" /&gt;
                  &lt;/xsd:restriction&gt; 
                &lt;/xsd:simpleType&gt;
              &lt;/xsd:element&gt;                 
            &lt;/xsd:sequence&gt;
          &lt;/xsd:complexType&gt;
        &lt;/xsd:element&gt;
        &lt;xsd:element name="common" minOccurs="0"&gt;
          &lt;xsd:complexType&gt;
            &lt;xsd:sequence&gt;
              &lt;xsd:element name="compression" minOccurs="0"&gt;
                &lt;xsd:complexType /&gt;
              &lt;/xsd:element&gt;
              &lt;xsd:element name="fragment" minOccurs="0"&gt;
                &lt;xsd:complexType /&gt;
              &lt;/xsd:element&gt;
              &lt;xsd:element name="schemaId" minOccurs="0" nillable="true"&gt;
                &lt;xsd:simpleType&gt;
                  &lt;xsd:restriction base="xsd:string" /&gt;
                &lt;/xsd:simpleType&gt;
              &lt;/xsd:element&gt;
            &lt;/xsd:sequence&gt;
          &lt;/xsd:complexType&gt;
        &lt;/xsd:element&gt;
        &lt;xsd:element name="strict" minOccurs="0"&gt;
          &lt;xsd:complexType /&gt;
        &lt;/xsd:element&gt;
      &lt;/xsd:sequence&gt;
    &lt;/xsd:complexType&gt;
  &lt;/xsd:element&gt;

  &lt;!-- Built-in EXI Datatype IDs for use in datatype representation maps --&gt;
  &lt;xsd:simpleType name="base64Binary"&gt;
     &lt;xsd:restriction base="xsd:base64Binary"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="hexBinary" &gt;
     &lt;xsd:restriction base="xsd:hexBinary"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="boolean" &gt;
     &lt;xsd:restriction base="xsd:boolean"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="decimal" &gt;
     &lt;xsd:restriction base="xsd:decimal"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="double" &gt;
     &lt;xsd:restriction base="xsd:double"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="integer" &gt;
     &lt;xsd:restriction base="xsd:integer"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="string" &gt;
     &lt;xsd:restriction base="xsd:string"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="dateTime" &gt;
     &lt;xsd:restriction base="xsd:dateTime"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="date" &gt;
     &lt;xsd:restriction base="xsd:date"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="time" &gt;
     &lt;xsd:restriction base="xsd:time"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="gYearMonth" &gt;
     &lt;xsd:restriction base="xsd:gYearMonth"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="gMonthDay" &gt;
     &lt;xsd:restriction base="xsd:gMonthDay"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="gYear" &gt;
     &lt;xsd:restriction base="xsd:gYear"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="gMonth" &gt;
     &lt;xsd:restriction base="xsd:gMonth"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="gDay" &gt;
     &lt;xsd:restriction base="xsd:gDay"/&gt;
  &lt;/xsd:simpleType&gt;

  &lt;!-- Qnames reserved for future use in datatype representation maps --&gt;
  &lt;xsd:simpleType name="ieeeBinary32" &gt;
     &lt;xsd:restriction base="xsd:float"/&gt;
  &lt;/xsd:simpleType&gt;
  &lt;xsd:simpleType name="ieeeBinary64" &gt;
     &lt;xsd:restriction base="xsd:double"/&gt;
  &lt;/xsd:simpleType&gt;
&lt;/xsd:schema&gt;
</pre></div><div class="note"><p class="prefix"><b>Note:</b></p>
The <a href="#key-qname" class="termref"><span class="arrow"></span>qnames<span class="arrow"></span></a> exi:ieeeBinary32 and exi:ieeeBinary64 defined above are reserved for future use in Datatype Representation Maps to identify the 32-bit and 64-bit Binary Interchange Formats defined by the IEEE 754-2008 standard <a href="#ieeefloat">[IEEE 754-2008]</a>.
</div></div><div class="div1">
<h2><a name="initialStringValues" id="initialStringValues"></a>D Initial Entries in String Table Partitions</h2><div class="div2">
<h3><a name="initialUriValues" id="initialUriValues"></a>D.1 Initial Entries in Uri Partition</h3><p>The following table lists the entries that are initially populated in uri partitions, where partition name URI denotes that they are entries in the uri partition.</p><table border="1"><caption>Table D-1. Initial values in <em>uri</em> partition</caption><colgroup span="2" align="center"></colgroup><colgroup span="1"></colgroup><thead><tr><th>Partition</th><th>Compact ID</th><th>String Value</th></tr></thead><tbody><tr><td>URI</td><td>0</td><td>"" [empty string]</td></tr><tr><td>URI</td><td>1</td><td>"http://www.w3.org/XML/1998/namespace"</td></tr><tr><td>URI</td><td>2</td><td>"http://www.w3.org/2001/XMLSchema-instance"</td></tr></tbody></table><p>When XML Schemas are used to inform the grammars for processing EXI body, there is an additional entry that is appended to the uri partition, 
regardless of the XML Schema in use. 
</p><table border="1"><caption>Table D-2. Additional entry when XML Schemas are used</caption><colgroup span="2" align="center"></colgroup><colgroup span="1"></colgroup><thead><tr><th>Partition</th><th>Compact ID</th><th>String Value</th></tr></thead><tbody><tr><td>URI</td><td>3</td><td>"http://www.w3.org/2001/XMLSchema"</td></tr></tbody></table><p>
Additionally, when XML Schemas are used, the uri partition is also pre-populated with some of the namespace URIs used in the schemas. Section <a href="#stringTablePartitions"><b>7.3.1 String Table Partitions</b></a> describes the way this has to be done. All string values in uri partition are unique.
</p></div><div class="div2">
<h3><a name="initialPrefixValues" id="initialPrefixValues"></a>D.2 Initial Entries in Prefix Partitions</h3><p>The following table lists the entries that are initially populated in prefix partitions, 
where XML-PF represents the partition for <em>prefixes</em> in
the <code>"http://www.w3.org/XML/1998/namespace"</code> namespace and XSI-PF
represents the partition for <em>prefixes</em> in the
<code>"http://www.w3.org/2001/XMLSchema-instance"</code> namespace.</p><table border="1"><caption>Table D-3. Initial 
<em>prefix</em> string table entries</caption><colgroup span="2" align="center"></colgroup><colgroup span="1"></colgroup><thead><tr><th>Partition</th><th>Compact ID</th><th>String Value</th></tr></thead><tbody><tr><td>""</td><td>0</td><td>"" [empty string]</td></tr><tr><td>XML-PF</td><td>0</td><td>"xml"</td></tr><tr><td>XSI-PF</td><td>0</td><td>"xsi"</td></tr></tbody></table></div><div class="div2">
<h3><a name="initialLocalNames" id="initialLocalNames"></a>D.3 Initial Entries in Local-Name Partitions</h3><p>The following tables list the string values that are initially populated and made available 
in local-name partitions, where XML‑NS represents the partition for <em>local-names</em>
in the <code>"http://www.w3.org/XML/1998/namespace"</code> namespace, XSI‑NS
represents the partition for <em>local-names</em> in the
<code>"http://www.w3.org/2001/XMLSchema-instance"</code> namespace, and XSD‑NS
represents the partition for <em>local-names</em> in the
<code>"http://www.w3.org/2001/XMLSchema"</code> namespace. 
</p><a name="initialLocalNamesSchemaLess" id="initialLocalNamesSchemaLess"></a><table border="1" cellpadding="5"><caption>Table D-4. 
String&nbsp;values&nbsp;initially&nbsp;available&nbsp;in&nbsp;XML‑NS&nbsp;and&nbsp;XSI‑NS&nbsp;partition
</caption><colgroup span="2" align="center"></colgroup><thead><tr><th>Partition</th><th>String Values</th></tr></thead><tbody><tr><td>XML‑NS</td><td>"base", "id", "lang", "space"</td></tr><tr><td>XSI‑NS</td><td>"nil", "type"</td></tr></tbody></table><p>
When XML Schemas are used to inform the grammars for processing EXI body, those string values listed in the next table are available in XSD‑NS partition.
</p><a name="initialLocalNamesSchemaInformed" id="initialLocalNamesSchemaInformed"></a><table border="1" cellpadding="5"><caption>Table D-5. 
String values initially available in XSD‑NS partition for schema-informed EXI streams
</caption><colgroup span="2" align="center"></colgroup><thead><tr><th>Partition</th><th>String Values</th></tr></thead><tbody><tr><td>XSD‑NS</td><td style="line-height: 1.5;">"ENTITIES", "ENTITY", "ID", "IDREF", "IDREFS", "NCName", "NMTOKEN", "NMTOKENS", "NOTATION", "Name", "QName", "anySimpleType", "anyType", "anyURI", "base64Binary", "boolean", "byte", "date", "dateTime", "decimal", "double", "duration", "float", "gDay", "gMonth", "gMonthDay", "gYear", "gYearMonth", "hexBinary", "int", "integer", "language", "long", "negativeInteger", "nonNegativeInteger", "nonPositiveInteger", "normalizedString", "positiveInteger", "short", "string", "time", "token", "unsignedByte", "unsignedInt", "unsignedLong", "unsignedShort"</td></tr></tbody></table><p>Additionally, when a schema is provided, the string table is also pre-populated with the local-name of each attribute, element and type explicitly declared in the schema, partitioned by namespace URI. 
</p><p>
All string values within each partition containing local-names is then sorted lexicographically. Assign each string value a compact identifier in the sorted order, with the initial identifier number 0 assigned to the first string value, incremented by 1 before each subsequent assignment.
</p></div></div><div class="div1">
<h2><a name="regexToCharset" id="regexToCharset"></a>E Deriving 
Set of Characters 
from XML Schema Regular Expressions</h2><p>
XML Schema datatypes specification <a href="#schema2">[XML Schema Datatypes]</a> defines a <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regexs" class="">regular expression</a><sup><small>XS2</small></sup> syntax for use in pattern facets of simple type definitions. Pattern facets constrain the set of valid values to those that lexically match the specified regular expression. This section describes the rules for deriving the set of characters allowed in a string value that conforms to a given regular expression in an XML Schema. 
In the following description, the term "set-of-chars" is used as the shorthand form of "set of characters". 
</p><p>At the top level, 
the XML Schema regular expression 
syntax is summarized by the following production excerpted here from <a href="#schema2">[XML Schema Datatypes]</a>. Note the notation used for the numbers that tag the productions. "XSD:" is prefixed to the original numeric tags to make it easier to discern them as belonging to XML Schema specification.
</p><p id="regExp">&nbsp;&nbsp;<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#regex" class="">[XSD:1]</a><sup><small>XS2</small></sup>&nbsp;&nbsp;regExp&nbsp;&nbsp;::=&nbsp;&nbsp;branch&nbsp;&nbsp;(&nbsp;&nbsp;'|'&nbsp;&nbsp;branch&nbsp;&nbsp;)*  
</p><p>The set-of-chars for a regex that conforms to the syntax above is the union of the set-of-chars defined for each branch. Each branch of a regex is described by the following production:
</p><p>&nbsp;&nbsp;<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#branch" class="">[XSD:2]</a><sup><small>XS2</small></sup>&nbsp;&nbsp;branch&nbsp;&nbsp;::=&nbsp;&nbsp;piece* 
</p><p>The set-of-chars for each branch of a regex is the union of the set-of-chars for each piece of the branch. Each piece of a branch is described by the following production:
</p><p>&nbsp;&nbsp;<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#piece" class="">[XSD:3]</a><sup><small>XS2</small></sup>&nbsp;&nbsp;piece&nbsp;&nbsp;::=&nbsp;&nbsp;atom&nbsp;&nbsp;quantifier? 
</p><p>The set-of-chars for each piece of a branch is the set-of-chars for the atom portion of the piece. The atom portion of a piece is described by the following production:
</p><p>&nbsp;&nbsp;<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#atom" class="">[XSD:9]</a><sup><small>XS2</small></sup>&nbsp;&nbsp;atom&nbsp;&nbsp;::=&nbsp;&nbsp;Char&nbsp;&nbsp;|&nbsp;&nbsp;charClass&nbsp;&nbsp;|&nbsp;&nbsp;(&nbsp;&nbsp;'('&nbsp;&nbsp;regExp&nbsp;&nbsp;')'&nbsp;&nbsp;) 
</p><p>The set-of-chars for the atom is the set-of-chars for the Char, charClass or regExp that constitutes the atom. 
</p><p>
The set-of-chars for a Char that constitutes an atom contains the single character that matches the <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#char" class="">Char expression</a><sup><small>XS2</small></sup>. 

The set-of-chars for a charClass that constitutes an atom is the set of characters specified by the <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#charClass" class="">charClass expression </a><sup><small>XS2</small></sup>. 

The set-of-chars for a regExp sub-expression enclosed in parenthesis that constitutes an atom is the set-of-chars for the regExp itself derived by recursively applying the rule defined above. 
</p><p>
For stability and interoperability of restricted character sets across different versions of the Unicode standard, certain pattern facets cannot be used for deriving restricted character sets. In particular, pattern facets that contain one or more <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#nt-catEsc" class="">category escapes</a><sup><small>XS2</small></sup>, <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#nt-complEsc" class="">category complement escapes</a><sup><small>XS2</small></sup> or <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#nt-MultiCharEsc" class="">multi-character escapes</a><sup><small>XS2</small></sup> other than \s do not have restricted character sets.
</p></div><div class="div1">
<h2><a name="mediaTypeRegistration" id="mediaTypeRegistration"></a>F Content Coding and Internet Media Type</h2><p>
Two labels are defined for identifying and negotiating the use of EXI for representing XML information in higher-level protocols. They serve two distinct roles. One is for content coding and the other is for internet media type. 
</p><div class="div2">
<h3><a name="contentCoding" id="contentCoding"></a>F.1 Content Coding</h3><p>
The content-coding value "exi" is registered with the Internet Assigned Numbers Authority (IANA) for use with EXI. Protocols that can identify and negotiate the content coding of 
XML 
information independent of its media type, 

SHOULD use the content coding "exi" (case-insensitive) to convey the acceptance or actual use of EXI encoding for XML information.
</p></div><div class="div2">
<h3><a name="internetMediaType" id="internetMediaType"></a>F.2 Internet Media Type</h3><p>
A new media type registration "application/exi" described below is being proposed for community review, with the intent to eventually submit it to the IESG for review, approval, and registration with IANA.




</p><dl><dt class="label">Type name:</dt><dd><p>
application
</p></dd><dt class="label">Subtype name:</dt><dd><p>
exi
</p></dd><dt class="label">Required parameters:</dt><dd><p>
none
</p></dd><dt class="label">Optional parameters:</dt><dd><p>
none
</p></dd><dt class="label">Encoding considerations:</dt><dd><p>
binary
</p></dd><dt class="label">Security considerations:</dt><dd><p>
When used as an XML replacement in an application, EXI shares
the same security concerns as XML, described in IETF RFC 3023 <a href="#RFC3023">[IETF RFC 3023]</a>,
section 10.
</p><p>
In addition to concerns shared with XML, the schema identifier
refers to information external to the EXI document itself. If
an attacker is able to substitute another schema in place of
the intended one, the semantics of the EXI document could be
changed in some ways. As an example, EXI is sensitive to the
order of the values in an enumeration. It is not known whether
such an attack is possible on the actual structure of the
document.
</p><p>
Also, EXI supports user-defined datatype representations, and such
representations, if present in a document and purportedly understood by
a processor, can be a security weakness. Definitions of these
representations are expected to be external, often application- or
industry-specific, so any definition needs to be analyzed carefully from
the security perspective before being adopted.
</p></dd><dt class="label">Interoperability considerations:</dt><dd><p>
The datatype representation map feature of EXI requires
coordination between the producer and consumer of an EXI
document, and is not recommended except in controlled
environments or using standardized datatype representations
potentially defined in the future.
</p><p>
EXI permits information necessary to decode a document to be
omitted with the expectation that such information has been
communicated out of band. Such omissions hinder
interoperability in uncontrolled environments.
</p></dd><dt class="label">Published specification:</dt><dd><p>
Efficient XML Interchange (EXI) Format 1.0, World Wide Web
Consortium
</p></dd><dt class="label">Applications that use this media type:</dt><dd><p>
No known applications currently use this media type.
</p></dd><dt class="label">Additional information:</dt><dd><table><tbody><tr><td colspan="2">&nbsp;</td></tr><tr align="left"><th colspan="2">
Magic number(s):
</th></tr><tr><td width="5%">&nbsp;</td><td>
The first four octets may be hexadecimal 24 45 58 49 ("$EXI").
The first octet after these, or the first octet of the whole
content if they are not present, has its high two bits set to
values 1 and 0 in that order.
</td></tr></tbody></table><table width="100%"><tbody><tr align="left"><th colspan="2">
File extension(s):
</th></tr><tr><td width="5%">&nbsp;</td><td>.exi</td></tr></tbody></table><table width="100%"><tbody><tr align="left"><th colspan="2">
Macintosh file type code(s):
</th></tr><tr><td width="5%">&nbsp;</td><td>APPL</td></tr></tbody></table><table><tbody><tr align="left"><th colspan="2">
Consideration of alternatives :
</th></tr><tr><td width="5%">&nbsp;</td><td>
<p>
When transferring EXI streams over a protocol that can identify and negotiate the content coding of XML information independent of its media-type, the content-coding should be used to identify and negotiate how the XML information is encoded and the media-type should be used to negotiate and identify what type of information is transferred. 

</p>
</td></tr><tr><td colspan="2">&nbsp;</td></tr></tbody></table></dd><dt class="label">Person &amp; email address to contact for further information:</dt><dd><p>
World Wide Web Consortium &lt;web-human@w3.org&gt;
</p></dd><dt class="label">Intended usage:</dt><dd><p>
COMMON
</p></dd><dt class="label">Restrictions on usage:</dt><dd><p>
none
</p></dd><dt class="label">Author/Change controller:</dt><dd><p>
The EXI specification is the product of the World Wide Web
Consortium's Efficient XML Interchange Working Group. The W3C
has change control over this specification.
</p></dd></dl></div></div><div class="div1">
<h2><a name="example" id="example"></a>G Example Encoding (Non-Normative)</h2><p>
EXI Primer <a href="#exiprimer">[EXI Primer]</a> contains a section that explains the workings of EXI format using simple example documents. Those examples are intended to serve as a tool to confirm the understanding of the EXI format in action by going through encoding and decoding processes step by step.
</p></div><div class="div1">
<h2><a name="grammarExamples" id="grammarExamples"></a>H Schema-informed Grammar Examples (Non-Normative)</h2><p>As an example to exercise the process to produce schema-informed element grammars, consider the following XML Schema fragment declaring two complex-typed elements, &lt;product&gt; and &lt;order&gt;:</p><div class="exampleOuter">
<div class="exampleHeader"><a name="N86669" id="N86669"></a><i><span>Example H-1. </span>Example XML Schema fragment</i></div><div class="exampleInner"><pre>
&lt;xs:element name="product"&gt; 
  &lt;xs:complexType&gt; 
    &lt;xs:sequence maxOccurs="2"&gt; 
      &lt;xs:element name="description" type="xs:string" minOccurs="0"/&gt; 
      &lt;xs:element name="quantity" type="xs:integer" /&gt; 
      &lt;xs:element name="price" type="xs:float" /&gt; 
    &lt;/xs:sequence&gt; 
    &lt;xs:attribute name="sku" type="xs:string" use="required" /&gt; 
    &lt;xs:attribute name="color" type="xs:string" use="optional" /&gt; 
  &lt;/xs:complexType&gt; 
&lt;/xs:element&gt; 

&lt;xs:element name="order"&gt; 
  &lt;xs:complexType&gt; 
    &lt;xs:sequence&gt; 
      &lt;xs:element ref="product" maxOccurs="unbounded" /&gt; 
    &lt;/xs:sequence&gt; 
  &lt;/xs:complexType&gt; 
&lt;/xs:element&gt; 
</pre></div></div><p>Section <a href="#exampleProtoGrammars"><b>H.1 Proto-Grammar Examples</b></a> guides you through the process of 
generating 
EXI proto-grammars from the schema components available in the example schema above. EXI grammars in the normalized form that correspond to the proto-grammars are shown in section <a href="#exampleNormGrammars"><b>H.2 Normalized Grammar Examples</b></a>. Section <a href="#exampleCompleteGrammars"><b>H.3 Complete Grammar Examples</b></a> shows the complete EXI grammars for elements &lt;product&gt; and &lt;order&gt;.
</p><div class="div2">
<h3><a name="exampleProtoGrammars" id="exampleProtoGrammars"></a>H.1 Proto-Grammar Examples</h3><p>Grammars for element declaration terms "description", "quantity" and "price" are as follows. See section <a href="#elementTerms"><b>8.5.4.1.6 Element Terms</b></a> for the rules used to 
generate grammars for element terms.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="termDescription" id="termDescription"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Term_description</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_description</em><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>"description"</em>) <em>Term_description</em><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table><a name="termQuantity" id="termQuantity"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Term_quantity</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_quantity</em><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>"quantity"</em>) <em>Term_quantity</em><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table><a name="termPrice" id="termPrice"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Term_price</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_price</em><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>"price"</em>) <em>Term_price</em><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>The grammar for element particle "description" is 

created based on 
<a href="#termDescription" class="termref"><span class="arrow"></span><em>Term_description</em><span class="arrow"></span></a> given {&nbsp;minOccurs&nbsp;} value of 0 and {&nbsp;maxOccurs&nbsp;} value of 1. See section <a href="#particles"><b>8.5.4.1.5 Particles</b></a> for the rules used to 
generate grammars for particles.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="particleDescription" id="particleDescription"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Particle_description</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_description</em><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>"description"</em>) <em>Term_description</em><sub>&nbsp;1</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>Grammars for element particle "quantity" and "prices" are the same as those of their terms (<a href="#termQuantity" class="termref"><span class="arrow"></span><em>Term_quantity</em><span class="arrow"></span></a> and <a href="#termPrice" class="termref"><span class="arrow"></span><em>Term_price</em><span class="arrow"></span></a>, respectively) because {minOccurs} and {maxOccurs} are both 1.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="particleQuantity" id="particleQuantity"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Particle_quantity</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_quantity</em><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>"quantity"</em>) <em>Term_quantity</em><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table><a name="particlePrice" id="particlePrice"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Particle_price</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_price</em><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>"price"</em>) <em>Term_price</em><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>The grammar for the sequence group term in &lt;product&gt; element declaration is 
created based on 
the grammars of subordinate particles as follows. See section <a href="#sequenceGroupTerms"><b>8.5.4.1.8.1 Sequence Model Groups</b></a> for the rules used to 
generate grammars for sequence groups.

</p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>Term_sequence</em> = <a href="#particleDescription" class="termref"><span class="arrow"></span><em>Particle_description</em><span class="arrow"></span></a> &oplus; <a href="#particleQuantity" class="termref"><span class="arrow"></span><em>Particle_quantity</em><span class="arrow"></span></a> &oplus; <a href="#particlePrice" class="termref"><span class="arrow"></span><em>Particle_price</em><span class="arrow"></span></a>
</td></tr></tbody></table><p>which yields the following grammars for <em>Term_sequence</em>.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="termSequence" id="termSequence"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Term_sequence</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_description</em><sub>0</sub> : 
</td></tr><tr><td></td><td width="5%"></td><td>
SE("description") <em>Term_description</em><sub>1</sub> 
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em> <sub>0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em> <sub>1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em> <sub>0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em> <sub>0</sub> : 
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em> <sub>1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em> <sub>1</sub> : 
</td></tr><tr><td></td><td></td><td>
<em>Term_price</em> <sub>0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em> <sub>0</sub> : 
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em> <sub>1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em> <sub>1</sub> :  
</td></tr><tr><td></td><td></td><td>
EE  
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>The grammar for the particle that is the content model of element &lt;product&gt; 
is created based on 
<a href="#termSequence" class="termref"><span class="arrow"></span><em>Term_sequence</em><span class="arrow"></span></a> (shown above) given {minOccurs} value of 1 and {maxOccurs} value of 2. See section <a href="#particles"><b>8.5.4.1.5 Particles</b></a> for the rules used to 
generate grammars for particles.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="particleSequence" id="particleSequence"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Particle_sequence</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_description</em><sub>0,0</sub> :  
</td></tr><tr><td></td><td width="5%"></td><td>
SE("description") <em>Term_description</em><sub>0,1</sub> 
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>0,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>0,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>0,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>0,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_price</em><sub>0,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>0,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>0,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_description</em><sub>1,0</sub>  
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>1,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>1,1</sub> 
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>1,0</sub> 
</td></tr><tr><td></td><td></td><td>
EE  
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>1,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>1,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>1,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_price</em><sub>1,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>1,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>1,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
EE  
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>Grammars for attribute uses of attributes "sku" and "color" are as follows. See section <a href="#attributeUses"><b>8.5.4.1.4 Attribute Uses</b></a> for the rules used to 
generate grammars for attribute uses.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="useSku" id="useSku"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Use_sku</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Use_sku</em> <sub>0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
AT("sku") [schema-typed value] <em>Use_sku</em> <sub>1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Use_sku</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table><a name="useColor" id="useColor"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Use_color</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Use_color</em> <sub>0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
AT("color") [schema-typed value] <em>Use_color</em> <sub>1</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Use_color</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>
Note the subtle difference between 
the forms of the two 
grammars <a href="#useSku" class="termref"><span class="arrow"></span><em>Use_sku</em><span class="arrow"></span></a> and <a href="#useColor" class="termref"><span class="arrow"></span><em>Use_color</em><span class="arrow"></span></a>. 
At the outset of the grammars, 
only <a href="#useColor" class="termref"><span class="arrow"></span><em>Use_color</em><span class="arrow"></span></a> contains a production of which the right-hand side starts with EE, which 
is the result of 
the difference in their occurrence 
requirement 
defined in the schema. 
</p><p>Finally, the grammar for the element &lt;product&gt; is 
created based on 
the grammars of its attribute uses and content model particle as follows. See section <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a> for the rules used to 
generate grammars for complex types.
</p><table width="100%"><tbody><tr><td width="5%"></td><td>
<em>ProtoG_ProductElement</em> = <a href="#useColor" class="termref"><span class="arrow"></span><em>Use_color</em><span class="arrow"></span></a> &oplus; <a href="#useSku" class="termref"><span class="arrow"></span><em>Use_sku</em><span class="arrow"></span></a> &oplus; <a href="#particleSequence" class="termref"><span class="arrow"></span><em>Particle_sequence</em><span class="arrow"></span></a>
</td></tr></tbody></table><p>which yields the following grammar for element &lt;product&gt;.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="protoProductElement" id="protoProductElement"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>ProtoG_ProductElement</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Use_color</em> <sub>0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
AT("color") [schema-typed value] <em>Use_color</em> <sub>1</sub>
</td></tr><tr><td></td><td></td><td>
<em>Use_sku</em> <sub>0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Use_color</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
<em>Use_sku</em> <sub>0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Use_sku</em> <sub>0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
AT("sku") [schema-typed value] <em>Use_sku</em> <sub>1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Use_sku</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
<em>Term_description</em><sub>0,0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>0,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>0,1</sub> 
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>0,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>0,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>0,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>0,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_price</em><sub>0,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>0,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>0,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_description</em><sub>1,0</sub>  
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>1,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>1,1</sub> 
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>1,0</sub> 
</td></tr><tr><td></td><td></td><td>
EE  
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_description</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_quantity</em><sub>1,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>1,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>1,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_quantity</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
<em>Term_price</em><sub>1,0</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>1,0</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>1,1</sub> 
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_price</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
EE  
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>The other element declaration &lt;order&gt; can be processed 
to generate its proto-grammar in a similar fashion as follows.
</p><div class="exampleOuter"><a name="termProduct" id="termProduct"></a><table width="80%"><thead><tr><th>&nbsp;</th></tr><tr><th align="left" colspan="3"><em>Term_product</em></th></tr></thead><tbody><tr><td colspan="3">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="2">
<em>Term_product</em><sub>&nbsp;0</sub> :</td></tr><tr><td></td><td width="5%"></td><td>
SE(<em>"product"</em>) <em>Term_product</em><sub>&nbsp;1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em><sub>&nbsp;1</sub> :
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>
The grammar for element particle "product" is created based on <a href="#termProduct" class="termref"><span class="arrow"></span><em>Term_product</em><span class="arrow"></span></a> given {&nbsp;minOccurs&nbsp;} value of 1 and {&nbsp;maxOccurs&nbsp;} value of <em>unbounded</em>. See section <a href="#particles"><b>8.5.4.1.5 Particles</b></a> for the rules used to generate grammars for particles.
</p><div class="exampleOuter"><table width="80%"><thead><tr><th>&nbsp;</th></tr><tr><th align="left" colspan="3"><em>Particle_product</em> &nbsp;&nbsp;(before simplification)</th></tr></thead><tbody><tr><td>&nbsp;</td></tr></tbody></table><table width="80%"><tbody><tr><td width="5%"></td><td width="5%"></td><td></td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>0,0</sub> :
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>0,1</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>0,1</sub> :
</td></tr><tr><td></td><td></td><td>
<em>Term_product</em> <sub>1,0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>1,0</sub> :
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>1,1</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>1,1</sub> :
</td></tr><tr><td></td><td></td><td>
<em>Term_product</em> <sub>1,0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>In the above grammars, two grammars <em>Term_product</em> <sub>0,1</sub> and <em>Term_product</em> <sub>1,1</sub> are redundant because they serve for no other purpose than simply relaying one non-terminal to another. Though it is not required, the uses of non-terminals <em>Term_product</em> <sub>0,1</sub> and <em>Term_product</em> <sub>1,1</sub> are each replaced by <em>Term_product</em> <sub>1,0</sub> and <em>Term_product</em> <sub>1,0</sub>, which produces the following 
simplified 
proto-grammars.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="particleProduct" id="particleProduct"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>Particle_product</em> &nbsp;&nbsp;(after simplification)</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="2">

</td></tr><tr><td></td><td width="5%"></td><td>

</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>0,0</sub> :
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>1,0</sub> :
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div><p>The proto-grammar of the element &lt;order&gt; equates to <a href="#particleProduct" class="termref"><span class="arrow"></span><em>Particle_product</em><span class="arrow"></span></a> because the type definition of element &lt;order&gt; has no attribute uses, and its content model has both {&nbsp;minOccurs&nbsp;} and {&nbsp;maxOccurs&nbsp;} property values of 1 where the element particle "product" is the sole member of the content model. 
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="protoOrderElement" id="protoOrderElement"></a><table width="80%"><thead><tr><th align="left" colspan="3"><em>ProtoG_OrderElement</em></th></tr></thead><tbody><tr><td width="5%"></td><td colspan="2">

</td></tr><tr><td></td><td width="5%"></td><td>

</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>0,0</sub> :
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td></tr><tr><td colspan="3">&nbsp;</td></tr><tr><td></td><td colspan="2">
<em>Term_product</em> <sub>1,0</sub> :
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td></tr><tr><td></td><td></td><td>
EE
</td></tr><tr><td colspan="3">&nbsp;</td></tr></tbody></table></div></div><div class="div2">
<h3><a name="exampleNormGrammars" id="exampleNormGrammars"></a>H.2 Normalized Grammar Examples</h3><p>The element proto-grammars <a href="#protoProductElement" class="termref"><span class="arrow"></span><em>ProtoG_ProductElement</em><span class="arrow"></span></a> and <a href="#protoOrderElement" class="termref"><span class="arrow"></span><em>ProtoG_OrderElement</em><span class="arrow"></span></a> produced in the previous section can be turned into their normalized forms which are shown below with an <a href="#key-eventcode" class="termref"><span class="arrow"></span>event code<span class="arrow"></span></a> assigned to each production. See section <a href="#normalizedGrammars"><b>8.5.4.2 EXI Normalized Grammars</b></a> for the process that converts proto-grammars into normalized grammars, and section <a href="#eventCodeAssignment"><b>8.5.4.3 Event Code Assignment</b></a> for the rules that determine the <a href="#key-eventcode" class="termref"><span class="arrow"></span>event codes<span class="arrow"></span></a> of productions in normalized grammars.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="normProductElement" id="normProductElement"></a><table width="80%"><thead><tr><th align="left" colspan="4"><em>NormG_ProductElement</em></th></tr><tr><th colspan="3"></th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="3">
<em>Use_color</em> <sub>0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
AT("color") [schema-typed value] <em>Use_color</em> <sub>1</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
AT("sku") [schema-typed value] <em>Use_sku</em> <sub>1</sub>
</td><td>1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Use_color</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
AT("sku") [schema-typed value] <em>Use_sku</em> <sub>1</sub>
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Use_sku</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>0,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>0,1</sub> 
</td><td>1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_description</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>0,1</sub> 
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_quantity</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>0,1</sub> 
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_price</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>1,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>1,1</sub> 
</td><td>1</td></tr><tr><td></td><td></td><td>
EE  
</td><td>2</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_description</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>1,1</sub> 
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_quantity</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>1,1</sub> 
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_price</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
EE  
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><a name="normOrderElement" id="normOrderElement"></a><table width="80%"><thead><tr><th align="left" colspan="4"><em>NormG_OrderElement</em></th></tr><tr><th colspan="3"></th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="3">
<em>Term_product</em> <sub>0,0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td><td>0</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_product</em> <sub>1,0</sub>:
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
EE
</td><td>1</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table></div><p>


Note that some 
productions 
that were present in the proto-grammars have been removed in the normalized grammars. 

Those 
productions 
were culled upon the completion of grammar normalization because their left-hand-side non-terminals are not referenced from right-hand side of any available productions, 

and yet those non-terminals are not the first non-terminals of the grammar they belong to.
.
</p></div><div class="div2">
<h3><a name="exampleCompleteGrammars" id="exampleCompleteGrammars"></a>H.3 Complete Grammar Examples</h3><p>The normalized grammars <a href="#normProductElement" class="termref"><span class="arrow"></span><em>NormG_ProductElement</em><span class="arrow"></span></a> and <a href="#normOrderElement" class="termref"><span class="arrow"></span><em>NormG_OrderElement</em><span class="arrow"></span></a> are augmented with undeclared productions to become complete grammars.
See section <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a> for the process 
to augment normalized grammars with productions for accepting terminal symbols not declared in schemas.
The complete grammars for elements &lt;product&gt; and &lt;order&gt; are shown below.
Note that the default grammar settings (i.e. the settings that can be described by an empty header options document &lt;exi:header/&gt; is used for the sake of this augmentation process, and those productions that accept ER, NS, CM and PI have been pruned according to the rules described in section <a href="#pruningProductions"><b>8.3 Pruning Unneeded Productions</b></a> since those 
terminal symbols 
are not preserved in the default grammar settings.
</p><div class="exampleOuter"><table width="80%"><tbody><tr><td>&nbsp;</td></tr></tbody></table><a name="completeProductElement" id="completeProductElement"></a><table width="80%"><thead><tr><th align="left" colspan="4">Complete grammar for element &lt;product&gt;</th></tr><tr><th colspan="3"></th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="3">
<em>Use_color</em> <sub>0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
AT("color") [schema-typed value] <em>Use_color</em> <sub>1</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
AT("sku") [schema-typed value] <em>Use_sku</em> <sub>1</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
AT(xsi:type) <em>Use_color</em> <sub>0</sub>
</td><td>2.1</td></tr><tr><td></td><td></td><td>
AT(xsi:nil) <em>Use_color</em> <sub>0</sub>
</td><td>2.2</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) <em>Use_color</em> <sub>0</sub>
</td><td>2.3</td></tr><tr><td></td><td></td><td>
AT("color") [untyped&nbsp;value] 
<em>Use_color</em><sub>1</sub> 
</td><td>2.4.0</td></tr><tr><td></td><td></td><td>
AT("sku") [untyped&nbsp;value] 
<em>Use_sku</em><sub>1</sub> 
</td><td>2.4.1</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) [untyped&nbsp;value] <em>Use_color</em> <sub>0</sub>
</td><td>2.4.2</td></tr><tr><td></td><td></td><td>
SE(*) 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>2.5</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>2.6</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Use_color</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
AT("sku") [schema-typed value] <em>Use_sku</em> <sub>1</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1.0</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) <em>Use_color</em> <sub>1</sub>
</td><td>1.1</td></tr><tr><td></td><td></td><td>
AT("sku") [untyped&nbsp;value] 
<em>Use_sku</em> <sub>1</sub> 
</td><td>1.2.0</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) [untyped&nbsp;value] <em>Use_color</em> <sub>1</sub>
</td><td>1.2.1</td></tr><tr><td></td><td></td><td>
SE(*) 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>1.3</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>1.4</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Use_sku</em> <sub>1</sub> :
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>0,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>0,1</sub> 
</td><td>1</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) <em>Use_sku</em> <sub>1</sub>
</td><td>2.1</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) [untyped&nbsp;value] <em>Use_sku</em> <sub>1</sub>
</td><td>2.2.0</td></tr><tr><td></td><td></td><td>
SE(*) 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>2.3</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>2.4</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Use_sku</em> <sub>1_copied</sub> :
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>0,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>0,1</sub> 
</td><td>1</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
SE(*) 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>
2.1 
</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] 
<em>Use_sku</em> <sub>1_copied</sub> 
</td><td>
2.2 
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_description</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>0,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
SE(*) <em>Term_description</em><sub>0,1</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Term_description</em><sub>0,1</sub>
</td><td>2.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_quantity</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>0,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
SE(*) <em>Term_quantity</em><sub>0,1</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Term_quantity</em><sub>0,1</sub>
</td><td>2.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_price</em><sub>0,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("description") <em>Term_description</em><sub>1,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>1,1</sub> 
</td><td>1</td></tr><tr><td></td><td></td><td>
EE  <sub>&nbsp;</sub>
</td><td>2</td></tr><tr><td></td><td></td><td>
SE(*) <em>Term_price</em><sub>0,1</sub>
</td><td>3.0</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Term_price</em><sub>0,1</sub>
</td><td>3.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_description</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("quantity") <em>Term_quantity</em><sub>1,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
SE(*) <em>Term_description</em><sub>1,1</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Term_description</em><sub>1,1</sub>
</td><td>2.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_quantity</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
SE("price") <em>Term_price</em><sub>1,1</sub> 
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
SE(*) <em>Term_quantity</em><sub>1,1</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Term_quantity</em><sub>1,1</sub>
</td><td>2.1</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_price</em><sub>1,1</sub> :  
</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
SE(*) <em>Term_price</em><sub>1,1</sub>
</td><td>1.0</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Term_price</em><sub>1,1</sub>
</td><td>1.1</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table><a name="completeOrderElement" id="completeOrderElement"></a><table width="80%"><thead><tr><th align="left" colspan="4">Complete grammar for element &lt;order&gt;</th></tr><tr><th colspan="3"></th><th align="left">Event Code</th></tr></thead><tbody><tr><td width="5%"></td><td colspan="3">
<em>Term_product</em> <sub>0,0</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1.0</td></tr><tr><td></td><td></td><td>
AT(xsi:type) <em>Term_product</em> <sub>0,0</sub>
</td><td>1.1</td></tr><tr><td></td><td></td><td>
AT(xsi:nil) <em>Term_product</em> <sub>0,0</sub>
</td><td>1.2</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) <em>Term_product</em> <sub>0,0</sub>
</td><td>1.3</td></tr><tr><td></td><td></td><td>
AT&nbsp;(*) [untyped&nbsp;value] <em>Term_product</em> <sub>0,0</sub>
</td><td>1.4.0</td></tr><tr><td></td><td></td><td>
SE(*) 
<em>Term_product</em> <sub>0,0_copied</sub> 
</td><td>1.5</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] 
<em>Term_product</em> <sub>0,0_copied</sub> 
</td><td>1.6</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td width="5%"></td><td colspan="3">
<em>Term_product</em> <sub>0,0_copied</sub> :
</td></tr><tr><td></td><td width="5%"></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1.0</td></tr><tr><td></td><td></td><td>
SE(*) 
<em>Term_product</em> <sub>0,0_copied</sub> 
</td><td>
1.1 
</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] 
<em>Term_product</em> <sub>0,0_copied</sub> 
</td><td>
1.2 
</td></tr><tr><td colspan="4">&nbsp;</td></tr><tr><td></td><td colspan="3">
<em>Term_product</em> <sub>1,0</sub> :
</td></tr><tr><td></td><td></td><td>
SE("product") <em>Term_product</em> <sub>1,0</sub>
</td><td>0</td></tr><tr><td></td><td></td><td>
EE <sub>&nbsp;</sub>
</td><td>1</td></tr><tr><td></td><td></td><td>
SE(*) <em>Term_product</em> <sub>1,0</sub>
</td><td>2.0</td></tr><tr><td></td><td></td><td>
CH [untyped&nbsp;value] <em>Term_product</em> <sub>1,0</sub>
</td><td>2.1</td></tr><tr><td colspan="4">&nbsp;</td></tr></tbody></table></div></div></div><div class="div1">
<h2><a name="changes" id="changes"></a>I Recent Specification Changes (Non-Normative)</h2><div class="div2">
<h3><a name="changes8" id="changes8"></a>I.1 Changes from Proposed Recommendation</h3><ul><li>
Updated bibliography entries <a href="#XMLNS10">[Namespaces in XML]</a>, <a href="#relaxng">[ISO/IEC 19757-2:2008]</a> and <a href="#soap12">[SOAP 1.2]</a> to use the up-to-date edition or version of each specification.
(see appendix <a href="#References"><b>A References</b></a>)
</li></ul></div><div class="div2">
<h3><a name="changes7" id="changes7"></a>I.2 Changes from Candidate Recommendation</h3><ul><li>Clarified that string table hits are always represented using a compact identifier.
(see <a href="#encodingOptimizedForMisses"><b>7.3.3 Partitions Optimized for Frequent use of String Literals</b></a>)
</li></ul><ul><li>
Added a note to clarify that Preserve.prefixes fidelity option SHOULD be turned on when 
xsi:type attributes are used in EXI streams that has Preserve.lexicalValues fidelity option 
value set to <em>true</em>.
(see <a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a>)
</li></ul><ul><li>
Section <a href="#encodingEnumerations"><b>7.2 Enumerations</b></a> now explicitly states that a value of an enumerated type can be represented using the ordinal position of any of the items in the enumeration that represent the value.
</li></ul><ul><li>
Corrected <a href="#encodingDateTime"><b>7.1.8 Date-Time</b></a> by making the previous change about  
Hour, Minute and Second values apply similarly to TimeZone so as to represent all datetime numbers consistenty in base 2.
</li></ul><ul><li>
Clarified how local-names in schemas are fed into the string table as part of the string table pre-population process when schemas are in use. 
(see <a href="#stringTablePartitions"><b>7.3.1 String Table Partitions</b></a>)
</li></ul><ul><li>
Clarified that mantissa or exponent values outside of the accepted range MUST NOT be used in the Float datatype representation.
(see <a href="#encodingFloat"><b>7.1.4 Float</b></a>)
</li></ul><ul><li>
Clarified that when a schema is provided which contains attribute declaration, element declaration or type declaration components with their target namespaces being one of <code>"http://www.w3.org/XML/1998/namespace"</code>, <code>"http://www.w3.org/2001/XMLSchema-instance"</code> and <code>"http://www.w3.org/2001/XMLSchema"</code>, the local-names of such schema components are also pre-populated into the string table, partitioned by their namespace URI, then sorted together with the string values listed for the respective namespace URI shown in appendix <a href="#initialLocalNames"><b>D.3 Initial Entries in Local-Name Partitions</b></a>.
</li></ul><ul><li id="changes100623">The provision that was set out to permit xsi:type and xsi:nil attributes to be represented using AT(*) terminal in schema-informed grammars was removed for improved implementation simplicity, based on observation derived from implementation experiences.
(see <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>, <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a>, <a href="#anyTypeGrammar"><b>8.5.4.1.3.3 Complex Ur-Type Grammar</b></a> and <a href="#addingProductions"><b>8.5.4.4.1 Adding Productions when Strict is False</b></a>)
</li></ul><ul><li id="changes100701a">
Clarified how a production of the form <em>LeftHandSide</em> : AT (<em>xsi:type</em>) <em>RightHandSide</em> that has already been added to the built-in grammar is evaluated.
(see <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>)
</li></ul><ul><li id="changes100707a">
Clarified that the special encoding provision described for the Integer datatype representation applies only when the associated schema datatype is derived from xsd:integer.
(see <a href="#encodingInteger"><b>7.1.5 Integer</b></a>)
</li></ul><ul><li id="changes100713a">
Clarified that only those attributes explicitly declared in schemas are considered for inclusion in the construction of schema-informed element fragment grammar.
(see <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>)
</li></ul><ul><li id="changes100721a">
Enumerated restrictions that are implicated by the use of strict option.
(see <a href="#addingProductionsStrict"><b>8.5.4.4.2 Adding Productions when Strict is True</b></a>)
</li></ul><ul><li id="changes100914a">
Clarified the criteria used to determine which values of xsi:nil attributes are included in the structure channel (as opposed to value channels) when EXI compression is used.
(see <a href="#StructureChannel"><b>9.2.1 Structure Channel</b></a>)
</li></ul><ul><li id="changes100916a">
Clarified the preamble text of <a href="#informedGrammars"><b>8.5 Schema-informed Grammars</b></a> by adding a mention that the section describes only the process for deriving schema-informed grammars from XML Schemas. 
</li></ul><ul><li id="changes100920a">
Clarified that the number of values used to dichotomize the compressed stream representation only includes values in value channels but not those occasional values of xsi:type and xsi:nil in the structure channel.
(see <a href="#CompressedStreams"><b>9.3 Compressed Streams</b></a>)
</li></ul><ul><li id="changes101105a">
Clarified that a channel of which all the events have zero-byte representations has a zero-byte representation and is not explicitly represented in a compressed stream. 
(see <a href="#CompressedStreams"><b>9.3 Compressed Streams</b></a>)
</li></ul><ul><li id="changes101105b">
The definition of blockSize element was clarified to indicate the element can have only values that are greater than or equal to 1.
(see <a href="#optionsSchema"><b>C XML Schema for EXI Options Document</b></a>)
</li></ul><ul><li>
Described the numeric ranges that must be supported by implementations.
(see <a href="#processorConformance"><b>10.2 EXI Processor Conformance</b></a>)
</li></ul><ul><li>
Clarified that regular expressions that contain category escapes, category complement escapes or multi-character escapes other than \s (whitespace) do not have corresponding restricted character sets.
(see <a href="#regexToCharset"><b>E Deriving 
Set of Characters 
from XML Schema Regular Expressions</b></a>)
</li></ul><ul><li>
Fixed an error in <em>ElementFragment</em> grammar to make sure the grammar when <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> value set to false, after undeclared productions are added, do not end up making AT terminals available following the first occurrence of SE or CH events.
(see <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>)
</li></ul><ul><li>
Fixed errors in <a href="#builtInEXITypes">Table 7-1</a> by removing unnecessary associations that were found to have been causing an interoperability problem.
</li></ul><ul><li>
Clarified appendix <a href="#initialUriValues"><b>D.1 Initial Entries in Uri Partition</b></a> by having it explicitly mentioned that some additional namespace URIs are added to the uri partition the process of which had been defined elsewhere in section <a href="#stringTablePartitions"><b>7.3.1 String Table Partitions</b></a>.
</li></ul><ul><li>
Relaxed the format constraint that had required xsi:type attribute to occur before all other attributes. It is now legitimate that other attributes occur before xsi:type so long as that xsi:type would not have caused grammar switch if it appeared as the first attribute. 
(See <a href="#encodingEvents"><b>6. Encoding EXI Streams</b></a> and <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>)
</li></ul><ul><li>
Clarified that the derivation methods "extension" or "restriction" are indicated (but not "list" or "union") when this specification mentions one type is derived from another or refers to the notion of type hierarchy. 
(See <a href="#conventions"><b>1.2 Notational Conventions and Terminology</b></a>)
</li></ul></div><div class="div2">
<h3><a name="changes6" id="changes6"></a>I.3 Changes from Last Call Working Draft</h3><ul><li>
Defined schema-order used for sorting productions in schema-informed element and type grammars.
(see <a href="#eventCodeAssignment"><b>8.5.4.3 Event Code Assignment</b></a>)
</li></ul><ul><li>
Added a caveat regarding the use of content-coding in EXI, clarifying that it is applicable only to XML documents and it is neither byte- nor character-preserving.
(see <a href="#contentCoding"><b>F.1 Content Coding</b></a>)
</li></ul><ul><li>
Hour, Minute and Second values are comparted into separate sequence of bits in order to make it easier to retrieve each values from Date-Time representation.
(see <a href="#encodingDateTime"><b>7.1.8 Date-Time</b></a>)
</li></ul><ul><li>
Made it clear that value content items of type xsd:QName and xsd:NOTATION are represented as String
with exception of xsi:type attribute whose representation uses xsd:QName.
(see <a href="#builtInEXITypes">Table 7-1</a>)
</li></ul><ul><li>
Described the behaviour expected of an EXI processor when it encountered EXI streams that have EXI versions not implemented by the processor.
(see <a href="#version"><b>5.3 EXI Format Version</b></a>)
</li></ul><ul><li>
AT&nbsp;(*) and/or SE&nbsp;(*) have been permitted on the right-hand side of Schema-informed Element Fragment Grammar.
(see <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>)
</li></ul><ul><li>
A condition was specified that makes those elements of the same name be excluded from the application of Relaxed Element Fragment grammar. Likewise, a condition that excludes attributes of the same name from the alternative application of String datatype representation.
(see <a href="#informedFragGrammars"><b>8.5.2 Schema-informed Fragment Grammar</b></a> and <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>)
</li></ul><ul><li>
Schema-informed Element Fragment Grammar is treated as though it was derived from an element declaration with a {nillable} property value of true and a type declaration that has named sub-types, when the grammar goes through the process of undeclared productions augmentation.
(see <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>)
</li></ul><ul><li>
Added missing semantics for AT&nbsp;(*) productions in Complex Type Grammars and Complex Ur-Type Grammar.
(see <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a> and <a href="#anyTypeGrammar"><b>8.5.4.1.3.3 Complex Ur-Type Grammar</b></a>)
</li></ul><ul><li>
Added a note indicating xsi:type and xsi:nil attributes cannot be used together on the same element when strict is true.(see <a href="#addingProductionsStrict"><b>8.5.4.4.2 Adding Productions when Strict is True</b></a>)
</li></ul><ul><li>
Clarified conditions under which xsi:nil values are stored in structure channel.
(see <a href="#StructureChannel"><b>9.2.1 Structure Channel</b></a>)
</li></ul><ul><li>
Added simple-type definitions for built-in EXI datatype representations to EXI options document schema.
(see <a href="#optionsSchema"><b>C XML Schema for EXI Options Document</b></a>)
</li></ul><ul><li>
Fixed issue in semantics that prohibited learning of AT(xsi:type) and AT(xsi:nil) in <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammar<span class="arrow"></span></a>.
(see <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>)
</li></ul><ul><li>In appendix section <a href="#regexToCharset"><b>E Deriving 
Set of Characters 
from XML Schema Regular Expressions</b></a>,
the terms "character set" and "charset" have been rephrased as "set of characters" and "set-of-chars", respectively. This is so as to avoid conjuring up some different connotations that these terms often bear in documents such as XML Schema specification. 
</li></ul><ul><li>It was made clear that "strict" element is not permitted to appear alongside "selfContained" element in an options document. (see the term definitions of "<a href="#key-strictOption">strict option</a>" and "<a href="#key-selfContained">selfContained option</a>")
</li></ul><ul><li>xsi:type is now allowed on all union types when <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> is true. (see <a href="#addingProductionsStrict"><b>8.5.4.4.2 Adding Productions when Strict is True</b></a>)
</li></ul><ul><li>
It has been made clearer that xsi:type and/or xsi:nil attribute events MUST occur before any other attribute events of the same element.(see <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>, <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a>, <a href="#addingProductions"><b>8.5.4.4.1 Adding Productions when Strict is False</b></a> and <a href="#addingProductionsStrict"><b>8.5.4.4.2 Adding Productions when Strict is True</b></a>)
</li></ul><ul><li>
The order of attribute occurrences when schema-informed grammar is in effect was relaxed to be in any order as long as the grammar permits it. (see <a href="#encodingEvents"><b>6. Encoding EXI Streams</b></a>)
</li></ul><ul><li>
The event after a self-contained element starts at an octet boundary. (see <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a> and see <a href="#addingProductions"><b>8.5.4.4.1 Adding Productions when Strict is False</b></a>)
</li></ul><ul><li>
The provision for selfContained option was removed from section <a href="#addingProductionsStrict"><b>8.5.4.4.2 Adding Productions when Strict is True</b></a>.
This removal does not cause any change to the format, because selfContained and strict options are mutually exclusive, therefore the provision there could never be utilized thus was simply extraneous.
</li></ul><ul><li>
SE(*) semantics has been clarified with regards to how grammars are resolved given an element <em>qname</em>.
</li></ul><ul><li>
The initial entries of local-name string table partitions has been split into two, where the second contains entries for the XSD-NS partition and gets appended to first only when XML Schemas are used. (see <a href="#initialLocalNames"><b>D.3 Initial Entries in Local-Name Partitions</b></a>)
</li></ul><ul><li>
It is now explicitly stated that Preserve.prefixes fidelity option SHOULD be turned on when qualified names are used in value content items. (see <a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a>)
</li></ul><ul><li>
Defined the term "<a href="#key-global-element-grammar" class="termref"><span class="arrow"></span>global element grammars<span class="arrow"></span></a>" for use in describing the SE&nbsp;(*) semantics.
</li></ul><ul><li>
Fixed various bugs that were present in the examples described in <a href="#grammarExamples"><b>H Schema-informed Grammar Examples</b></a>.
</li></ul><ul><li>
Sorted the initial entries in local-name partition of string tables were sorted in lexicographical order. 
(see <a href="#initialLocalNames"><b>D.3 Initial Entries in Local-Name Partitions</b></a>)
</li></ul><ul><li>
Simplified the way in which restricted character sets are derived from datatypes with pattern facets.
(see <a href="#restrictedCharSet"><b>7.1.10.1 Restricted Character Sets</b></a> and <a href="#regexToCharset"><b>E Deriving 
Set of Characters 
from XML Schema Regular Expressions</b></a>)
</li></ul><ul><li>
Added references to XML 1.1 alongside those of XML 1.0 to consistently indicate that EXI can be used with both versions of XML. 
(see <a href="#concepts"><b>3. Basic Concepts</b></a> and <a href="#DistinguishingBits"><b>5.2 Distinguishing Bits</b></a>)
</li></ul><ul><li>
Round-robin style mechanism of entry reuse for <em>value</em> string table partitions is described.
(see <a href="#encodingOptimizedForMisses"><b>7.3.3 Partitions Optimized for Frequent use of String Literals</b></a>)
</li></ul><ul><li>
Added exi:time, exi:date, exi:gYearMonth, exi:gYear, exi:gMonthDay, exi:gDay and exi:gMonth to 
<a href="#builtInRestrictedStrings">Table 7-2</a>.
</li></ul><ul><li>
Appended an empty content grammar to the definition of <em>TypeEmpty</em><sub>&nbsp;i</sub> in "8.5.4.1.3.2 Complex Type Grammars".
(see <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a>)
</li></ul><ul><li>
Changed the threshold number used for determining the use of restricted character sets from 255 to 256.
(see <a href="#restrictedCharSet"><b>7.1.10.1 Restricted Character Sets</b></a>)
</li></ul><ul><li>
Implementations are allowed to choose whether to use local or global table hit when both are available 
for representing string values. 
(see <a href="#encodingOptimizedForMisses"><b>7.3.3 Partitions Optimized for Frequent use of String Literals</b></a>)
</li></ul><ul><li>
Pattern facets defined for built-in schema datatypes are disregarded when computing restricted character sets. 
(see <a href="#restrictedCharSet"><b>7.1.10.1 Restricted Character Sets</b></a>)
</li></ul><ul><li>
The prefix string table partitions are made use of in the encoding of the prefix component of QName.
(see <a href="#encodingQName"><b>7.1.7 QName</b></a>)
</li></ul><ul><li>
Changed the default value of schemaId, datatypeRepresentationMap and [user defined meta-data] options to "no default value" in 
<a href="#exiOptionsInOptionsField">Table 5-1</a>.
</li></ul><ul><li>
It is made clear that [user defined meta-data] option cannot modify the EXI format. 
(see <a href="#options"><b>5.4 EXI Options</b></a>)
</li></ul><ul><li>
The predicates used for AT and CH terminal symbols (i.e. those previously denoted as [schema-valid value] and [schema-invalid value]) have been changed to [schema-typed value] and [untyped&nbsp;value] to more accurately reflect the associated semantics. 
</li></ul><ul><li>
Updated the section on content coding to reflect that the "exi" content coding is now in the IANA registry.
(see <a href="#contentCoding"><b>F.1 Content Coding</b></a>)
</li></ul><ul><li>
Added a non-terminal <em>TypeEmpty</em><sub>&nbsp;ur-type,</sub><sub>&nbsp;1&nbsp;</sub> to the complex ur-type grammar <em>TypeEmpty</em><sub>&nbsp;ur-type&nbsp;</sub>, and defined the content index of the <em>TypeEmpty</em><sub>&nbsp;ur-type&nbsp;</sub> grammar.
(see <a href="#anyTypeGrammar"><b>8.5.4.1.3.3 Complex Ur-Type Grammar</b></a>)
</li></ul><ul><li>
Removed the paragraph that described the processor conformance defining the minimal value range required of blockSize option support.
(see <a href="#processorConformance"><b>10.2 EXI Processor Conformance</b></a>)
</li></ul><ul><li>
It was made clear that the datatypeRepresentationMap option does not take effect when the value of the Preserve.lexicalValues fidelity option is true.
(See the definition of datatypeRepresentationMap in <a href="#options"><b>5.4 EXI Options</b></a>)
</li></ul><ul><li>
It was made clear that the section <a href="#restrictedCharSet"><b>7.1.10.1 Restricted Character Sets</b></a> only applies to datatypes
derived from xsd:string.
</li></ul><ul><li>
The maximum size of the range used for determining the use of <em>n</em>-bit Unsigned Integer for representing values of xsd:integer was changed from 4095 to 4096. 
(see <a href="#builtInEXITypes">Table 7-1</a> and <a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>).
</li></ul><ul><li>
Corrected the semantics associated with the production of the form <em>LeftHandSide</em> : EE in section 
<a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>.
</li></ul><ul><li>
Added <em>ElementFragmentTypeEmpty</em> grammar to the schema-informed element fragment grammar, and defined the <em>content</em> index of grammars <em>ElementFragment</em> and <em>ElementFragmentTypeEmpty</em>.
(see <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>)
</li></ul><ul><li>
The target namespace name of the XML Schema for EXI options document was changed to "http://www.w3.org/2009/exi".
(see <a href="#optionsSchema"><b>C XML Schema for EXI Options Document</b></a>)
</li></ul><ul><li>
Updated the semantics associated with xsi:type and xsi:nil attributes to ensure they are encoded property when the value of Preserve.lexicalValues option is true.
</li></ul><ul><li>
Removed the reference to Unicode 5.0.0 character database. Section <a href="#regexToCharset"><b>E Deriving 
Set of Characters 
from XML Schema Regular Expressions</b></a> no longer has dependency on Unicode 5.0.0. A normative reference to XML Schema datatypes specification <a href="#schema2">[XML Schema Datatypes]</a> in  regards to processing regular expressions effectively have <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-cces" class="">character class escapes</a><sup><small>XS2</small></sup> be each resolved into a set of characters using the exact version of XML and Unicode, namely XML 1.0 (Second Edition) and Unicode 3.1.0.
</li></ul><ul><li>
Added the "processContents" attribute with value "skip" to the wildcard terms in the XML Schema for EXI options document. 
(see <a href="#optionsSchema"><b>C XML Schema for EXI Options Document</b></a>)
</li></ul><ul><li>
Added a statement that suggests turning on Preserve.prefixes fidelity option when the Preserve.lexicalValues fidelity option is true and xsi:type attributes are used in the EXI stream. 
(see <a href="#fidelityOptions"><b>6.3 Fidelity Options</b></a>)
</li></ul><ul><li>
The EXI datatype identifier exi:integer represents the Integer datatype representation, and <a href="#builtInEXITypes">Table 7-1</a> has been updated to accurately reflect the association. The rule previously applied to xsd:Integer datatype in that table is now described in section <a href="#encodingInteger"><b>7.1.5 Integer</b></a>.
</li></ul><ul><li>
Two qname definitions "ieeeBinary32" and "ieeeBinary64" have been given in the EXI options document schema.
(see <a href="#optionsSchema"><b>C XML Schema for EXI Options Document</b></a>)
</li></ul><ul><li>
Implementations are required to support all Unsigned Integer values less than 2147483648, whereas the threshold value was previously 4294967296.
(see <a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>)
</li></ul></div><div class="div2">
<h3><a name="changes5" id="changes5"></a>I.4 Changes from Fourth Public Working Draft</h3><ul><li>
Added the section <a href="#mediaTypeRegistration"><b>F Content Coding and Internet Media Type</b></a>.
</li></ul></div><div class="div2">
<h3><a name="changes4" id="changes4"></a>I.5 
Changes from Third Public Working Draft
</h3><ul><li>
Added the section <a href="#conformance"><b>10. Conformance</b></a>.
</li></ul><ul><li><a href="#key-exiCookie" class="termref"><span class="arrow"></span>EXI Cookie<span class="arrow"></span></a> was introduced in the EXI header in order to provide a facility to distinguish EXI streams from a broader range of document types used on the Web. (see <a href="#EXICookie"><b>5.1 EXI Cookie</b></a>)
</li></ul><ul><li>
Header options fields <a href="#key-valueMaxLengthOption" class="termref"><span class="arrow"></span>valueMaxLength<span class="arrow"></span></a> and <a href="#key-valuePartitionCapacityOption" class="termref"><span class="arrow"></span>valuePartitionCapacity<span class="arrow"></span></a> have been added in EXI options to limit the length of a string and the total number of strings that are put into value partitions of a string table.
</li></ul><ul><li>
Added support for mixed and empty content model in complex type grammar generation.
(see <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a>)
</li></ul><ul><li>
Described how <a href="#key-builtin-elem-grammar" class="termref"><span class="arrow"></span>built-in element grammars<span class="arrow"></span></a> handle xsi:type and xsi:nil attribute occurrences in schema-informed EXI streams.
(see <a href="#builtinElemGrammars"><b>8.4.3 Built-in Element Grammar</b></a>)
</li></ul><ul><li>
Defined the grammar that represents xsd:anyType.
(see <a href="#anyTypeGrammar"><b>8.5.4.1.3.3 Complex Ur-Type Grammar</b></a>)
</li></ul><ul><li>
Described the restricted character sets used for certain typed values when <a href="#key-preserveLexicalValuesOption" class="termref"><span class="arrow"></span>Preserve.lexicalValues<span class="arrow"></span></a> is true.
(see <a href="#builtInRestrictedStrings">Table 7-2</a>)
</li></ul><ul><li>
Added a section <a href="#informedElementFragGrammar"><b>8.5.3 Schema-informed Element Fragment Grammar</b></a>
describing the content of elements declared with the same qname when they occur inside an EXI fragment or EXI Element Fragment.
</li></ul><ul><li>
Added <a href="#key-selfContained" class="termref"><span class="arrow"></span>selfContained<span class="arrow"></span></a> option for creating elements that can be indexed for random access.
(see <a href="#options"><b>5.4 EXI Options</b></a>)
</li></ul><ul><li>
Added mention of Unsigned Integer size that EXI processors SHOULD and MUST support.
(see <a href="#encodingUnsignedInteger"><b>7.1.6 Unsigned Integer</b></a>)
</li></ul><ul><li>
Changed the order of productions representing CH events 
during event code assignment. 
(see <a href="#eventCodeAssignment"><b>8.5.4.3 Event Code Assignment</b></a>)
</li></ul><ul><li>
Added semantics for empty "schemaId" element value.
(see <a href="#options"><b>5.4 EXI Options</b></a>)
</li></ul><ul><li>
The term "CODEC" has been replaced by a more appropriate term "datatype representation" throughout this document.
</li></ul><ul><li>
Added support for parameterized attribute wildcards in the generation of complex type grammars.
(see <a href="#complexTypeGrammars"><b>8.5.4.1.3.2 Complex Type Grammars</b></a>)
</li></ul></div><div class="div2">
<h3><a name="changes3" id="changes3"></a>I.6 
Changes from Second Public Working Draft
</h3><ul><li>
Added <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> (see <a href="#options"><b>5.4 EXI Options</b></a> and <a href="#addingProductionsStrict"><b>8.5.4.4.2 Adding Productions when Strict is True</b></a>).
</li></ul><ul><li>
The order of content items for NS event has been corrected. (see <a href="#eventTypes">Table 4-1</a>)
</li></ul><ul><li>
Improved the description of <a href="#key-options" class="termref"><span class="arrow"></span>EXI Options document<span class="arrow"></span></a> to make it clear that its representation does not start with an EXI header (see section <a href="#options"><b>5.4 EXI Options</b></a>). 
</li></ul><ul><li>
Reworked the section <a href="#undeclaredProductions"><b>8.5.4.4 Undeclared Productions</b></a> for grammar system accuracy as well as describing how grammars are augmented with undeclared productions when <a href="#key-strictOption" class="termref"><span class="arrow"></span>strict option<span class="arrow"></span></a> is true.
</li></ul><ul><li>
The indicator content item in NS event type has been renamed to "local-element-ns", and improved its description for clarity (see section <a href="#streams"><b>4. EXI Streams</b></a>).
</li></ul><ul><li>
The calculus of the MonthDay component used in Date-Time representation has been corrected (see section <a href="#encodingDateTime"><b>7.1.8 Date-Time</b></a>).
</li></ul><ul><li><em>TypeEmpty</em> is created for each type grammars to facilitate xsi:nil handling (see section <a href="#typeGrammars"><b>8.5.4.1.3 Type Grammars</b></a>).
</li></ul><ul><li>
Described how the use of substitution groups in schemas affects the grammars (see section <a href="#elementTerms"><b>8.5.4.1.6 Element Terms</b></a>).
</li></ul><ul><li>
Described how the namespace constraints of wildcard terms are factored into the grammars. (see section <a href="#wildcardTerms"><b>8.5.4.1.7 Wildcard Terms</b></a>).
</li></ul><ul><li>
Regular expressions do not apply to constrain character sets when regexps contain certain category escapes (see section <a href="#regexToCharset"><b>E Deriving 
Set of Characters 
from XML Schema Regular Expressions</b></a>).
</li></ul></div><div class="div2">
<h3><a name="changes2" id="changes2"></a>I.7 
Changes from First Public Working Draft
</h3><ul><li>

Specified how schema-informed grammars are derived from available XML Schemas (see section <a href="#informedElemGrammars"><b>8.5.4 Schema-informed Element and Type Grammars</b></a>).

</li></ul><ul><li>

Described how QNames are represented with prefixes when prefix preservation is turned on (see section <a href="#encodingQName"><b>7.1.7 QName</b></a>).

</li></ul><ul><li>

The <a href="#key-alignmentOption" class="termref"><span class="arrow"></span>alignment<span class="arrow"></span></a> option was introduced in <a href="#key-options" class="termref"><span class="arrow"></span>EXI Options<span class="arrow"></span></a> to support <a href="#key-precompression" class="termref"><span class="arrow"></span>pre-compression<span class="arrow"></span></a> stream as well as plain <a href="#key-bytealignment" class="termref"><span class="arrow"></span>byte-alignment<span class="arrow"></span></a> stream, in addition to the default <a href="#key-unaligned" class="termref"><span class="arrow"></span>bit-packed<span class="arrow"></span></a> representation.

</li></ul><ul><li>

Described how the presence of pattern facets affects the encoding of EXI Boolean (see section <a href="#encodingBoolean"><b>7.1.2 Boolean</b></a>) and EXI String (see section <a href="#encodingString"><b>7.1.10 String</b></a>) representation.

</li></ul><ul><li>

Values typed as integer with bounded range of 4095 or smaller are now represented as <em>n</em>-bit Unsigned Integers (see section <a href="#encodingBoundedUnsigned"><b>7.1.9 n-bit Unsigned Integer</b></a>).

</li></ul><ul><li>

Added a section  that lists additional items that have been advised and are currently under consideration.

</li></ul></div></div><div class="div1">
<h2><a name="acknowledgements" id="acknowledgements"></a>J Acknowledgements (Non-Normative)</h2><p>This document is the work of the <a href="http://www.w3.org/XML/EXI/">Efficient XML Interchange (EXI) WG</a>.</p><p>Members of the Working Group are (at the time of writing, sorted alphabetically by last name): </p><ul><li>Carine Bournez, W3C/ERCIM (<em>staff contact</em>)</li><li>Don Brutzman, Web3D Consortium</li><li>Michael Cokus, MITRE Corporation 
(<em>co-chair</em>)
</li><li>Youenn Fablet, Canon, Inc.</li><li>Jun Fujisawa, Canon, Inc.</li><li>Joerg Heuer, Siemens AG</li><li>Alan Hudson, Web3D Consortium</li><li>Takuki Kamiya, Fujitsu Laboratories of America, Inc. 
(<em>co-chair</em>)
</li><li>Jaakko Kangasharju, University of Helsinki</li><li>Richard Kuntschke, Siemens AG</li><li>Nan Ma, China Electronics Standardization Institute</li><li>Don McGregor, Web3D Consortium</li><li>Hideyuki Moribe, Fujitsu Laboratories of America, Inc.</li><li>Daniel Peintner, Siemens AG</li><li>Liam Quin, W3C/MIT (<em>staff contact</em>)</li><li>Rich Rollman, AgileDelta, Inc.</li><li>John Schneider, AgileDelta, Inc.</li><li>Sheldon Snyder, Web3D Consortium</li><li>Greg White, Stanford University (<em>former co-chair</em>)</li></ul><p>The EXI Working Group would like to acknowledge the following former members of the group for their leadership, guidance and expertise they provided throughout their individual tenure in the WG. (sorted in chronologically)
</p><ul><li>Oliver Goldman, Adobe Systems, Inc. (<em>former co-chair</em>) (until 08 June 2006) </li><li>Robin Berjon, Expway (<em>former co-chair</em>) (until 17 October 2006) </li><li>Peter Haggar, IBM (until 07 March 2007) </li><li>Paul Thorpe, OSS Nokalva, Inc. (until 11 Sept 2007)</li><li>Kimmo Raatikainen, Nokia (until 13 March 2008)</li><li>Daniel Vogelheim, Invited Expert (<em>former co-chair</em> then from Siemens AG) (until 15 July 2008)</li><li>Stephen Williams, High Performance Technologies, Inc. (until 8 Aug 2008)</li><li>Ed Day, Objective Systems, Inc. (until 23 Oct 2009)</li><li>Santiago Pericas-Geertsen, Sun Microsystems, Inc. (until 06 May 2010)</li><li>Paul Sandoz, Sun Microsystems, Inc. (until 06 May 2010)</li></ul><p>
The EXI working group owes so much to our distinguished colleague from Nokia, Kimmo Raatikainen (1955-2008), on the progress of our work, who succumbed to an ailment on March 13, 2008. His breadth of knowledge, depth of insight, ingenuity and courage to speak up constantly shed a light onto us whenever the group seemed to stray into a futile path of disagreements during the course. We shall never forget and will always appreciate his presence in us, and great contribution that is omnipresent in every aspect of our work throughout.
</p></div></div></body></html>