Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document defines rules and guidelines for HTML family documents that trigger specific document processing behavior in user agents. These techniques enable language designers and user agent developers to build extensions for the HTML family languages.
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 most recently formally published revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
If you wish to make comments regarding this document, please send them to public-html@w3.org (subscribe, archives)
Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.
The publication of this document by the W3C as a W3C Working Draft does not imply that all of the participants in the W3C HTML working group endorse the contents of the specification. Indeed, for any section of the specification, one can usually find many members of the working group or of the W3C as a whole who object strongly to the current text, the existence of the section at all, or the idea that the working group should even spend time discussing the concept of that section.
The latest stable version of the editor's draft of this specification is always available on the W3C CVS server. The latest editor's working copy (which may contain unfinished text in the process of being prepared) is also available.
The W3C HTML Working Group is the W3C working group responsible for this specification's progress along the W3C Recommendation track.
This specification is an extension to the HTML5 language. All normative content in the HTML5 specification, unless specifically overridden by this specification, is intended to be the basis for this specification.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Status: Working draft
The profile attribute was introduced in HTML 4 as a means
to specify the location of one or more meta data profiles. The attribute
could contain a space-separated list of URIs and was primarily designed to
extend the way User Agents processed metadata in the HTML document. User
agents could recognize the URI (without actually retrieving the profile)
and perform some activity based on known conventions for that profile or
dereference the URI and perform some activity based on the actual
definitions within the profile.
While specific profile URIs were not defined in HTML 4, the profile attribute was later used in [ERDF], [MICROFORMATS], [GRDDL], [DCHTML] and [XHTML+RDFA] in order to trigger processing instructions for extracting semantics from attribute values contained in the HTML document.
The version attribute was introduced in HTML 2.0. The
attribute could contain any type of character data and was primarily
designed to signal the version of the HTML language to the user agent. It
was later deprecated in favor of using a DOCTYPE header at the top of the
HTML document.
This entire document is an attempt at ensuring that there is an easier way to specify language features than there have traditionally been in HTML4 and XHTML1 while ensuring backward and forward compatability for processing extensions such as eRDF, Microformats, GRDDL, RDFa, and DCHTML. The base HTML5 specification removes the ability to specify metadata profiles. This document is an attempt at intelligently re-enabling the concept of metadata profiles, and accurately instructing user agent processing behavior.
The profile attribute and version attribute
attempted to express desired processing behavior to the user agent. History
has shown that neither was very effective at doing so, as most authors
never specify the profile attribute nor the
version attribute when authoring documents. However, the
number of authors specifying DOCTYPE is significant. This could demonstrate
that there is a desire for specifying the processing instructions for a
language even though usage of the feature has not been, historically
speaking, well understood. The DOCTYPE feature was subsequently obsoleted
in the base HTML5 specification because correct authoring usage was
problematic.
Given these base assumptions, it is still useful for an author to be able to express desired processing behavior to user agents, especially when using language extensions. For example, in order to ensure backwards-compatability, a page author may request that a particular document is parsed according to a specific language version. To provide an example, the designers of the RDFa 1.0 Syntax Specification [XHTML+RDFA] may desire to change the processing rules in a future version of the specification, say RDFa 2.0, that subtly changes the RDFa processor output. If an author desires that their document always be processed according to RDFa 1.0 rules, they can use techniques outlined in this document to ensure that their document is always interpreted in the same way, regardless of future changes to the extension language.
This section is normative.
The following sub-sections outline the necessary modifications to the base HTML5 specification.
profile attributeFor content conforming to this specification, profile is an
obsolete but conforming attribute name when used in the head
element. For example:
<head profile="http://www.w3.org/1999/xhtml/vocab" />
profile link typeprofile link type
replaces the profile attribute. The profile link
type should be used in the rel attribute in a
link element contained in the head element of a
conforming document. For example:
<head>
<link rel="profile" href="http://www.w3.org/1999/xhtml/vocab" />
</head>
This particular attribute and link type is used to provide a user agent processing behavior signalling mechanism.
Authors should use the profile link type instead of the
profile attribute when authoring new HTML documents.
The table entry below extends the list of link types as specified in Link types section of the HTML5 specification:
| Link type | Effect on... | Brief description | |
|---|---|---|---|
link |
a and area |
||
profile |
Hyperlink | not allowed | This may be used by language designers and user agent developers
to trigger additional or different processing behavior based on the
value of the href attribute. |
The [HTML4] recommendation is inconsistent in its description of the profile attribute:
This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.
Since the publication of HTML 4.01, a number of meta data profiles have
been defined, and many of them can be used in the same document. While the
profile attribute does not help in discovering which profile
applies to which part of the document, it does allow declaring
which profiles are in use, potentially triggering extended behavior in
recipients.
This erratum restores consistency in HTML 4.01, explicitly allowing
multiple URIs in a single profile attribute.
After
URIs are represented in the DTD by the parameter entity %URI;.
add
Sets of whitespace-separated URIs are represented by the parameter entity %URIlist;.
Replace
profile = uri [CT]
with
profile = urilist [CT]
(just replacing "uri" by "urilist", but not changing the link target)
Replace
profile %URI; #IMPLIED -- named dictionary of meta info --
with
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
Update the attribute index accordingly.
Replace
This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.
with
This attribute specifies the location of one or more meta data profiles, separated by white space. In case of ambiguities, profiles that appear earlier in the attribute value should be considered more significant. Profiles are discussed below in the section on meta data.
Replace
The profile attribute of the HEAD specifies the location of a meta data profile. The value of the profile attribute is a URI. User agents may use this URI in two ways:
with
The profile attribute of the HEAD specifies a set of locations of meta data profiles. The value of the profile attribute is a whitespace-separated list of URIs. User agents may use these URIs in two ways:
Note: the changes below apply both to the copy of the DTD in the HTML 4.01 spec, and the actual DTD files.
After the definition for URI, insert:
<!ENTITY % URIlist "CDATA"
-- whitespace-separated list of Uniform Resource Identifiers,
see [URI]
-->
Replace the following definition:
<!ATTLIST HEAD %i18n; -- lang, dir -- profile %URI; #IMPLIED -- named dictionary of meta info -- >
with
<!ATTLIST HEAD %i18n; -- lang, dir -- profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated -- >
Status: First draft
Some of the following references are normative while others are informative.
All references are non-normative.