HTML+RDFa 1.1

Abstract

This specification defines rules and guidelines for adapting the RDFa Core 1.1 and RDFa Lite 1.1 specifications for use in HTML5 and XHTML5. The rules defined in this specification not only apply to HTML5 documents in non-XML and XML mode, but also to HTML4 and XHTML documents interpreted through the HTML5 parsing rules.

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

2.1 Document Conformance

There are two types of document conformance criteria for HTML documents containing RDFa semantics; HTML+RDFa and HTML+RDFa Lite.

The following conformance criteria apply to any HTML document including RDFa markup:

All document conformance requirements stated as mandatory in the HTML5 specification must be met.
The appropriate Extensions to the HTML5 Syntax, as described in this document, must be considered valid and conforming. Note that there are fewer supported attributes if the RDFa Lite syntax [RDFA-LITE] is desired over the more advanced set of RDFa attributes outlined in RDFa Core.
All HTML5 elements and attributes should be used in a way that is conformant with [HTML5]. All RDFa attributes should be used in a way that is conformant with [RDFA-CORE] and this document.
If HTML4 is the target language, the document should conform to the appropriate constraints expressed in the HTML + RDFa DTDs section located in Appendix A.

An example of a conforming HTML+RDFa document:

<html lang="en">
  <head>
    <title>Example Document</title>
  </head>
  <body>
    <p>This website is <a href="http://example.org/">example.org</a>.</p>
  </body>
</html>

Non-XML mode HTML+RDFa 1.1 documents should be labeled with the Internet Media Type text/html as defined in section 12.1 of the HTML5 specification [HTML5].

2.2 RDFa Processor Conformance

The RDFa Processor conformance criteria are listed below, all of which are mandatory:

An RDFa Processor must implement all of the mandatory features specified in the RDFa Core 1.1 specification [RDFA-CORE].
An RDFa Processor must support any mandatory features described in this specification.

2.3 User Agent Conformance

A User Agent is considered to be a type of RDFa Processor when the User Agent stores or processes RDFa attributes and their values. The reason there are separate RDFa Processor Conformance and a User Agent Conformance sections is because one can be a valid HTML5 RDFa Processor but not a valid HTML5 User Agent (for example, by only providing a very small subset of rendering functionality).

The User Agent conformance criteria are listed below, all of which are mandatory:

A User Agent must conform to all requirements listed in the Conformance requirements section of the HTML5 specification.
A User Agent must implement all of the features required by this specification.
A User Agent must implement all of the features required in the RDFa Core 1.1 specification, excluding those features which are specifically overridden by this specification as detailed in the Extensions to RDFa Core 1.1.

3. Extensions to RDFa Core 1.1

The RDFa Core 1.1 [RDFA-CORE] specification is the base document on which this specification builds. RDFa Core 1.1 specifies the attributes and syntax, in Section 5: Attributes and Syntax, and processing model, in Section 7: Processing Model, for extracting RDF from a Web document. This section specifies changes to the attributes and processing model defined in RDFa Core 1.1 in order to support extracting RDF from HTML documents.

The requirements and rules, as specified in RDFa Core and further extended in this document, apply to all HTML5 documents. The RDFa Processor operating on HTML and XHTML documents, specifically the resulting DOMs or Infosets, must apply the same processing rules for HTML4, HTML5 and XHTML5 serializations, DOMs and/or Infosets.

3.1 Additional RDFa Processing Rules

Documents conforming to the rules in this specification are processed according to [RDFA-CORE] with the following extensions:

The default vocabulary URI is undefined.
HTML+RDFa uses an additional initial context by default, http://www.w3.org/2011/rdfa-context/html-rdfa-1.1, which must be applied after the initial context for [RDFA-CORE] (http://www.w3.org/2011/rdfa-context/rdfa-1.1).
The base can be set using the base element.
The current language can be set using either the lang or xml:lang attributes.
In Section 7.5: Sequence, processing step 11, the HTML5 datetime attribute must be utilized when generating output, overriding any value expressed using the content attribute. If datetime is detected and the value of the attribute is a valid xsd:dateTime, xsd:date, or xsd:time, then a triple must be generated where the current property value is the respective datatype and the value is the value contained in the datetime attribute. If datatype is specified, it must override the automatic datatype. If no datatype is specified and the value does not match a xsd:dateTime, xsd:date, or xsd:time pattern, a plain literal must be generated with the associated language of the node, if available.
In Section 7.5: Sequence, processing step 11, the HTML5 value attribute must be utilized when generating output. If value is detected, it must override and be processed according to the rules for content.

