HTML+RDFa 1.1 (original) (raw)

Support for RDFa in HTML4 and HTML5

W3C Working Draft 07 February 2013

This version:

http://www.w3.org/TR/2013/WD-html-rdfa-20130207/

Latest published version:

http://www.w3.org/TR/html-rdfa/

Latest editor's draft:

http://www.w3.org/2010/02/rdfa/sources/rdfa-in-html/

Test suite:

http://rdfa.info/test-suite/

Previous version:

http://www.w3.org/TR/2012/WD-rdfa-in-html-20121213/

Editor:

Manu Sporny, Digital Bazaar, Inc.

Authors:

Shane McCarron, Applied Testing and Technology, Inc.

Ben Adida, Creative Commons

Mark Birbeck, Sidewinder Labs

Gregg Kellogg, Kellogg Associates

Ivan Herman, W3C

Steven Pemberton, CWI

This document is also available in this non-normative format: diff to previous version

Copyright © 2009-2013W3C® (MIT,ERCIM,Keio), All Rights Reserved.W3C liability,trademark anddocument use rules apply.

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.

Status of This Document

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 latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This specification had been jointly developed by the RDFa Working Group and theHTML Working Group. The document was previously published via the HTML Working Group, but has since been transitioned to the newly rechartered RDFa Working Group.

Changes in this version of the specification include:

• The addition of the Property Copying feature, a Microdata @itemref-like mechanism.
• The addition of special processing rules for head and body.
• Update of the Acknowledgements section.
• Minor fixes to the specification wording in order to make processing instructions more precise.

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.

A sample test harness is available for software developers. This set of tests is not intended to be exhaustive. A community-maintained website contains more information on further reading, developer tools, and software libraries that can be used to extract RDFa data from web documents.

If no major changes to the document result from the Last Call process, an official W3C Recommendation is expected 2-3 months after the Last Call.

This document was published by the RDFa Working Group as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-rdfa-wg@w3.org (subscribe,archives). The Last Call period ends 28 February 2013. All comments are welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.

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 containsEssential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

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
  • 3.5 Property Copying
    * 3.5.1 Implementing Property Copying
• 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. About this Document
  • A.1 History
  • A.2 Change History
  • A.3 Acknowledgments
• B. References
  • B.1 Normative references
  • B.2 Informative references

1. Introduction

This section is non-normative.

Today's web is built predominantly for human readers. Even as machine-readable data begins to permeate the web, it is typically distributed in a separate file, with a separate format, and very limited correspondence between the human and machine versions. As a result, web browsers can provide only minimal assistance to humans in parsing and processing web pages: browsers only see presentation information. RDFa is intended to solve the problem of marking up machine-readable data in HTML documents. RDFa provides a set of HTML attributes to augment visual data with machine-readable hints. Using RDFa, authors may turn their existing human-visible text and links into machine-readable data without repeating content.

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 andHTML+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 appropriateExtensions 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 conforms to [HTML5]. All RDFa attributes should be used in a way that is conforms to [RDFA-CORE] and this document.

An example of a conforming HTML+RDFa document, with the RDFa portions highlighted in green:

Example 1: Example of an HTML+RDFa 1.1 document

Welcome to my blog.

The following data will be extracted by a conforming RDFa processor, shown in Turtle format [TURTLE]:

Example 2: Turtle output of Example Document

@prefix schema: http://schema.org/ .

[] a schema:Blog; schema:url http://example.org/ .

Non-XML mode HTML+RDFa 1.1 documents should be labeled with the Internet media type text/html as defined insection 12.1of the HTML5 specification [HTML5].

XML mode XHTML5+RDFa 1.1 documents should be labeled with the Internet Media Type application/xhtml+xml as defined insection 12.3of the HTML5 specification [HTML5], must not use a DOCTYPEdeclaration for XHTML+RDFa 1.0 or XHTML+RDFa 1.1, and should not use the@version attribute.

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 Section 2.2: Conformance Requirements 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. An RDFa processor operating on both HTML and XHTML documents, specifically on their resulting DOMs or infosets, must apply these 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).
• Thebase can be set using the base element. For XHTML5+RDFa 1.1 documents,base can also be set using the @xml:base attribute.
• Thecurrent language can be set using either the @lang or @xml:lang attributes. When the @lang attribute and the@xml:lang attribute are specified on the same element, the@xml:lang attribute takes precedence. When both@lang and @xml:lang are specified on the same element, they must have the same value.
• When determining which set of RDFa processing rules to use for documents served with the application/xhtml+xml media type, a conforming RDFa processor must look at the value in the DOCTYPE declaration of the document. If a DOCTYPE declaration exists, then the processing rules are:
  • XHTML1+RDFa 1.0 for a DOCTYPE of <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">, or
  • XHTML1+RDFa 1.1 for a DOCTYPE of <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">, or
  • XHTML5+RDFa 1.1 for all other values of DOCTYPE.
    Documents served as application/xhtml+xml, that don't contain a DOCTYPE declaration, and don't specify a @version attribute must be interpreted as XHTML5+RDFa 1.1 documents.
