This document has been developed for discussion by the W3C Technical Architecture Group.
This document is the work of the editors. It is a draft with no official standing. It does not necessarily represent the consensus opinion of the TAG and it may not even represent the consensus opinion of the editors.
Publication of this document by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
In human communication, mutual understanding of meaning is often achieved through an iterative process. Our common experiences provide a platform on which we can express our thoughts and opinions. On matters of fact, we can exchange evidence until we reach consensus. On matters of opinion, we can exchange views until we reach understanding.
Communication with and between machines does not generally allow the luxury of partial understanding. Machines have not yet demonstrated any ability to proceed in the face of ambiguity. On the Web, where communication is achived by the exchange of resources (most often "documents" in a broad sense, but generally any resource that is identified by a URI can be exchanged), we need a clear means by which meaning can be associated unambiguiously with a document.
A document on the Web is a stream of bits identified with a specific MIME type. The MIME type indicates to the processor how it may interpret the stream of bits to decompose it into a sequence of characters, for example, or a specific bitmap image.
One of the fundamental benefits of an open, extensible language like XML is that it makes information reuse very cheap. A number of mechanisms exist that allow me to quickly and efficiently repurpose information "on demand".
Some forms of reuse are easy to predict: publishing information for multiple platforms and multiple hardware architectures, converting between application formats. Others are harder to predict: transforming legacy information for new systems, mining existing data resources for new information, and applications net yet imagined.
It is important to preserve this cheap, flexible reuse policy as we develop the Web architecture.
On the Web, every document has a MIME type in addition to the stream of bits that comprises its content. In the absense of a MIME type, a stream of bits is essentially meaningless. It's the MIME type that tells a process how it can interpret the stream of bits. Although good engineering often encourages us to design self-describing data formats, it's quite possible for the same stream of bits to have different semantics depending on the MIME type associated with it.
Consider an XHTML document. If it is served as
text/xhtml, the receipient is obligated to process it as
XML, performing well-formedness and perhaps validity checking,
namespace processing, and a small number of other tasks. If the same
document is served as
text/html, the interpretation of those
bits is governed by the HTML Recommendation which has no provision for
XML namespace processing or well-formedness.
So, a first level approximation of a document's meaning is determined solely by its MIME type.
Some MIME types, such as
whole classes of documents that may have much more specific,
Consider, for example, an XHTML home page, a purchase order, and a remote
procedure call; all three of these documents might be transmited (for better
or worse) with the MIME type
application/xml. Few of us, however,
would assert that they have the same "meaning" except in the
most general sense.
So, how can we determine a more specific meaning in an unambiguous way? What additional information can we rely upon?
The document might have an associated document type or schema. That would provide additional information about the document, if we are capable of performing the required validity assessment, and assuming that it is in fact valid.
The document has a (possibly anonymous) fully qualified root element name. That name provides additional information about the type of document. As a general rule, XML allows an author to mix different namespaces with considerable freedome, so the fully qualified name of the root element may not tell us everything about the document.
The document has a (possibly empty) set of top-level namespace declarations. These namespaces tell us what the author declared at the top level, but there's nothing that requires the author to have used all of those namespaces nor anything that prevents the author from using more at lower levels of the tree.
The document has a (possibly empty) set of attribute name/value pairs on the root element. These may provide additional details.
The document forms a complete information set. Although expensive in the general case, it's not entirely unreasonable to imagine applications that examine an entire information set.
The document may have arrived as part of a larger context. That context may identify definitively what the document means, or is intended to mean. An RPC application might listen for a set of parameters on a particular port and it might always interpret any document so received as a set of parameters. Hopefully the application would perform enough error-checking to recognize when it had been sent something in appropropriate, but there's no reason to imagine that this application can handle anything else.
MIME provides for the transmission of messages composed of several parts. How is meaning determined if the receipient is handed such a "package".
Some documents may be transformed in ways that may (encryption) or may not (digital signatures) require the recipient to reverse the transformation before continuing. Does such a process confer any meaning? How is that meaning related to the meaning that would have been expressed if the document had not been so transformed before transmission?
Which, if any of these, is an appropriate answer in any and all circumstances is an open question.