The version attribute is not supported in HTML5 and is non-conforming. However, if an HTML+RDFa document contains the version attribute on the html element, a conforming RDFa Processor must examine the value of this attribute. If the value matches that of a defined version of RDFa, then the processing rules for that version must be used. If the value does not match a defined version, or there is no version attribute, then the processing rules for the most recent version of RDFa 1.1 must be used.

3.2 Modifying the Input Document

RDFa's tree-based processing rules, outlined in Section 7.5: Sequence of the RDFa Core 1.1 specification [RDFA-CORE], allow an input document to be automatically corrected, cleaned-up, re-arranged, or modified in any way that is approved by the host language prior to processing. Element nesting issues in HTML documents should be corrected before the input document is translated into the DOM, a valid tree-based model, on which the RDFa processing rules will operate.

Any mechanism that generates a data structure equivalent to the HTML5 or XHTML5 DOM, such as the html5lib library, may be used as the mechanism to construct the tree-based model provided as input to the RDFa processing rules.

3.3 Specifying the language for a literal

RDFa Core 1.1 allows for the current language to be specified by the Host Language. In order for RDFa Processors to conform to this specification, they must use the mechanism described in The lang and xml:lang attributes section of the [HTML5] specification to determine the language of a node.

If an author is editing an HTML fragment and is unsure of the final encapsulating MIME type for their markup, it is suggested that the author specify both lang and xml:lang where the value in both attributes is exactly the same.

3.4 Invalid XMLLiteral values

When generating literals of type XMLLiteral, the processor must ensure that the output XMLLiteral is a namespace well-formed XML fragment. A namespace well-formed XML fragment has the following properties:

The XML fragment, when placed inside of a single root element, must validate as well-formed XML. The normative language that describes a well-formed XML document is specified in Section 2.1 "Well-Formed XML Documents" of the XML specification.
The XML fragment, when placed inside of a single root element, must retain all active namespace information. The currently active attributes declared using xmlns and xmlns: stored in the RDFa Processor's current evaluation context in the list of URI mappings must be preserved in the generated XMLLiteral. The PREFIX value for xmlns:PREFIX must be transformed to all lower-case characters when preserving the value in the XMLLiteral. All active namespaces declared via xmlns and xmlns: must be placed in each top-level element in the generated XMLLiteral, taking care to not overwrite pre-existing namespace values.

An RDFa Processor that transforms the XML fragment must use the Coercing an HTML DOM into an Infoset algorithm, as specified in the HTML5 specification, followed by the algorithm defined in the Serializing XHTML Fragments section of the HTML5 specification. If an error or exception occurs at any point during the transformation, the triple containing the XMLLiteral must not be generated.

Transformation to a namespace well-formed XML fragment is required because an application that consumes XMLLiteral data expects that data to be a namespace well-formed XML fragment.

The transformation requirement does not apply to input data that are text-only, such as literals that contain a datatype attribute with an empty value (""), or input data that that contain only text nodes.

An example transformation demonstrating the preservation of namespace values is provided below. The → symbol is used to denote that the line is a continuation of the previous line and is included purely for the purposes of readability:

<p xmlns:ex="http://example.org/vocab#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 Two rectangles (the example markup for them are stored in a triple):
 <svg xmlns="http://www.w3.org/2000/svg" property="ex:markup" datatype="rdf:XMLLiteral">
 →<rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"></rect>
 →<rect width="50" height="50" style="fill:rgb(255,0,0);stroke-width:2;stroke:rgb(0,0,0)"></rect></svg>
</p>

The markup above should produce the following triple, which preserves the xmlns declaration in the markup by injecting the xmlns attribute in the rect elements:

<>
   <http://example.org/vocab#markup>
      "<rect xmlns=\"http://www.w3.org/2000/svg\" width=\"300\" 
→height=\"100\" style=\"fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)\"/>
→<rect xmlns=\"http://www.w3.org/2000/svg\" width=\"50\" 
→height=\"50\" style=\"fill:rgb(255,0,0);stroke-width:2; 
→stroke:rgb(0,0,0)\"/>"^^http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral .

Since the ex and rdf namespaces are not used in either rect element, they are not preserved in the XMLLiteral.

Similarly, compound document elements that reside in different namespaces must have their namespaces declarations preserved:

<p xmlns:ex="http://example.org/vocab#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:fb="http://www.facebook.com/2008/fbml">
 This is how you markup a user in FBML:
 <span property="ex:markup" datatype="rdf:XMLLiteral">
→<p><fb:user uid="12345">The User</fb:user></p>
→</span>
</p>

The markup above should produce the following triple, which preserves the fb namespace in the corresponding triple:

<>
   <http://example.org/vocab#markup>
      "<p xmlns:fb="http://www.facebook.com/2008/fbml">
→<fb:user uid="12345">
→</p>"^^http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral .

4. Extensions to the HTML5 Syntax

There are a few attributes that are added as extensions to the HTML5 syntax in order to fully support RDFa:

If HTML+RDFa Lite document conformance is desired, all RDFa attributes and valid values (including CURIEs), as listed in RDFa Lite 1.1, Section 2: The Attributes, must be allowed and validate as conforming when used in an HTML4, HTML5 or XHTML5 document. For the avoidance of doubt, the following RDFa attributes are allowed on all elements in the HTML5 content model: vocab, typeof, property, resource, and prefix. All other attributes that RDFa may process, like href and src, are only allowed on the elements defined in the HTML5 specification.
If HTML+RDFa document conformance is desired, all RDFa attributes and valid values (including CURIEs), as listed in RDFa Core 1.1, Section 2.1: The RDFa Attributes, must be allowed and validate as conforming when used in an HTML4, HTML5 or XHTML5 document. For the avoidance of doubt, the following RDFa attributes are allowed on all elements in the HTML5 content model: vocab, typeof, property, resource, prefix, content, about, rel, rev, datatype, and inlist. All other attributes that RDFa may process, like href and src, are only allowed on the elements defined in the HTML5 specification.
If any RDFa attribute is present on the link or meta elements, they must be considered flow and phrasing content if used outside of the head of the document. If the RDFa property attribute is present on the link element, the rel attribute is not required.

5. Backwards Compatibility

RDFa Core 1.1 deprecates the usage of xmlns: in RDFa 1.1 documents. Web page authors should not use xmlns: to express prefix mappings in RDFa 1.1 documents. Web page authors should use the prefix attribute to specify prefix mappings.

However, there are times when XHTML+RDFa 1.0 documents are served by web servers using the text/html MIMEType. In these instances, the HTML5 specification asserts that the document is processed according to the non-XML mode HTML5 processing rules. In these particular cases, it is important that the prefixes declared via xmlns: are preserved for the RDFa processors to ensure backwards-compatibility with RDFa 1.0 documents. The following sections detail the backwards compatibility details for RDFa processor implementations.

5.1 `xmlns:`-Prefixed Attributes

The RDFa Core 1.1 [RDFA-CORE] specification effectively deprecates the use of the xmlns: mechanism to declare CURIE prefix mappings in favor of the prefix attribute. While utilizing xmlns: is now frowned upon, there are instances where it is unavoidable - such as publishing legacy documents as HTML5 or supporting older XHTML+RDFa 1.0 documents that rely on the xmlns: attribute.

CURIE prefix mappings specified using attributes prepended with xmlns: must be processed using the algorithm defined in section 4.4.1: Extracting URI Mappings from Infosets for Infoset-based processors, or section 4.5.1: Extracting URI Mappings from DOMs for DOM Level 2-based processors. For CURIE prefix mappings using the prefix attribute, Section 7.5: Sequence, step #4 must be used to process namespace values.

Since CURIE prefix mappings have been specified using xmlns:, and since HTML attribute names are case-insensitive, CURIE prefix names declared using the xmlns:attribute-name pattern xmlns:<PREFIX>="<URI>" should be specified using only lower-case characters. For example, the text "xmlns:" and the text in "<PREFIX>" should be lower-case only. This is to ensure that prefix mappings are interpreted in the same way between HTML (case-insensitive attribute names) and XHTML (case-sensitive attribute names) document types.

5.2 Conformance Criteria for `xmlns:`-Prefixed Attributes

Since RDFa 1.0 documents may contain attributes starting with xmlns: to specify CURIE prefixes, any attribute starting with a case-insensitive match on the text string "xmlns:" must be preserved in the DOM or other tree-like model that is passed to the RDFa Processor. For documents conforming to this specification, attributes with names that have a case insensitive prefix matching "xmlns:" must be considered conforming. Conformance checkers must accept attribute names that have a case insensitive prefix matching "xmlns:" as conforming. Conformance checkers should generate warnings noting that the use of xmlns: is deprecated.

All attributes starting with a case insensitive prefix matching "xmlns:" must conform to the production rules outlined in Namespaces in XML [XML-NAMES11], Section 3: Declaring Namespaces. Documents that contain xmlns: attributes that do not conform to Namespaces in XML must not be accepted as conforming.

5.3 Preserving Namespaces via Coercion to Infoset

This section needs feedback from the user agent vendors to ensure that this feature does not conflict with user agent architecture and has no technical reason that it cannot be implemented.

