For the best results when printing this page, set your browser's font size to SMALLEST.
HTML, as it is currently specified, has no notion of contexts (or blocks, or scopes, or namespaces) other than the page. Specifically, HTML supports the notion of identifiers for page elements, by means of the ID attribute, but requires that ID values be unique with the page.
This presents a problem for statistical organizations. Such organizations typically produce many tables of statistical data that they publish on the Web. Except in the very simplest of cases, in order for these tables to be accessible, header cells must be assigned IDs, so that they can be associated with other cells in the table by means of the HEADERS attribute.
This might not present a problem if each table were published -- by itself, with no other information -- on its own Web page. But that is rarely true. For one thing, such tables are typically embedded in pages where other, non-table, elements may have IDs, often to identify anchors for local HREFS. Furthermore, it is often the cases that a page may contain multiple tables. This is especially true of analytic reports. An analytic report that discusses, for instance, economic trends and indicators, might includse several pages on the same Web page. This means that, in order for the page to be well-formed, the IDs used inside the tables must be unique, not only within the context of the table, but across all of the tables and indeed across all of the IDs on the page.
And if any of the tables is published on more than one Web, its IDs must be unique across all of the Web pages on which it is published. And of course, this often happens -- a table of important economic indicators might very well appear in several analytic reports from the same organization. In fact, it might appear on the Web pages of multiple organizations. Imagine a table released by the United States Bureau of Labor Statistics. This table contains information about important economic indicators for the United States. It is quite possible that analytic reports by other organizations might want to cut-and-paste the HTML table into the Web pages for their own analytic reports. Such organizations might include other state or federal agencies (e.g. the Federal Reserve Board, the Departments of Census or Commerce), statistical agencies of other nations (e.g. a French or German discussion of the effects of recent economic trends in the United States on the economies of France or Germany), and international agencies (the United Nations, the World Bank, etc.). In order for an HTML table to be cut-and-pasted this way, its IDs have to be unique across all of the pages of all of the agencies that might wish to reproduce it. The only alternative is for the organization that does the cutting-and-pasting to go into every table that it has cut-and-pasted and check or adjust the IDs used in the tables.
The situation is compounded by the fact that the IDs have to be unique not only across the Web pages of all agencies that might wish to reproduce them -- unique across space, as it were -- but also unique across time. Imagine an analytic report that compares the United States Consumer Price Index as it was publishedd in June 2002 with the same table as it was published in July 2002. This means that the IDs in the table for the CPI for June must be different from the IDs for the CPI for July.
In short, the problem is a problem of namespace (or scope, or context) clashes. We need to be able to keep the namespaces of tables separate -- so that the IDs used in the table won't clash with IDs used for other elements on the same Web page -- but we have not mechanism for doing so.
Clearly, what is needed is some notion of a context or scope for IDs at a finer level of granularity than the Web page.
There are at least two possible solutions.
One is to add to HTML something like a CONTEXT element. Probably CONTEXT is the best name for this element, since other terms for the same concept -- scope, block, namespace -- are already in general use for other concepts in HTML or XML.
With a CONTEXT tag, it would be possible to enclose a table within <CONTEXT> ... </CONTEXT> and then to assign its IDs with complete freedom within that context.
Probably it would be best to allow CONTEXT elements to be nested, but that is a question that can be postponed until such time as the W3C seriously considers the possibility of adding such an element to the HTML language.
Another solution is less general, and would solve the problem of context clashes for tables only. That is to add TID (table ID) and THEADERS (table HEADERS) elements to HTML. Such elements would be permitted only within the context of a TABLE element, and would have no effect outside of the TABLE in which they appear. In situations where content providers using the HTML 4.01 specification would use ID and HEADERS to associate table cells, in the future they could use TID and THEADERS instead.
This proposal is actually preferable to the first one. It is targeted at a specific part of the HTML language specification -- just the part having to do with TABLES. Its implications are understandable, and it is simple enough to be implementable.
In addition, because it is narrowly focussed, it is likely to have minimal side-effects. One drawback to the proposal for a CONTEXT tag, for instance, is that it has interesting side effects. Suppose there is a section of HTML that is within the scope of a CONTEXT tag, but you need to refer to an ID on the page that is outside of that CONTEXT. Suppose that ID was the same as an ID that occurred within the context. Could you refer to it? How?
Add TID (table ID) and THEADERS (table HEADERS) elements to HTML. Such elements would be permitted only within the context of a TABLE element, and would have no effect outside of the TABLE in which they appear.
It would be recommended that in situations where content providers using the HTML 4.01 specification would use ID and HEADERS to associate table cells for the purposes of accessibility, in the future they should use TID and THEADERS instead.