• In Section 7.5: Sequence, processing step 3, if theprocessor graph feature is supported and if anIRI mapping overwrites a previously existing mapping in thelocal list of IRI mappings with a different value, the processor must generate an appropriaterdfa:PrefixRedefinition warning and place the associated triples into theprocessor graph.
• In Section 7.5: Sequence, immediately after processing step 4, if the@property attribute and the @rel and/or@rev attribute exists on the same element, the non-CURIE and non-URI @rel and @rev values are ignored. If, after this, the value of @rel and/or @rev becomes empty, then the processor must act as if the respective attribute is not present.
• In Section 7.5, processing step 5, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then setnew subject toparent object.
• In Section 7.5, processing step 6, if no IRI is provided by a resource attribute (e.g., @about, @href, @resource, or @src), then first check to see if the element is the head or body element. If it is, then set new subject toparent object.
• In Section 7.5: Sequence, processing step 11, the HTML5@datetime attribute must be utilized when generating output. If@datetime is detected and the value of the attribute is a validxsd:date, xsd:time, xsd:dateTime,xsd:duration, xsd:gYear, orxsd:gYearMonth, then a triple must be generated where the current property value is the matching xsd datatype and the value is the value contained in the @datetime attribute. If @datatype is specified, it must take precedence. If no @datatype is specified, and the value does not match any of the automatically detected xsd datatypes, a plain literal must be generated with the associated language of the node, if available. If @content is specified on the same element, it must take precedence over @datetime and the contents of the element and must be processed according to the rules defined in [RDFA-CORE].
• In Section 7.5: Sequence, processing step 11, if the element istime, and the element does not have @datetime or @content attributes, the processor must act as if there is a @datetime attribute containing exactly the elements text value.
• In Section 7.5: Sequence, step 11, immediately after sub-step 2, if the@datatype attribute is present and evaluates tohttp://www.w3.org/1999/02/22-rdf-syntax-ns#HTML, the value of the HTML Literal is a string created by serializing all child nodes to text. This applies to all nodes that are descendants of the current element, not including the element itself. The HTML Literal is given a datatype of http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML as defined in Section 5.2: The rdf:HTML Datatype of [RDF-CONCEPTS].
• Once theoutput graph is generated following the processing steps defined inSection 7.5: Sequence of the RDFa Core 1.1 specification [RDFA-CORE], and the steps in this section, perform the operations defined inImplementing Property Copying.

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 inSection 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

According to RDFa Core 1.1 thecurrent language may be specified by the host language. In order to conform to this specification, RDFa processors must use the mechanism described in_The lang and xml:lang attributes_ section of the [HTML5] specification to determine thelanguage of a node.

If the final encapsulating MIME type for an HTML fragment is not decided on while editing, it is recommended 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: that are stored in the RDFa processor's currentevaluation context in theIRI mappings must be preserved in the generated XMLLiteral. The PREFIX value for@xmlns:PREFIX must be entirely transformed into lower-case characters when preserving the value in the XMLLiteral. All active namespaces declared via @xmlns, @xmlns:, and @prefix 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 plain text input data that are text-only, such as literals that contain a @datatype attribute with an empty value (""), or input data 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:

Example 3: Namespace preservation markup

Two rectangles (the example markup for them are stored in a triple):

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:

Example 4: Namespace preservation triple

<> 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 rdfnamespaces 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 namespace declarations preserved:

Example 5: Namespace preservation for compound document elements

This is how you markup a user in FBML: →The User →

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

Example 6: Namespace element preservation triple

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

3.5 Property Copying

Issue 1

This feature is at risk, and may be removed from a subsequent version of this specification. Reviewers are invited to comment on the utility of this feature.

There are times when authors will find that they have many resources on a page that share a common set of properties. For example, several music events may have different performance times, but use the same location, band, and ticket prices. In this particular case, it is beneficial to have a short-hand notation to instruct the RDFa processor to include the location, band, and ticket price information without having to repeat all of the markup that expresses the data.