RDFa 1.0 documents may contain the xmlns: pattern to declare prefix mappings, it is important that namespace information that is declared in non-XML mode HTML5 documents are mapped to an Infoset correctly. In order to ensure this mapping is performed correctly, the "Coercing an HTML DOM into an infoset" rules defined in [HTML5] must be extended to include the following rule:

If the XML API is namespace-aware, the tool must ensure that ([namespace name], [local name], [normalized value]) namespace tuples are created when converting the non-XML mode DOM into an Infoset. Given a standard xmlns: definition, xmlns:foo="http://example.org/bar#", the [namespace name] is http://www.w3.org/2000/xmlns/, the [local name] is foo, and the [normalized value] is http://example.org/bar#, thus the namespace tuple would be (http://www.w3.org/2000/xmlns/, foo, http://example.org/bar#).

For example, given the following input text:

<div xmlns:com="http://purl.org/commerce#">

The div element above, when coerced from an HTML DOM into an Infoset, should contain an attribute in the [namespace attributes] list with a [namespace name] set to "http://www.w3.org/2000/xmlns/", a [local name] set to com, and a [normalized value] of "http://purl.org/commerce#".

5.4 Infoset-based Processors

While the intent of the RDFa processing instructions are to provide a set of rules that are as language and toolchain agnostic as possible, for the sake of clarity, detailed methods of extracting RDFa content from processors operating on an XML Information Set are provided below.

5.4.1 Extracting URI Mappings from Infosets

Extracting URI Mappings declared via xmlns: while operating from within an Infoset-based RDFa processor can be achieved using the following algorithm:

While processing an element as described in [RDFA-CORE], Section 7.5: Sequence, Step #2:

For each attribute in the [namespace attributes] list that has a [prefix] value, create a [URI mapping] by storing the [prefix] as the value to be mapped, and the [normalized value] as the value to map.
For each attribute in the [attributes] list that has no value for [prefix] and a [local name] that starts with xmlns:, create a [URI mapping] by storing the [local name] part with the xmlns: characters removed as the value to be mapped, and the [normalized value] as the value to map.
This step is unnecessary if the Infoset coercion rules preserve namespaces specified in non-XML mode.

For example, assume that the following markup is processed by an Infoset-based RDFa processor:

<div xmlns:audio="http://purl.org/media/audio#" ...

After the markup is processed, there should exist a [URI mapping] in the [local list of URI mappings] that contains a mapping from audio to http://purl.org/media/audio#.

5.4.2 Processing RDFa Attributes

There are a number of non-prefixed attributes that are associated with RDFa Processing in HTML5. If an XML Information Set based RDFa processor is used to process these attributes, the following algorithm should be used to detect and extract the values of the attributes.

While processing Infoset Attribute Information Items in Element Information Items as described in [RDFA-CORE], Section 7.5: Sequence, Step #4 through Step #9:

For each Attribute Information Item specific to RDFa in the Infoset [attributes] list that has a [prefix] with no value, extract and use the [normalized value].

5.5 DOM Level 1 and Level 2-based Processors

This mechanism should be double-checked against all of the RDFa Javascript implementations to ensure correctness.

Most DOM-aware RDFa Processors are capable of accessing DOM Level 1 [DOM-LEVEL-1] methods to process attributes on elements. To discover all xmlns:-specified CURIE prefix mappings, the Node.attributes NamedNodeMap can be iterated over. Each Attr.name that starts with the text string xmlns: specifies a CURIE prefix mapping. The value to be mapped is the string after the xmlns: substring in the Attr.name variable and the value to be mapped is the value of the Attr.value variable.

The intent of the RDFa processing instructions are to provide a set of rules that are as language and toolchain agnostic as possible. If a developer chooses to not use the DOM1 environment mechanism outlined in the previous paragraph, they may use the following DOM2 [DOM-LEVEL-2-CORE] environment mechanism.

5.5.1 Extracting URI Mappings via DOM Level 2

Extracting URI Mappings declared via xmlns: while operating from within a DOM Level 2 based RDFa processor can be achieved using the following algorithm:

While processing each DOM2 [Element] as described in [RDFA-CORE], Section 7.5: Sequence, Step #2:

For each [Attr] in the [Node.attributes] list that has a [namespace prefix] value of xmlns, create a [URI mapping] by storing the [local name] as the value to be mapped, and the [Node.nodeValue] as the value to map.
For each [Attr] in the [Node.attributes] list that has a [namespace prefix] value of null and a [local name] that starts with xmlns:, create a [URI mapping] by storing the [local name] part with the xmlns: characters removed as the value to be mapped, and the [Node.nodeValue] as the value to map.
This step is unnecessary if the XML and non-XML mode DOMs are namespace consistent.

