HTML: Table Deployment Strategy
TOWARD GRACEFUL DEPLOYMENT OF TABLES IN HTML
Daniel W. Connolly[1]
$Id: table-deployment.html,v 1.2 1995/03/13 23:01:39 connolly Exp $
There is a clear market demand to represent tables in HTML[2] on the
World-Wide Web[3]. The development and vendor community is moving
rapidly to fulfill this demand, even while the specification for
HTML tables[4] is still under discussion.
But documents with table markup represent a potential interoperability
problem, and a potential support burden for information providers.
For example, there is a significant installed base of users who access
the web via the lynx browser on "shell accounts." Table markup will not
be interpreted reliably by this installed base.
Information providers might have to choose between not using tables,
compromising support for this user community, or mainaining alternate
representations of the information, and cluttering up their documents
with "if your browser supports tables..."
The web architecture is designed to gracefully incorporate new
features. This statement outlines a strategy for graceful deployment of
HTML tables on the web.
Format Negociation
The web architecture acknowledges that new data formats will be
introduced, and that data formats will evolve over time.
To account for this, the primary web information retrieval protocol,
HTTP[5], supports format negociation[6], where the client advertises
its capabilities and preferences regarding data formats, and the server
tunes its response to these preferences.
The installed base of web user agents generally advertises acceptance
of the text/html internet media type. The installed base of servers uses
text/html to label the data that they serve as well. Their shared
understanding of the meaning of this term is given in the HTML 2.0
specification[7].
While clients should be robust in the face of errors, the onus is on
the server to make sure the data agrees with the Content-Type: field of
the HTTP response.
Hence, if information providers wish to put table markup, which is not
part of the 2.0 specification, in their documents, they must not label
it as text/html, since this would result in unreliable behaviour in
deployed clients.
Impact on Information Providers
Documents with tables should be labelled as:
Content-Type: text/html; level=3
and clients that support HTML 3.0 will interpret them reliably.
Clients that do not support HTML 3.0 should act reliably as well, with
some loss of functionality. The installed base of clients will
generally offer to save the data to a file for later processing. Future
releases of browsers that do not support level 3 features may attempt to
interpret the document with respect to the HTML 2.0 specification, after
giving the user some indication that some idioms might be
misinterpreted.
If an information provider deems that having the documents saved to a
file rather than displayed is too much loss of functionality, they may
arrange for their server to detect the lack of level 3 support in
clients, and in that case translate the level 3 features into level 2
representations, and return the result with a text/html content type.
This conversion may be done in batch at the time the documents are made
available, or at the time of the request, with caching employed for
improved performance.
IMPACT ON AUTHORS AND SERVER ADMINISTRATORS
The need to detect a mismatch between the features used in a document
and the features supported by a client motivates a requirement that
authors should label documents with table markup distinctly from HTML
2.0 documents. Authors are encouraged to include an explicit prologue at
the beginning of each document which uses tables:
<!DOCTYPE HTML "-//IETF//DTD HTML 3.0//EN">
But since the installed base of server software generally determines
the content type of a document before opening the file, we suggest that
authors use a .html3 filename extension, or .ht3 on MS-DOS filesystems.
If the cost of deploying this convention at a site is too high, a
server administrator may assume that all documents with the .html
extension may have level 3 features, and label them as text/html;
level=3, or convert them as above.
IMPACT ON CLIENT DEVELOPERS
The need for servers to be able to detect lack of support for tables in
clients motivates a requirement that clients that support tables should
make this apparent in their requests, since it is impractical to change
the operation of the installed base of clients.
Client implementors are encouraged to support the full HTML 3.0
specification, and announce this in each request ala:
Accept: text/html; level=3
Open Issues
Detailed Instructions We need another document detailing how to this
soluion is implemented with the CERN and NCSA
servers, using the multi feature, and CGI
conversion scripts. Volunteers?
HTML 2.5, i.e. 2.0 + tables?
Should we suggest that browser implementors who wish
to support tables, but not the rest of the 3.0
spec should specify level=2.5 in their Accept:
headers?
x-html until 3.0 spec is published?
Since there is no published HTML 3.0 spec, should
information providers use text/x-html; level=3
rather than text/html; level=3?
We tested the case of returning the latter response header to Netscape
1.1beta, and it worked; i.e. the document was
displayed as expected. The Arena browser is being
updated to handle this case. We haven't tested
Netscape with x-html.
Suggest the use of disclaimers?
Should we allow, as a last resort, folks to put some
disclaimer (or link to a disclaimer) like "we use
level 3 features. If your browser doesn't support
tables, BEWARE!" on every page or at least on the
site home page? Folks will do this anyway. The
question is whether to explicitly acknowledge it or
not.
Conclusions
The long-term viability of the World-Wide Web as a global information
service depends on the graceful deployment of new features over time.
Support for the installed base of applications during the introduction
of new features does not come without cost, but considering the cost of
destabilizing the installed base, it is worth the extra effort.
The above strategy allows software with the capability to support table
markup in HTML to be deployed without causing the installed base of
applications to behave unreliably, and without an undue maintenance
burden on the part of information providers.
*** References from this document ***
[1] http://www.w3.org/hypertext/WWW/People/Connolly
[2] file://www18.w3.org/afs/w3.org/usr/connolly/develop/WWW/MarkUp/MarkUp.html
[3] http://www.w3.org/hypertext/WWW/
[4] http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html#development
[5] http://www.w3.org/hypertext/WWW/Protocols/Overview.html
[6] file://www18.w3.org/afs/w3.org/usr/connolly/develop/WWW/DesignIssues/Formats.html#4
[7] ftp://ds.internic.net/internet-drafts/draft-ietf-html-spec-01.txt