HTML+RDFa defines a property copying mechanism which allows properties associated with a resource to be copied to another resource. This mechanism can be activated by using the rdfa:copy predicate. The feature is illustrated in the following two examples:

Example 7: Events with duplicate properties

In this case, two music events are defined with image,name, startDate, and location properties. The image and name values are identical for the two events and are unnecessarily duplicated in the markup. Using RDFa's property copying feature, a pattern can be declared that expresses the common properties. This pattern can then be copied into other resources within the document:

Example 8: Copying common properties

In this case, the common properties for all of the events are expressed in the first div. The common properties are copied into each event resource via the rdfa:copy predicate. The output for the previous two examples is the same:

Example 9: Turtle output of property copying example

@prefix schema: http://schema.org/ .

[] a schema:MusicEvent; schema:image <Muse1.jpg>, <Muse2.jpg>, <Muse3.jpg>; schema:name "Muse"; schema:startDate "March 3rd 2013"; schema:location <#united> .

[] a schema:MusicEvent; schema:image <Muse1.jpg>, <Muse2.jpg>, <Muse3.jpg>; schema:name "Muse"; schema:startDate "March 7th 2013"; schema:location <#target> .

The copy process is iterative, so that resources may copy other resources that copy other resources. For example:

Example 10: Resources may copy other resources that copy other resources

In the example above, the properties from #lennon and #band are copied into the first resource. Then the properties from #beatles are copied into#band. Subsequently, those properties are again copied into the first resource yielding the following output:

Example 11: Iterative copying example output in Turtle

@prefix schema: http://schema.org/ .

[ a schema:Person; schema:name "John Lennon" ; schema:band [ a schema:MusicGroup; schema:name "The Beatles"; schema:size "4" ] ] .

Similar toVocabulary Expansion as defined in [RDFA-CORE], RDFa Property Copying operates on theoutput graph after document processing is complete.

3.5.1 Implementing Property Copying

Once theoutput graph is generated following the processing steps defined inSection 7.5: Sequence of the RDFa Core 1.1 specification [RDFA-CORE], and the Extensions to the HTML5 Syntax defined in this specification, processors must update theoutput graph using the following rules:

1. Run the following rule for each rdfa:copy statement in the output graph, and for each new rdfa:copy statement added as a result of property copying until no new triples are added to theoutput graph:

   Rule name	If output graph contains	then add
   pattern-copy	?subject rdfa:copy ?target ?target rdf:type rdfa:Pattern ?target ?predicate ?object	?subject ?predicate ?object

2. Finally, run this rule to remove utilized rdfa:copy statements and rdfa:Pattern resources from the output graph:

   Rule name	If output graph contains	then remove
   pattern-clean	?subject rdfa:copy ?target ?target rdf:type rdfa:Pattern ?target ?predicate ?object	?subject rdfa:copy ?target ?subject rdf:type rdfa:Pattern ?target ?predicate ?object

Note

Implementers should be aware that a simplistic implementation of the pattern-copy rule may lead to an infinite loop when handling circular dependencies. A processor should cease the pattern-copy rule when no unique triples are generated.

Note

Alternate rules may be used to update the output graph as long as the end result is the same.

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, such as@href and @src, are only allowed when consistent with the content model for that element, as defined in the HTML5 specification.
• If HTML+RDFa document conformance is desired, all RDFa attributes and valid values (including CURIEs), as listed inRDFa 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, such as@href and @src, are only allowed when consistent with the content model for that element, as defined in the HTML5 specification.
• If any RDFa attribute is present on the link ormeta elements, they must be viewed as conforming if used in the body of the document. More specifically, when link or meta elements containing RDFa attributes are used in the body of an HTML5 document, they must be considered flow content.
• If the RDFa @property attribute is present on the link element, the @rel attribute is not required.
• If the RDFa @resource attribute is present on the link element, the @href attribute is not required.
• If the RDFa @property attribute is present on the meta element, neither the @name, @http-equiv, nor @charset attributes are required and the @content attribute must be specified.

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 MIME type. 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 elaborate upon the backwards compatibility requirements for RDFa processor implementations.

5.1 @xmlns:-Prefixed Attributes

The RDFa Core 1.1 [RDFA-CORE] specification deprecates the use of the @xmlns: mechanism to declare CURIE prefix mappings in favor of the @prefix attribute. However, there are instances where its use is unavoidable. For example, 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 3 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 should 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. Conformance checkers may report the use of xmlns: as an error.

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

Issue 2

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:

Example 12