For example, assume that the following markup is processed by a DOM2-based RDFa processor:

<div xmlns:com="http://purl.org/commerce#" ...

After the markup is processed, there should exist a [URI mapping] in the [local list of URI mappings] that contains a mapping from com to http://purl.org/commerce#.

5.5.2 Processing RDFa Attributes

There are a number of non-prefixed attributes that are associated with RDFa processing in HTML5. If an DOM2-based RDFa processor is used to process these attributes, the following algorithm should be used to detect and extract the values of the attributes.

While processing an element as described in [RDFA-CORE], Section 5.5: Sequence, Step #4 through Step #9:

For each RDFa attribute in the [Node.attributes] list that has a [namespace prefix] that is null, extract and use [Node.nodeValue] as the value.

When extracting values from href, src and data, Web authors and developers should note that certain values may be transformed if accessed via the DOM versus a non-DOM processor. The rules for modification of URL values can be found in the main HTML5 specification under Section 2.6.2: Parsing URLs.

A. Validation

Note that DTD-based validation for HTML4+RDFa is currently a feature-at-risk and may be replaced with a more thorough validation mechanism before this specification reaches W3C Recommendation status. This is being tracked as HTML WG BUG-15936.

Documents written using the markup language defined in this specification may be validated using the DTDs defined in this section. If a document author wants to facilitate such validation, they may include the following declaration at the top of their document for HTML 4.01 + RDFa 1.1:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01+RDFa 1.1//EN"
   "http://www.w3.org/MarkUp/DTD/html401-rdfa11-1.dtd">

The following declaration may be included at the top of their document for HTML 4.01 + RDFa Lite 1.1:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01+RDFa Lite 1.1//EN"
   "http://www.w3.org/MarkUp/DTD/html401-rdfalite11-1.dtd">

A.1 HTML4 + RDFa DTDs

For the purposes of DTD-based validation, there are two DTDs that can be utilized to validate an HTML 4.01 document containing RDFa; HTML4+RDFa 1.1 and HTML4+RDFa Lite 1.1. The only difference between the RDFa 1.1 DTD versus the RDFa 1.1 Lite DTD is the addition of the following attributes to the metainformation attributes collection; content, rel, rev, datatype, about, and inlist.

B. About this Document

B.1 History

This section is non-normative.

In early 2004, Mark Birbeck published a document named "RDF in XHTML" via the XHTML2 Working Group wherein he laid the groundwork for what would eventually become RDFa (The Resource Description Framework in Attributes).

In 2006, the work was co-sponsored by the Semantic Web Deployment Work Group, which began to formalize a technology to express semantic data in XHTML. This technology was successfully developed and reached consensus at the W3C, later published as an official W3C Recommendation. While HTML provides a mechanism to express the structure of a document (title, paragraphs, links), RDFa provides a mechanism to express the meaning in a document (people, places, events).

The document, titled "RDF in XHTML: Syntax and Processing" [XHTML-RDFA], defined a set of attributes and rules for processing those attributes that resulted in the output of machine-readable semantic data. While the document applied to XHTML, the attributes and rules were always intended to operate across any tree-based structure containing attributes on tree nodes (such as HTML4, SVG and ODF).

While RDFa was initially specified for use in XHTML, adoption by a number of large organizations on the Web spurred RDFa's use in non-XHTML languages. Its use in HTML4, before an official specification was developed for those languages, caused concern regarding document conformance.

Over the years, the members of the RDFa Task Force had discussed the possibility of applying the same attributes and processing rules outlined in the XHTML+RDFa specification to all HTML family documents. By design, the possibility of a unified semantic data expression mechanism between all HTML and XHTML family documents was squarely in the realm of possibility.

An RDFa Working Group was created in 2010 to address the issues concerning multiple language implementations of RDFa. The XHTML+RDFa document was split into a base specification, called RDFa Core 1.1 [RDFA-CORE], and thin specifications that layer above RDFa Core 1.1. The XHTML+RDFa 1.1 specification [XHTML-RDFA] is an example of such a thin specification. This document, also a thin specification, is targeted at HTML4, HTML5 and XHTML5.

This document describes the extensions to the RDFa Core 1.1 specification that permits the use of RDFa in all HTML family documents. By using the attributes and processing rules described in the RDFa Core 1.1 specification and heeding the minor changes in this document, authors can generate markup that produces the same semantic data output in HTML4, HTML5 and XHTML5.

B.2 Change History

This section is non-normative.

2009-10-15: First version of the RDFa for HTML4, HTML5 and XHTML5.

2010-03-04: Updated HTML5 coercion to Infoset rules, preservation of namespaces in Infoset and DOM2-based processors, clarifying how to extract RDFa attributes via Infoset, how to extract RDFa attributes via DOM2.

2010-05-02: Inheritance of basic processing rules from RDFa 1.1 [RDFA-CORE], instead of XHTML+RDFa 1.0 [RDFA-SYNTAX], inclusion of the HTML Default Vocabulary Terms, inclusion of a HTML 4.01 + RDFa 1.1 DTD for validation purposes.

2010-06-24: Inheritance of basic processing rules from RDFa 1.1 [RDFA-CORE], instead of XHTML+RDFa 1.0 [RDFA-SYNTAX], inclusion of the HTML Default Vocabulary Terms, added HTML 4.01 + RDFa 1.1 DTD for validation purposes, added normative definition of @version attribute.

2010-10-19: Removal of @version attribute, migrated HTML Vocabulary Terms to RDFa Profile document, added statement to send comments to the HTML WG bug tracker.

2011-01-11: Removed decentralized extensibility issue markers, added DOM Level 1 prefix mapping extraction algorithm.

2011-04-05: Moved all xmlns: rules into a section titled Backwards Compatibility and brought spec in-line with latest RDFa Core 1.1 spec.

2011-05-12: Generated Last Call document, no substatitive changes.

2011-12-30: Addition of normative dependency for RDFa Lite 1.1. Addition of rules to allow meta and link elements in flow and phrasing content as long as they contain at least one RDFa-specific attribute. Added support for datetime and value processing.

2012-03-10: Clarification of where each RDFa attribute is allowed to be used. Feature at risk warning for HTML4+RDFa DTD-based validation.

B.3 Acknowledgments

This section is non-normative.

At the time of publication, the members of the RDF Web Applications Working Group were:

Ivan Herman (staff contact), Shane McCarron, Gregg Kellogg, Niklas Lindström, Knud Möller, Steven Pemberton, Manu Sporny (chair), Stéphane Corlosquet and Thomas Steiner.

At the time of publication, the members of the HTML Working Group were:

Colin Aarts, Miller Abel, D.R.Imanuel Abromeit, Robert Accettura, Chris Adams, Ben Adida, Arihant Agarwal, yael aharon, Jim Allan, Kazuyuki Ashimura, Tab Atkins Jr., Stephen Axthelm, Mark Baker, Christopher Bank, Bogdan Baraszkiewicz, Gary Barber, David Baron, Adam Barth, Aaron Bassett, Adrian Bateman, Matthias Bauer, Johannes Behr, John-Mark Bell, Robin Berjon, Arve Bersvendsen, Levent Besik, David Bills, Mark Birbeck, David Bolter, Anders Bondehagen, Marco Bonetti, Glenn Bookout, Sierk Bornemann, Denis Boudreau, Ben Boyle, River Brandon, Judy Brewer, Dan Brickley, Per-Erik Brodin, Thomas Broyer, Don Brutzman, Craig Buckler, Dick Bulterman, Daniel Burnett, Noel Bush, Andrew Buzzell, Craig Cadwallader, Sally Cain, Ben Caldwell, Brian Campbell, Carlos Cardona, Maurice Carey, Eric Carlson, Laura Carlson, Gavin Carothers, Wayne Carr, Tomas Caspers, James Cassell, Tantek Çelik, Namachivayam Chelladurai, David Child, Wendy Chisholm, David Choi, wu chou, Edward Cianci, Michaeljohn Clement, Richard Conyard, Michael Cooper, Paul Cotton (chair), Chris Cressman, Brendan Cullen, Joseph D'Andrea, Mohammed DADAS, Deborah Dahl, Erik Dahlström, David Dailey, Will Daniels, Ivan De Marino, Tommaso Donnarumma, Chris Double, John Drinkwater, Marc Drumm, Mark DuBois, Karl Dubost, Andrew Duck, Clair Dunn, Henrik Dvergsdal, Dean Edridge, Anand Samuel Edwin, Eric Eggert, S Emerson, Ivan Enderlin, Rob Ennals, Jean-Pierre EVAIN, Steve Faulkner, Andrew Fedoniouk, Alexey Feldgendler, Alejandro Fernandez, Ian Fette, Roy Fielding, Markus Fischer, David Fisher, Nick Fitzsimons, Mark Foladare, John Foliot, Kelly Ford, Jason Fowler, Geoff Freed, Matthew Freels, Steve Gabrio, Mike Ganner, Patrick Garies, Olivier Gendrin, Giovanni Gentili, Dragos Georgita, Dimitri Glazkov, Daniel Glazman, Eliot Graff, James Graham, Aryeh Gregor, Chris Griego, Jonathan Griffin, Guillaume Guérin, Jon Gunderson, Lars Gunther, Raghavan Gurumurthy, Markku Hakkinen, Marcin Hanclik, Matt Harris, Chris Hay, Sean Hayes, Ian Hickson, Thomas Higginbotham, Krijn Hoetmer, Laurens Holst, Mikko Honkala, Tobias Horvath, Peter Howkins, Raul Hudea, Dale Hudjik, Jon Hughes, Lachlan Hunt, David Hyatt, David Håsäther, Eihab Ibrahim, Kunter Ilalan, Toby Inkster, Patrick D F Ion, Erik Isaksen, Richard Ishida, Moto Ishizawa, Yudai Iwasaki, Dean Jackson, Justin James, Arthur Jennings, Arne Johannessen, Kenny Johar, Sam Johnston, Sam Johnston, Doug Jones, Wilhelm Joys Andersen, Philip Jägenstedt, Susanne Jäger, Yehuda Katz, Jeremy Keith, Serge K. Keller, John Kemp, Kazuhito Kidachi, Don Kiely, Dowan Kim, Sebastian Kippe, Martin Kliehm, Egor Kloos, Graham Klyne, Justin Anthony Knapp, Masatomo Kobayashi, Marcel Koeppen, Jirka Kosek, Anssi Kostiainen, Lee Kowalkowski, Michael Kozakewich, Maxim Kozhuh, Peter Krantz, Keith Krieger, Kris Krueger, Mayank Kumar, Michael Köller, Jonatan Lander, Lucas Larson, Bruce Lawson, Josh Lawton, Nicolas LE GALL, Chasen Le Hara, Philippe Le Hégaret, Jane Lee, Kangchan Lee, WonSuk Lee, Niels Leenheer, Dean Leigh, Travis Leithead, Gez Lemon, Kornel Lesinski, aurélien levy, Scott Lewis, Li Li, Danny Liang, Jake Liddell, Håkon Wium Lie, Jedi Lin, Andy Lintner, Feng Liu, Jianjun Liu, Robert Love, Guillaume Ludwig, Andrew Maben, Shefik Macauley, Matthew MacKenzie, Krzysztof Maczynski, Vilem Malek, Murray Maloney, Jatinder Mann, Gabriel Mansour, Zhihong Mao, Bilgehan Maras, Chris Marrin, Robert Marshall, Andrew Martin, Alfonso Martínez de Lizarrondo, Luca Mascaro, Larry Masinter, Bill Mason, Matthew May, Cena Mayo, Charles McCathieNevile, Cameron McCormack, Martin McEvoy, Benjamin Meadowcroft, Shawn Medero, Reinier Meenhorst, Jens Meiert, Jakob Melander, Markus Mielke, Ben Millard, Mark Miller, Ryan Mitchell, Katsuhiko Momoi, Stefan More, Terry Morris, Thomas Morris, Daniel Morrison, Simon Myers, Stuart Myles, Marco Neumann, Sharon Newman, Tom Nguyen, Andrey Nikanorov, Jer Noble, Andrew Norman, Joshue O Connor, Robert O'Callahan, Edward O'Connor, Matt Obee, Frank Olivier, Ryan Orr, Debi Orton, Kulanthaivel Palanichamy, Frank Palinkas, Soohong Daniel Park, Sylvain Pasche, Chris Pearce, Brian Peppler, Ariel Pérez, Adele Peterson, Silvia Pfeiffer, Simon Pieters, Benoit Piette, Thomas Pike, Gabriel Pizzorno, Andrew Polk, Andrei Polushin, Pasquale Popolizio, Harri Porten, Alexey Proskuryakov, Michael Puls II, Juan Quemada, T.V. Raman, Andrew Ramsden, Arun Ranganathan, Marco Ranon, Matthew Ratzloff, Matthew Raymond, Ron Reisor, Daniel Renfer, Julian Reschke, Cyra Richardson, Ole Riesenberg, Anders Ringqvist, Adam Roben, Alex Robinson, Jude Robinson, Leonard Rosenthol, Gregory Rosmaita, Tony Ross, Steven Roussey, Sam Ruby (chair), Pietro Russo, Weston Ruter, Monikandan S, Lucas Sa, Rene Saarsoo, Sajid Saiyed, Janina Sajka, joaquin Salvachua, satish sangaru, Samuel Santos, Sorin Sbarnea, Daniel Schattenkirchner, Doug Schepers, Kai Scheppe, Christian Schmidt, Sebastian Schnitzenbaumer, Christopher Schroeder, Richard Schwerdtfeger, Gavin Sharp, Cynthia Shelly, Jonas Sicking, Andrew Sidwell, Leif Halvard Silli, David Singer, Henri Sivonen, Brian Skahan, Kenneth Sklander, Dan Smith, Dylan Smith, Michael(tm) Smith (staff contact), Sam Sneddon, Gnanasekar S Somanathan, Manu Sporny, Elliott Sprehn, Maciej Stachowiak (chair), Vicki Stanton, Hallvord Steen, Johnny Stenback, Robert Stern, Peter Stewart, Stephen Stewart, Andrew Stibbard, Bruce Stockwell, Motti Strom, Oli Studholme, Mihai Sucan, Bryan Sullivan, Marat Tanalin, Mike Taylor, Philip Taylor, Sander Tekelenburg, Shane Thacker, Nik Thierry, Morten Tollefsen, Dominik Tomaszuk, Dzung Tran, Monika Trebo, Mark Turnage, Jason Turnbull, Scott Turner, Michael Turnwall, Matthew Turvey, Asbjørn Ulsberg, Wesley Upchurch, Ojan Vafai, Erik van Kempen, Anne van Kesteren, Sander van Lambalgen, Charl van Niekerk, Tim van Oostrom, Christopher Varley, Jean-Charles Verdié, John Vernaleo, Scott Vesey, Sigbjørn Vik, Laurent Vilday, Kent Villard, Jace Voracek, David Voth, Vladimir Vukicevic, Johnson Wang, Martijn Wargers, Jonathan Watt, Kyle Weems, Samuel Weinig, Ian Wessman, Ben West, Jason White, Michael Whitley, Joe Williams, Andrew Wilson, Chris Wilson, Doug Wright, Han Xu, Mateo Yadarola, Masataka Yakura, Channy Yun, Michael Zajac, Boris Zbarsky, Milan Zoufal, Michael zur Muehlen

HTML+RDFa 1.1

Support for RDFa in HTML4 and HTML5

W3C Working Draft 29 March 2012

Abstract

Status of This Document

Table of Contents

1. Introduction

2. Conformance

2.1 Document Conformance

2.2 RDFa Processor Conformance

2.3 User Agent Conformance

3. Extensions to RDFa Core 1.1

3.1 Additional RDFa Processing Rules

3.2 Modifying the Input Document

3.3 Specifying the language for a literal

3.4 Invalid XMLLiteral values

4. Extensions to the HTML5 Syntax

5. Backwards Compatibility

5.1 `xmlns:`-Prefixed Attributes

5.2 Conformance Criteria for `xmlns:`-Prefixed Attributes

5.3 Preserving Namespaces via Coercion to Infoset

5.4 Infoset-based Processors

5.4.1 Extracting URI Mappings from Infosets

5.4.2 Processing RDFa Attributes

5.5 DOM Level 1 and Level 2-based Processors

5.5.1 Extracting URI Mappings via DOM Level 2

5.5.2 Processing RDFa Attributes

A. Validation

A.1 HTML4 + RDFa DTDs

B. About this Document

B.1 History

B.2 Change History

B.3 Acknowledgments

C. References

C.1 Normative references

C.2 Informative references

HTML+RDFa 1.1

Support for RDFa in HTML4 and HTML5

W3C Working Draft 29 March 2012

Abstract

Status of This Document

Table of Contents

1. Introduction

2. Conformance

2.1 Document Conformance

2.2 RDFa Processor Conformance

2.3 User Agent Conformance

3. Extensions to RDFa Core 1.1

3.1 Additional RDFa Processing Rules

3.2 Modifying the Input Document

3.3 Specifying the language for a literal

3.4 Invalid XMLLiteral values

4. Extensions to the HTML5 Syntax

5. Backwards Compatibility

5.1 xmlns:-Prefixed Attributes

5.2 Conformance Criteria for xmlns:-Prefixed Attributes

5.3 Preserving Namespaces via Coercion to Infoset

5.4 Infoset-based Processors

5.4.1 Extracting URI Mappings from Infosets

5.4.2 Processing RDFa Attributes

5.5 DOM Level 1 and Level 2-based Processors

5.5.1 Extracting URI Mappings via DOM Level 2

5.5.2 Processing RDFa Attributes

A. Validation

A.1 HTML4 + RDFa DTDs

B. About this Document

B.1 History

B.2 Change History

B.3 Acknowledgments

C. References

C.1 Normative references

C.2 Informative references

5.1 `xmlns:`-Prefixed Attributes

5.2 Conformance Criteria for `xmlns:`-Prefixed Attributes