Copyright © 2017 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This document provides guidance for developers on implementing Evaluation and Report Language (EARL) 1.0 in software tools and process. EARL is a vocabulary, the terms of which are defined across a set of specifications and technical notes, that is used to describe test results. The primary motivation for developing this vocabulary is to facilitate the exchange of test results between web accessibility evaluation tools in a vendor-neutral and platform-independent format. It also provides reusable terms for generic quality assurance and validation purposes.
While this document provides developer guidance for using and implmenting EARL, Evaluation and Report Language (EARL) 1.0 Schema defines the core terms of the vocabulary, and other specifications provide additional terms for representing HTTP exchanges between clients and servers, HTTP Vocabulary in RDF 1.0, for representing web content itself, Representing Content in RDF 1.0, or for specifying particular locations within or sections of content, Pointer methods in RDF 1.0. An Evaluation and Report Language (EARL) Overview is also available.
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 https://www.w3.org/TR/.
This Developer Guide for Evaluation and Report Language (EARL) 1.0 provides an introduction to EARL and defines conformance requirements for software tools supporting EARL. It is published as a W3C Working Group Note because the Evaluation and Repair Tools Working Group (ERT WG) reached the end of its Charter.
EARL 1.0 Guide is supporting document for the Evaluation and Report Language (EARL) 1.0 Schema. It is fairly complete but at this time there are not sufficient implementations to finalize this work. Particularly the section on conformance may not be adequately mature.
If you wish to make comments regarding this Evaluation and Report Language (EARL) 1.0 Guide document, please send them to public-earl10-comments@w3.org (publicly visible mailing list archive).
Publication as a Working Group Note 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 document has been produced by the Evaluation and Repair Tools Working Group (ERT WG) as part of the Web Accessibility Initiative (WAI) Technical Activity.
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.
This document is governed by the 1 September 2015 W3C Process Document.
This document is a guide to the Evaluation and Report Language (EARL) 1.0 for developers of software tools and proccesses. It provides an introduction to EARL and its uses, defines conformance requirements for tools supporting EARL, and describes approaches for serializing EARL data in different formats.
EARL is a vocabulary, the terms of which are defined across a set of specifications and technical notes, that is used to describe test results in a machine-readable format. This set of specifications includes:
An Evaluation and Report Language (EARL) Overview is also available.
The assumed audience of this document is developers of software tools and processes, who want to implement EARL. This includes developers of quality assurance tools, in particular developers of web accessibility evaluation tools, web authoring tools, and web quality assurance tools.
This document assumes that the reader is familiar with the Resource Description Framework (RDF) and can read its XML serialization. Readers who wish to understand more about RDF should read a general introduction or the RDF Primer [RDF-PRIMER]. This document is also written with consideration for developers who are more accustomed to XML than RDF, but reader is cautioned about notable differences between the syntax-based nature of XML and the semantic-based nature of RDF.
The keywords must, required, recommended, should, may, and optional in this document are used in accordance with RFC 2119 [RFC 2119].
The RDF
representation of the vocabulary defined by this document uses the namespace
http://www.w3.org/ns/earl#
. The prefix earl
is used
throughout this document to denote this namespace. Other prefixes used
throughout this document include:
cnt
- Representing Content in RDF namespace http://www.w3.org/2011/content#
(defined by [Content])dct
- Dublin Core (DC) namespace http://purl.org/dc/terms/
(defined by [DC])doap
- Description of a Project (DOAP) namespace http://usefulinc.com/ns/doap#
(defined by [DOAP])foaf
- Friend of a Friend (FOAF) namespace http://xmlns.com/foaf/spec/#
(defined by [FOAF])http
- HTTP Vocabulary in RDF
namespace http://www.w3.org/2011/http#
(defined by [HTTP])ptr
- Pointer Methods in RDF namespace http://www.w3.org/2009/pointers#
(defined by [Pointers])rdf
- RDF namespace http://www.w3.org/1999/02/22-rdf-syntax-ns#
(defined by [RDF])rdfs
- RDF Schema namespace http://www.w3.org/2000/01/rdf-schema#
(defined by [RDFS])xsd
- XMLS namespace http://www.w3.org/2001/XMLSchema#
(defined by [XMLS])The Evaluation and Report Language (EARL) is a vocabulary to describe test results in a machine-readable format. EARL supports the test reporting stage in the testing process, as described by different standards on testing, such as IEEE 829 [IEEE-829]. Stages in the testing process include:
Figure 1. Stages in the testing processes.
EARL vocabulary can be used to describe resources to be tested as defined by the test plan, test cases and criteria as defined by the test specification, and outcomes of the test execution stages. More importantly, EARL provides a format to uniformly record these and other elements in semantically rich testing reports.
[Editor note: this section overlaps with section "2. Classes" of EARL 1.0 Schema and needs to reviewed after further review and refinement.]
The terms of EARL are defined using the Resource Description Framework [RDF], which is technology to express semantic data in a machine-readable format. Like any RDF vocabulary, EARL is a collection of statements about resources, each with a subject, a predicate (or verb), and an object. RDF statements describe resources and relationships, such as in the following example:
<#someone> <#checks> <#resource> . <#resource> <#fails> <#test> .
EARL provides a standardized vocabulary to describe specific resources and relationships that are relevant to test reporting. The core construct of EARL is an Assertion, which describes the context and outcome of an individual test execution. It contains the following information:
Example 1: A person carries out a manual evaluation of a web page to an accessibility requirement.
http://www.example.org/page.html
Example 2: A software application carries out automated validation of a web page to a technical specification.
http://validator.w3.org/
http://www.example.org/page.html
at
2004-04-14T14:00:04+1000
<li>
element on line 53, char 7 was not
closed.As a standardized machine-readable format, EARL facilitates processing of test results, such as those generated by automated or semi-automated web accessibility evaluation tools. Web authoring tools and quality assurance software can aggregate such test results to support website developers in developing high quality web content. EARL has been specifically designed to support a broad variety of uses cases, including the following:
[Editor note: this section needs to be extended and refined in later iterations
It is important to consider potential security and privacy issues when using EARL. For instance, test results expressed in EARL could contain sensitive information such as the internal directory structure of a web server, username and password information, parts of restricted Web pages, or testing modalities. The scope of this document is limited to the use of the EARL vocabulary: security and privacy considerations need to be made at the application level. For example, certain parts of the data may be restricted to appropriate user permissions, encrypted or obfuscated.
[Editor note: this entire section needs to be revised and refined in later iterations.
EARL is not a standalone vocabulary and builds on top of many existing vocabularies that cover some of its needs for metadata definition. This approach avoids the re-creation of applications already established and tested like the Dublin Core elements. The referenced specifications are:
These vocabularies are referenced via namespaces in the corresponding RDF serialization. The list of the normative namespaces can be found in the EARL 1.0 Schema. RDF can be serialized in many equivalent ways, but its XML presentation [RDF/XML] is the preferred method and will be used throughout this document.
In the following sections, we will construct an EARL report with several examples of each component of the report. The root element of any EARL report is an RDF node, in which we declare the namespaces used to define additional classes and/or properties.
Example 3.1. The root element of an EARL report [download file for example 3.1].
<rdf:RDF xmlns:earl="http://www.w3.org/ns/earl#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> <!-- ... --> </rdf:RDF>
Next, let us assume that we want to express the results of an XHTML validation in a
given document with the W3C HTML
Validator. The tested document can be found in the fictitious URL
http://example.org/resource/index.html
and has the following HTML
code:
Example 3.2. An XHTML document to be validated [download file for example 3.2].
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>Example of project pages</title> </head> <body> <h1>Project description</h1> <h2>My project name</h2> <!-- ... --> </body> </html>
This document has three errors that will constitute the basis of our EARL report:
li
" here; missing one of "ul
", "ol
"
start-tag.li
" omitted, but
OMITTAG NO was specified.alt
".The first step is to define who performed the test, either
a human being or a software tool. This is noted in the EARL framework as an
Assertor
. Let us consider different use cases. First, let us
assume that only the W3C HTML Validator performed the test. This could be
expressed as an Assertor
:
Example 3.3. A
generic tool as an Assertor
[download file for example 3.3].
<earl:Assertor rdf:about="http://validator.w3.org/about.html#"> <dct:title xml:lang="en">W3C HTML Validator</dct:title> <dct:description xml:lang="en"> W3C Markup Validation Service, a free service that checks Web documents in formats like HTML and XHTML for conformance to W3C Recommendations and other standards. </dct:description> </earl:Assertor>
Notice that the Assertor
class provides a mechanism by which to
specify more information by leveraging standard Dublin Core properties like
dct:title
and dct:description
. This is not the only
possible serialization of this report. An alternative, expressed in N3, could
be:
Example 3.4. An
Assertor
expressed in N3 notation [download file for example 3.4].
@prefix earl: <http://www.w3.org/ns/earl#> . @prefix dct: <http://purl.org/dc/terms/> . <http://validator.w3.org/about.html#> a earl:Assertor ; dct:description """W3C Markup Validation Service, a free service that checks Web documents in formats like HTML and XHTML for conformance to W3C Recommendations and other standards."""@en ; dct:title "W3C HTML Validator"@en .
An Assertor
is a generic type. EARL allows the use of certain
FOAF classes like Agent
, Organisation
, or
Person
to provide more semantic information on the type of
assertor. Additionally, EARL defines the Software
class to declare
tool assertors. Thus, our W3C Validator could be described more adequately in
the following way:
Example 3.5. A
Software
assertor [download file for example 3.5].
<earl:Software rdf:about="http://validator.w3.org/about.html#"> <dct:title xml:lang="en">W3C HTML Validator</dct:title> <dct:hasVersion>0.7.1</dct:hasVersion> <dct:description xml:lang="en"> W3C Markup Validation Service, a free service that checks web documents in formats like HTML and XHTML for conformance to W3C Recommendations and other standards. </dct:description> </earl:Software>
Notice the aditional property, dct:hasVersion
, indicating the
version of the software. Let us consider now the case where the assertor is a
person. This can be expressed as in the following example:
Example 3.6. A
Person
as an EARL assertor [download file for example 3.6].
<foaf:Person rdf:ID="john"> <foaf:mbox rdf:resource="mailto:john@example.org"/> <foaf:name>John Doe</foaf:name> </foaf:Person>
We could combine assertors as well. The typical example could be an expert
evaluator and a software tool, which perform the analysis. This set of
assertors can be expressed under the umbrella of a foaf:Group
. We
should define who is the main assertor within a foaf:Group
through
the mainAssertor
property (notice in the example how the person is
defined as a blank node):
Example 3.7. A
foaf:Group
(software tool and person) as an assertor [download file for example 3.7].
<foaf:Group rdf:ID="assertor01"> <dct:title>John Doe and the W3C HTML Validator</dct:title> <earl:mainAssertor rdf:resource="http://validator.w3.org/about.html#"/> <foaf:member> <foaf:Person> <foaf:mbox rdf:resource="mailto:john@example.org"/> <foaf:name>John Doe</foaf:name> </foaf:Person> </foaf:member> </foaf:Group>
The second step is to define what was analyzed, the tested
resource. For that, EARL defines the TestSubject
class. This class
is a generic wrapper for things to be tested like Web resources
(cnt:Content
) or software (earl:Software
). In this
case, the Example 3.2 could be represented as:
Example 3.8. A
TestSubject
with some Dublin Core properties (non-abbreviated
RDF/XML serialization) [download file
for example 3.8].
<rdf:Description rdf:about="http://example.org/resource/index.html"> <dct:title xml:lang="en">Project Description</dct:title> <dct:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2006-02-14</dct:date> <rdf:type rdf:resource="http://www.w3.org/ns/earl#TestSubject"/> </rdf:Description>
Using the Representing Content in RDF vocabulary (via the
cnt:ContentAsText
class), we could insert the content of the test
XHTML file into the report:
Example 3.9. A
test subject expressed as cnt:ContentAsText
(notice that the
special XML characters have been escaped because the document is not
well-formed to be expressed as an XML Literal) [download file for example 3.9].
<cnt:ContentAsText rdf:about="http://example.org/resource/index.html"> <dct:title xml:lang="en">Project Description</dct:title> <dct:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2006-02-14</dct:date> <cnt:characterEncoding>UTF-8</cnt:characterEncoding> <cnt:chars><?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>Example of project pages</title> </head> <body> <h1>Project description</h1> <h2>My project name</h2> <p>The strategic goal of this project is to make you understand EARL.</p> <ul> <li>Here comes objective 1. <li>Here comes objective 2.</li> </ul> <p alt="what?">And goodbye ...</p> </body> </html> </cnt:chars> </cnt:ContentAsText>
The third step is to define the criterion used for testing
the resource. EARL defines test criteria under the umbrella of the
TestCriterion
class. This class has two subclasses,
TestRequirement
and TestCase
, depending on whether
the criterion is a high level requirement, composed of many tests, or an atomic
test case. In our example, we are testing validity against the XHTML 1.0 Strict specification, which
could be expressed in the following way via the TestRequirement
class:
Example 3.10. A
TestRequirement
with some Dublin Core properties [download file for example 3.10].
<earl:TestRequirement rdf:about="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <dct:title xml:lang="en">XHTML 1.0 Strict Document Type Definition</dct:title> <dct:description xml:lang="en">DTD for XHTML 1.0 Strict.</dct:description> </earl:TestRequirement>
The fourth step is to specify the results of the test.
There were three errors discovered by the W3C Validator that need to be
presented as TestResult
s. In this case, we present only the
errors, but it is also possible to present positive results. In the example
below, we present the message errors as text messages within XHTML snippets. We
will see later how to improve the machine-readability of such results.
Example 3.11. Results of the tests with the validator [download file for example 3.11].
<earl:TestResult rdf:ID="error1"> <dct:description rdf:parseType="Literal"> <div xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"> <p>Error - Line 14 column 7: document type does not allow element <code>li</code>here; missing one of <code>ul</code>, <code>ol</code> start-tag.</p> </div> </dct:description> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> <earl:TestResult rdf:ID="error2"> <dct:description rdf:parseType="Literal"> <div xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"> <p>Error - Line 15 column 6: end tag for <code>li</code> omitted, but OMITTAG NO was specified.</p> </div> </dct:description> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> <earl:TestResult rdf:ID="error3"> <dct:description rdf:parseType="Literal"> <div xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"> <p>Error - Line 16 column 9: there is no attribute <code>alt</code>.</p> </div> </dct:description> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult>
The final step is to merge together the created components. The EARL statements for this
purpose are called Assertion
s, and have four key properties:
earl:assertedBy
, earl:subject
, earl:test
and earl:result
. Each of them serves to point to the corresponding
assertors, test subjects, test requirements, and results, respectively. From
our previous examples, we could build our first complete report with our three
assertions:
Example 3.12. Results of the tests with the W3C Validator [download file for example 3.12].
<earl:Assertion rdf:ID="ass1"> <earl:result rdf:resource="#error1" /> <earl:test rdf:resource="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" /> <earl:subject rdf:resource="http://example.org/resource/index.html" /> <earl:assertedBy rdf:resource="#assertor01" /> </earl:Assertion> <earl:Assertion rdf:ID="ass2"> <earl:result rdf:resource="#error2" /> <earl:test rdf:resource="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" /> <earl:subject rdf:resource="http://example.org/resource/index.html" /> <earl:assertedBy rdf:resource="#assertor01" /> </earl:Assertion> <earl:Assertion rdf:ID="ass3"> <earl:result rdf:resource="#error3" /> <earl:test rdf:resource="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" /> <earl:subject rdf:resource="http://example.org/resource/index.html" /> <earl:assertedBy rdf:resource="#assertor01" /> </earl:Assertion>
Our next example presents the results of an accessibility test in a given Web resource. Let us consider a simple XHTML page, which presents the image of a cat:
Example 3.13. An XHTML document to be verified [download file for example 3.13].
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>A cat's photography</title> </head> <body> <h1>A cat's photography</h1> <p>Image of a cat who likes <acronym title="Evaluation and Report Language">EARL</acronym>, although it seems quite tired. <img src="../images/cat.jpg" alt="Image of a white cat with black spots."/> </p> </body> </html>
We have in this case a software tool called "Cool Tool" that performs a test
against the Common Failure
F65 from the (X)HTML techniques for WCAG 2.0 [WCAG20]. This technique proofs the existence of the
alt
attribute for given (X)HTML elements like img
.
The software can be represented as:
Example 3.14. A
Software
assertor [download file for example 3.14].
<earl:Software rdf:about="http://example.org/cooltool/"> <dct:title xml:lang="en">Cool Tool accessibility checker</dct:title> <dct:hasVersion>1.0.c</dct:hasVersion> <dct:description xml:lang="en">A reliable compliance checker for Web Accessibility</dct:description> </earl:Software>
The test requirement can be represented as:
Example 3.15. A
TestCase
for a WCAG 2.0 technique [download file for example 3.15].
<earl:TestCase rdf:about="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65"> <dct:title xml:lang="en">Failure of Success Criterion 1.1.1 from WCAG 2.0</dct:title> <dct:description xml:lang="en">Failure due to omitting the alt attribute on img elements, area elements, and input elements of type image.</dct:description> </earl:TestCase>
We can make the test result more amenable to machine processing by making use of the Pointers [Pointers-RDF] vocabulary. In this case, we identify the line number where the test was compliant:
Example 3.16. A
TestResult
with a pointer [download file for example 3.16].
<ptr:LineCharPointer rdf:ID="pointer"> <ptr:lineNumber>15</ptr:lineNumber> <ptr:reference rdf:resource="http://example.org/resource/index.html" /> </ptr:LineCharPointer> <earl:TestResult rdf:ID="result"> <earl:pointer rdf:resource="#pointer" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#passed" /> </earl:TestResult>
Which leads to the following assertion:
Example 3.17.
Accessibility Assertion
[download file for example
3.17].
<earl:Assertion rdf:ID="assert"> <earl:result rdf:resource="result" /> <earl:test rdf:resource="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65" /> <earl:subject rdf:resource="http://example.org/resource/index.html" /> <earl:assertedBy rdf:resource="http://example.org/cooltool/" /> </earl:Assertion>
There are cases where the identification of a resource on the Web requires
more than a URL. This occurs typically when the user agent and the server
exchange HTTP messages via Content
Negotiation to deliver the best possible alternative to the client. A
common scenario appears when the user expresses a preference for given
languages with a ranking via the Accept-Language
header. Under those circumstances, it is necessary to use the HTTP vocabulary
in RDF [HTTP-RDF] to identify correctly the
TestSubject
.
Let us assume that our exemplary Web server can deliver under the URL
http://example.org/resource/index.html
two versions (English and
Spanish) of a given XHTML page. The English version can be seen in Example 3.13. The Spanish version can be seen in the
listing below:
Example 3.18. An XHTML file resource in Spanish [download file for example 3.18].
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html lang="es" xmlns="http://www.w3.org/1999/xhtml" xml:lang="es"> <head> <title>Fotografia de un gato</title> </head> <body> <h1>Fotografia de un gato</h1> <p>Imagen de un gato al que le gusta <acronym title="Evaluation and Report Language" xml:lang="en" lang="en">EARL</acronym>, aunque aparenta estar muy cansado. <img src="../images/cat.jpg" /> </p> </body> </html>
The English resource can be represented as:
Example 3.19. RDF representation of Example 3.13 [download file for example 3.19].
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:earl="http://www.w3.org/ns/earl#" xmlns:dct="http://purl.org/dc/terms/" xmlns:cnt="http://www.w3.org/2008/content#" xmlns:http="http://www.w3.org/2006/http#" xml:base="http://www.example.org/resource/content_001#"> <cnt:ContentAsBase64 rdf:ID="content1"> <cnt:bytes rdf:datatype="http://www.w3.org/2001/XMLSchema#base64Binary">PD94bWwgdmVyc2lv...</cnt:bytes> </cnt:ContentAsBase64> <http:Response rdf:ID="response1"> <http:httpVersion>1.1</http:httpVersion> <http:statusCodeNumber>200</http:statusCodeNumber> <http:sc rdf:resource="http://www.w3.org/2008/http-statusCodes#200" /> <http:reasonPhrase>OK</http:reasonPhrase> <http:headers rdf:parseType="Collection"> <http:MessageHeader> <http:fieldName>Vary</http:fieldName> <http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#vary" /> <http:fieldValue>Accept-Language</http:fieldValue> </http:MessageHeader> <!-- ... --> </http:headers> <http:body rdf:resource="#content1" /> </http:Response> <http:Connection rdf:ID="connection1"> <http:connectionAuthority>www.example.org:80 </http:connectionAuthority> <http:requests rdf:parseType="Collection"> <http:Request rdf:resource="#request1" /> </http:requests> </http:Connection> <http:Request rdf:ID="request1"> <http:httpVersion>1.1</http:httpVersion> <http:methodName>GET</http:methodName> <http:mthd rdf:resource="http://www.w3.org/2008/http-methods#GET" /> <http:abs_path>/resource/index.html</http:abs_path> <http:headers rdf:parseType="Collection"> <http:MessageHeader> <http:fieldName>Accept-Language</http:fieldName> <http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#accept-language" /> <http:fieldValue>en</http:fieldValue> </http:MessageHeader> <!-- ... --> </http:headers> <http:resp rdf:resource="#response1" /> </http:Request> </rdf:RDF>
The Spanish one could be represented as:
Example 3.20. RDF representation of Example 3.18 [download file for example 3.20].
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:earl="http://www.w3.org/ns/earl#" xmlns:dct="http://purl.org/dc/terms/" xmlns:cnt="http://www.w3.org/2008/content#" xmlns:http="http://www.w3.org/2006/http#" xml:base="http://www.example.org/resource/content_002#"> <cnt:ContentAsBase64 rdf:ID="content2"> <cnt:bytes rdf:datatype="http://www.w3.org/2001/XMLSchema#base64Binary" >PD94bWwgdmVyc2lvbj...</cnt:bytes> </cnt:ContentAsBase64> <http:Response rdf:ID="response2"> <http:httpVersion>1.1</http:httpVersion> <http:statusCodeNumber>200</http:statusCodeNumber> <http:sc rdf:resource="http://www.w3.org/2008/http-statusCodes#200" /> <http:reasonPhrase>OK</http:reasonPhrase> <http:headers rdf:parseType="Collection"> <http:MessageHeader> <http:fieldName>Vary</http:fieldName> <http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#vary" /> <http:fieldValue>Accept-Language</http:fieldValue> </http:MessageHeader> <!-- ... --> </http:headers> <http:body rdf:resource="#content2" /> </http:Response> <http:Connection rdf:ID="connection2"> <http:connectionAuthority>www.example.org:80</http:connectionAuthority> <http:requests rdf:parseType="Collection"> <http:Request rdf:resource="#request2" /> </http:requests> </http:Connection> <http:Request rdf:ID="request2"> <http:httpVersion>1.1</http:httpVersion> <http:methodName>GET</http:methodName> <http:mthd rdf:resource="http://www.w3.org/2008/http-methods#GET" /> <http:abs_path>/resource/index.html</http:abs_path> <http:headers rdf:parseType="Collection"> <http:MessageHeader> <http:fieldName>Accept-Language</http:fieldName> <http:hdrName rdf:resource="http://www.w3.org/2008/http-headers#accept-language" /> <http:fieldValue>es</http:fieldValue> </http:MessageHeader> <!-- ... --> </http:headers> <http:resp rdf:resource="#response2" /> </http:Request> </rdf:RDF>
Strictly speaking, for the representation of the TestSubject
,
only the http:Response
object is needed. However, it is
recommended to use the http:Request
and
http:Connection
objects to facilitate the replicability of the
results. The replicability of the results is also time-dependent as the
resources may change over time. Therefore, timestamps or modification dates in
the reports are also recommended.
We are now in the situation to allow our Cool Tool accessibility checker (see Example 3.14) to produce accurate reports on both versions of the page. The evaluation report for the English resource (assuming the same test requirement of Example 3.15) looks like the following snippet:
Example 3.21. Evaluation report for the English XHTML resource [download file for example 3.21].
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:earl="http://www.w3.org/ns/earl#" xmlns:dct="http://purl.org/dc/terms/" xmlns:cnt="http://www.w3.org/2008/content#" xmlns:ptr="http://www.w3.org/2009/pointers#" xml:base="http://www.example.org/earl/report1#"> <earl:Assertion rdf:ID="assert"> <earl:result rdf:resource="result" /> <earl:test rdf:resource="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65" /> <earl:subject rdf:resource="http://www.example.org/resource/content_001#response1" /> <earl:assertedBy rdf:resource="http://example.org/cooltool/" /> </earl:Assertion> <earl:Software rdf:about="http://example.org/cooltool/"> <dct:title xml:lang="en">Cool Tool accessibility checker</dct:title> <dct:hasVersion>1.0.c</dct:hasVersion> <dct:description xml:lang="en">A reliable compliance checker for Web Accessibility</dct:description> </earl:Software> <earl:TestCase rdf:about="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65"> <dct:title xml:lang="en">Failure of Success Criterion 1.1.1 from WCAG 2.0</dct:title> <dct:description xml:lang="en">Failure due to omitting the alt attribute on img elements, area elements, and input elements of type image.</dct:description> </earl:TestCase> <ptr:LineCharPointer rdf:ID="pointer"> <ptr:lineNumber>15</ptr:lineNumber> <ptr:charNumber>5</ptr:charNumber> <ptr:reference rdf:resource="http://www.example.org/resource/content_001#content1a" /> </ptr:LineCharPointer> <earl:TestResult rdf:ID="result"> <earl:pointer rdf:resource="#pointer" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#passed" /> </earl:TestResult> </rdf:RDF>
And the evaluation report for the Spanish resource looks like the following:
Example 3.22. Evaluation report for the Spanish XHTML resource [download file for example 3.22].
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:earl="http://www.w3.org/ns/earl#" xmlns:dct="http://purl.org/dc/terms/" xmlns:cnt="http://www.w3.org/2008/content#" xmlns:ptr="http://www.w3.org/2009/pointers#" xml:base="http://www.example.org/earl/report2#"> <earl:Assertion rdf:ID="assert"> <earl:result rdf:resource="result" /> <earl:test rdf:resource="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65" /> <earl:subject rdf:resource="http://www.example.org/resource/content_002#response2" /> <earl:assertedBy rdf:resource="http://example.org/cooltool/" /> </earl:Assertion> <earl:Software rdf:about="http://example.org/cooltool/"> <dct:title xml:lang="en">Cool Tool accessibility checker</dct:title> <dct:hasVersion>1.0.c</dct:hasVersion> <dct:description xml:lang="en">A reliable compliance checker for Web Accessibility</dct:description> </earl:Software> <earl:TestCase rdf:about="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65"> <dct:title xml:lang="en">Failure of Success Criterion 1.1.1 from WCAG 2.0</dct:title> <dct:description xml:lang="en">Failure due to omitting the alt attribute on img elements, area elements, and input elements of type image.</dct:description> </earl:TestCase> <ptr:LineCharPointer rdf:ID="pointer"> <ptr:lineNumber>16</ptr:lineNumber> <ptr:charNumber>9</ptr:charNumber> <ptr:reference rdf:resource="http://www.example.org/resource/content_002#content2a" /> </ptr:LineCharPointer> <earl:TestResult rdf:ID="result"> <earl:pointer rdf:resource="#pointer" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> </rdf:RDF>
Notice how both the result and the location of the element analyzed (in this
case the <img>
element in the page) is different in both
reports.
This section presents some advanced use of the vocabularies. In particular, we will show an example demonstrating the extensibility of the vocabulary (without losing its interoperability) and another example showing how to merge reports from different sources.
Let us assume a software product (Cool Validator 2.0) that validates XML documents on the Web against given DTDs or XML Schemas. According to the XML specification [XML], there are two types of errors:
The product defines an additional category, warning, which are errors reported by the underlying SAX parser. These are basically violations not included in the XML specification, and allow the product to continue its normal processing work. With these elements in mind, the following RDF Schema was developed:
Example 4.1. RDF
Schema in the namespace http://example.org/ns/xmlval#
for the
error extensions of Cool Validator, which contains new classes, extensions of
earl:Fail
[download file for
example 4.1].
<rdfs:Class rdf:ID="FatalError"> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> Fatal error when processing the XML file (well-formedness)</rdfs:label> <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> 1.0</owl:versionInfo> <rdfs:subClassOf rdf:resource="http://www.w3.org/ns/earl#Fail" /> </rdfs:Class> <rdfs:Class rdf:ID="Error"> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> Error when processing the XML file (validation constraint)</rdfs:label> <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> 1.0</owl:versionInfo> <rdfs:subClassOf rdf:resource="http://www.w3.org/ns/earl#Fail" /> </rdfs:Class> <rdfs:Class rdf:ID="Warning"> <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> Warning when processing the XML file (parser issues)</rdfs:label> <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> 1.0</owl:versionInfo> <rdfs:subClassOf rdf:resource="http://www.w3.org/ns/earl#Fail" /> </rdfs:Class>
A user of the aforementioned validator defines her own XML Schema (see Example 4.2) for an e-commerce application. The schema defines some restrictions in an order element, against which running Web Services payloads must be verified. To facilitate this process and provide via the Web Service a more user-friendly error feedback to her customers, she uses this validator.
Example 4.2. XML Schema for the ordering Web Service [download file for example 4.2].
<xsd:schema xmlns:xsd = "http://www.w3.org/2001/XMLSchema" elementFormDefault = "qualified"> <xsd:element name = "order"> <xsd:complexType> <xsd:sequence> <xsd:element ref = "item" maxOccurs = "unbounded"/> </xsd:sequence> <xsd:attribute name = "orderid" use = "required" type = "xsd:ID"/> <xsd:attribute name = "customer" use = "required" type = "xsd:integer"/> </xsd:complexType> </xsd:element> <xsd:element name = "item"> <xsd:complexType> <xsd:sequence> <xsd:element ref = "quantity"/> <xsd:element ref = "unitprice"/> </xsd:sequence> <xsd:attribute name = "itemid" type = "xsd:ID"/> </xsd:complexType> </xsd:element> <xsd:element name = "quantity" type = "xsd:unsignedLong"/> <xsd:element name = "unitprice"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base = "xsd:float"> <xsd:attribute name = "currency" use = "required" type = "currencyType"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> <xsd:simpleType name = "currencyType"> <xsd:restriction base = "xsd:string"> <xsd:enumeration value = "euros"/> <xsd:enumeration value = "dollars"/> <xsd:enumeration value = "pounds"/> </xsd:restriction> </xsd:simpleType> </xsd:schema>
Customer X sends as a SOAP payload the following order:
Example 4.3. SOAP payload for Customer X [download file for example 4.3].
<order xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation = "order.xsd" orderid = "oj_384" customer = "12345"> <item itemid = "cat_34894"> <quantity>2</quantity> <unitprice currency = "dollars">40.88</unitprice> </item> </order>
Which is evaluated through the Cool Validator, producing the following EARL report:
Example 4.4. First XML validation report [download file for example 4.4].
<earl:Software rdf:about="http://example.org/coolvalidator/20/"> <dct:title xml:lang="en">Cool Validator</dct:title> <dct:hasVersion>2.0</dct:hasVersion> <dct:description xml:lang="en">The best XML validator of the world.</dct:description> </earl:Software> <earl:TestCase rdf:about="http://example.org/customers/schemas/order.xsd"> <dct:title xml:lang="en">Ordering Web Service Schema</dct:title> </earl:TestCase> <earl:TestResult rdf:about="#result"> <earl:info>The end-tag for element type "quantity" must end with a '>' delimiter.</earl:info> <earl:pointer rdf:resource="#pointer" /> <earl:outcome rdf:resource="http://example.org/ns/xmlval#FatalError" /> </earl:TestResult> <ptr:LineCharPointer rdf:ID="pointer"> <ptr:charNumber>9</ptr:charNumber> <ptr:lineNumber>7</ptr:lineNumber> <ptr:reference rdf:resource="#order" /> </ptr:LineCharPointer>
This customer is aware of the EARL extensions of the Cool Validator, and can interpret the results from the perspective of the XML specification, correcting accordingly her SOAP client. Customer Y, who sent the following payload:
Example 4.5. SOAP payload for Customer Y [download file for example 4.5].
<order xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation = "order.xsd" orderid = "oj_490" customer = "67890"> <item itemid = "cat_30922"> <quantity>4.0</quantity> <unitprice currency = "euro">783.30</unitprice> </item> </order>
cannot interpret this extension of the vocabulary sent in another report. However, by supporting the EARL standard and standard subclassing mechanisms of Semantic Web vocabularies, this customer is still in the position of interpreting the outcome of the error messages and can act accordingly.
Example 4.6. Second XML validation report translated to standard EARL [download file for example 4.6].
<earl:TestResult rdf:ID="result1"> <earl:pointer rdf:resource="#pointer1" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#Fail" /> <earl:info>The value '4.0' of element 'quantity' is not valid.</earl:info> </earl:TestResult> <earl:TestResult rdf:ID="result2"> <earl:pointer rdf:resource="#pointer2" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#Fail" /> <earl:info>The value 'euro' of attribute 'currency' on element 'unitprice' is not valid with respect to its type, 'currencyType' [euros, dollars, pounds].</earl:info> </earl:TestResult> <ptr:LineCharPointer rdf:ID="pointer1"> <ptr:charNumber>33</ptr:charNumber> <ptr:lineNumber>6</ptr:lineNumber> <ptr:reference rdf:resource="#order" /> </ptr:LineCharPointer> <ptr:LineCharPointer rdf:ID="pointer2"> <ptr:charNumber>38</ptr:charNumber> <ptr:lineNumber>7</ptr:lineNumber> <ptr:reference rdf:resource="#order" /> </ptr:LineCharPointer>
Using EARL, reports from different sources can be combined to obtain more information or refine existing ones. We take as starting point an XHTML file, which contains two images. One of them lacks of an alternative text attribute. In the other one, the attribute is present, but it reflects the size of the image in bytes.
Example 4.7. An XHTML document to be tested [download file for example 4.7].
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>My photo album</title> </head> <body> <h1>My photo album<</h1> <p>These are two nice photos I took yesterday:</p> <ul> <li>Image of a cat who likes <acronym title="Evaluation and Report Language">EARL</acronym>, although it seems quite tired: <img src="../images/cat.jpg" /> </li> <li>Image of a fir tree: <img src="../images/fir_tree.jpg" alt="98211 bytes" /> </li> </ul> </body> </html>
An accessibility evaluator who wants to verify the compliance of this page against success criteria 1.1.1 from WCAG 2.0 [WCAG20] is using for its accessibility test two tools:
Example 4.8.
Exemplary Compliance as a Software
assertor [download file for example 4.8].
<earl:Software rdf:about="http://example.org/excompliance/"> <dct:title xml:lang="en">Exemplary Compliance checker</dct:title> <dct:hasVersion>3.2</dct:hasVersion> <dct:description xml:lang="en">The compliance checker for Web Accessibility</dct:description> </earl:Software>
The selected tools test, among others, the following WCAG 2.0 techniques:
The Cool Tool checker provides the following report:
Example 4.9. Extract from the Cool Tool report [download file for example 4.9].
<earl:TestResult rdf:ID="result1"> <earl:pointer rdf:resource="#pointer1" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> <earl:TestResult rdf:ID="result2"> <earl:pointer rdf:resource="#pointer2" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#cantTell" /> </earl:TestResult> <ptr:LineCharPointer rdf:ID="pointer1"> <ptr:lineNumber>17</ptr:lineNumber> <ptr:charNumber>5</ptr:charNumber> <ptr:reference rdf:resource="http://example.org/resource/index.html" /> </ptr:LineCharPointer> <ptr:LineCharPointer rdf:ID="pointer2"> <ptr:lineNumber>20</ptr:lineNumber> <ptr:charNumber>5</ptr:charNumber> <ptr:reference rdf:resource="http://example.org/resource/index.html" /> </ptr:LineCharPointer>
In this section of the report, we can observe that the tool is able to identify correctly the error in the first image, but it is unable to discern whether the alternative attribute of the second image corresponds to its size. However, the Exemplary Compliance checker is able to download the image, check its size, and compare it to the content of the alternative attribute. This tool produces the following report:
Example 4.10. Extract from the Exemplary Compliance checker report [download file for example 4.10].
<earl:TestResult rdf:ID="result1"> <earl:pointer rdf:resource="#pointer1" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> <earl:TestResult rdf:ID="result2"> <earl:pointer rdf:resource="#pointer2" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> <ptr:LineCharPointer rdf:ID="pointer1"> <ptr:lineNumber>17</ptr:lineNumber> <ptr:charNumber>5</ptr:charNumber> <ptr:reference rdf:resource="http://example.org/resource/index.html" /> </ptr:LineCharPointer> <ptr:LineCharPointer rdf:ID="pointer2"> <ptr:lineNumber>20</ptr:lineNumber> <ptr:charNumber>5</ptr:charNumber> <ptr:reference rdf:resource="http://example.org/resource/index.html" /> </ptr:LineCharPointer>
Finally, our evaluator creates a new assertor group, which members include the evaluator and the two tools. The report that she delivers to her customer contains only the assertions that are final, substituting the undefined outcomes by those from the tool that is able to verify adequately the technique. Our evaluator can take decisions on this regard because the use of the EARL Pointers vocabulary allows her to compare exactly the location of the assertion.
Example 4.11. Extract from the final accessibility report [download file for example 4.11].
<foaf:Group rdf:ID="assertgroup"> <dct:title>John Doe and the W3C HTML Validator</dct:title> <earl:mainAssertor rdf:resource="http://example.org/persons/jdoe/" /> <foaf:member rdf:resource="http://example.org/excompliance/" /> <foaf:member rdf:resource="http://example.org/cooltool/" /> </foaf:Group> <foaf:Person rdf:about="http://example.org/persons/jdoe/"> <foaf:mbox rdf:resource="mailto:jane@example.org" /> <foaf:name>Jane Doe</foaf:name> </foaf:Person> <earl:Software rdf:about="http://example.org/cooltool/"> <dct:title xml:lang="en">Cool Tool accessibility checker</dct:title> <dct:hasVersion>1.0.c</dct:hasVersion> <dct:description xml:lang="en">A reliable compliance checker for Web Accessibility</dct:description> </earl:Software> <earl:Software rdf:about="http://example.org/excompliance/"> <dct:title xml:lang="en">Exemplary Compliance checker</dct:title> <dct:hasVersion>3.2</dct:hasVersion> <dct:description xml:lang="en">The compliance checker for Web Accessibility</dct:description> </earl:Software> <earl:TestCase rdf:about="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65"> <dct:description xml:lang="en">Failure due to omitting the alt attribute on img elements, area elements, and input elements of type image.</dct:description> <dct:title xml:lang="en">Failure of Success Criterion 1.1.1 from WCAG 2.0</dct:title> </earl:TestCase> <earl:TestCase rdf:about="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F30"> <dct:description xml:lang="en">Failure of Success Criterion 1.1.1 and 1.2.1 due to using text alternatives that are not alternatives.</dct:description> <dct:title xml:lang="en">Failure of Success Criterion 1.1.1 and 1.2.1 from WCAG 2.0</dct:title> </earl:TestCase> <earl:TestResult rdf:ID="result1"> <earl:pointer rdf:resource="#pointer1" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> <earl:TestResult rdf:ID="result2"> <earl:pointer rdf:resource="#pointer2" /> <earl:outcome rdf:resource="http://www.w3.org/ns/earl#failed" /> </earl:TestResult> <ptr:LineCharPointer rdf:ID="pointer1"> <ptr:lineNumber>17</ptr:lineNumber> <ptr:charNumber>5</ptr:charNumber> <ptr:reference rdf:resource="http://example.org/resource/index.html" /> </ptr:LineCharPointer> <ptr:LineCharPointer rdf:ID="pointer2"> <ptr:lineNumber>20</ptr:lineNumber> <ptr:charNumber>5</ptr:charNumber> <ptr:reference rdf:resource="http://example.org/resource/index.html" /> </ptr:LineCharPointer>
This example demonstrates how the use of simple Semantic Web technologies enables the combination of EARL assertions to produce improved and more accurate reports.
This section defines conformance requirements for software tools and processes, to ensure a consistent implementation and exchange of the EARL 1.0 vocabulary. The following applies to tools conforming with EARL 1.0:
Conforming EARL 1.0 reports are valid RDF graphs with:
earl:assertedBy
,
for each Assertion
dct:title
,
foaf:name
,
or doap:name
for each Assertordct:description
or doap:description
for each Assertorfoaf:nick
,
foaf:mbox
,
or foaf:homepage
for each Assertor that
is also of type foaf:Agent
foaf:member
,
for each Assertor that
is also of type foaf:Group
earl:mainAssertor
,
for each Assertor that
is also of type foaf:Group
earl:subject
,
for each Assertion
dct:title
,
foaf:name
,
or doap:name
for each Test
Subjectdct:description
or doap:description
for each Test
Subjectdct:date
, for each Test
Subjectdct:hasPart
or dct:isPartOf
,
between any instances of Test
Subjectearl:test
, for
each Assertion
dct:title
,
for each Test
Criteriondct:description
or doap:description
for each Test
Criteriondct:hasPart
or dct:isPartOf
,
between any instances of Test
Criterionearl:result
,
for each Assertion
dct:date
, for each Test
Resultearl:outcome
,
for each Test
Result
dct:title
, for each Outcome
Valuedct:description
, for each Outcome
Valuedct:title
,
for each Test
Resultdct:description
or doap:description
for each Test
Resultearl:info
for each Test
Resultearl:pointer
for
each Test
Resultearl:mode
, for
each Assertion
dct:title
,
for each Test
Modedct:description
,
for each Test
Modedoap:name
, for
each Softwarehttp:Response
cnt:Content
Note: subclasses or subproperties of terms share the same type. They are therefore considered to be equivalent entities in adhering to any of the above requirements. Also, instances in multiple languages of the same entity (such as title or description) are considered to be a single occurrence of the entity.
In addition, it is strongly recommended that EARL 1.0 reports are also valid RDF graphs with:
Conforming HTTP-in-RDF graphs are valid RDF graphs with:
http:connectionAuthority
,
for each Connectionhttp:requests
,
with any number of Request
instances, for each Connectionhttp:httpVersion
,
for each Messagehttp:headers
,
with any number of Message
Header instances, for each Messagehttp:body
,
for each Messagedct:date
, for
each Messagehttp:methodName
,
for each Requesthttp:requestURI
,
for each Requesthttp:mthd
,
for each Requesthttp:resp
,
for each Requesthttp:statusCodeValue
,
for each Responsehttp:reasonPhrase
,
for each Responsehttp:sc
, for
each Responsehttp:fieldName
,
for each Message
Headerhttp:fieldValue
,
for each Message
Headerhttp:hdrName
,
for each Message
Headerhttp:headerElements
,
with any number of Header
Element instances, for each Message
Headerhttp:elementName
,
for each Header
Elementhttp:elementValue
,
for each Header
Elementhttp:params
,
with any number of Parameter
instances, for each Header
Elementhttp:paramName
,
for each Parameterhttp:paramValue
,
for each ParameterConforming Content-in-RDF graphs are valid RDF graphs with:
cnt:characterEncoding
,
for each Contentdct:hasFormat
or
dct:isFormatOf
,
between any instances of Contentcnt:bytes
,
for each ContentAsBase64cnt:chars
,
for each ContentAsTextcnt:rest
,
for each ContentAsXMLcnt:leadingMisc
,
for each ContentAsXMLcnt:dtDecl
,
for each ContentAsXMLcnt:version
,
for each ContentAsXMLcnt:declaredEncoding
,
for each ContentAsXMLcnt:standalone
,
for each ContentAsXMLcnt:doctypeName
,
for each DoctypeDeclcnt:publicId
,
for each DoctypeDeclcnt:systemId
,
for each DoctypeDeclcnt:internalSubset
,
for each DoctypeDeclNote: this section will be added to refer the reader to best practices and existing references in RDF/XML serializations (possibly providing a DTD or XML Schema for EARL); RDF->JSON conversion (in particular if we do end up providing an XML Schema or DTD); binary RDF (work in progress at W3C); or other formats that may be useful to tool developers.
http://www.w3.org/TR/Content-in-RDF10/
http://dublincore.org/schemas/rdfs/
http://www.w3.org/TR/EARL10-Schema/
http://xmlns.com/foaf/spec/
http://www.w3.org/TR/HTTP-in-RDF10/
http://ieeexplore.ieee.org/servlet/opac?punumber=5976
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52142
http://www.niso.org/standards/z39-85-2007/
http://www.w3.org/TR/Pointers-in-RDF10/
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
http://www.w3.org/TR/rdf-primer/
http://www.w3.org/TR/rdf-schema/
http://www.w3.org/TR/rdf-syntax-grammar/
http://www.w3.org/DesignIssues/RDF-XML
http://www.ietf.org/rfc/rfc2119.txt
http://www.ietf.org/rfc/rfc5013.txt
http://www.w3.org/TR/owl-features/
http://www.w3.org/TR/WCAG10/
http://www.w3.org/TR/WCAG20/
http://www.w3.org/TR/REC-xml/
http://www.ietf.org/rfc/rfc3986.txt
Shadi Abou-Zahra, Carlos Iglesias, Michael A Squillace, Johannes Koch and Carlos A Velasco.
The following is a list of changes with respect to the previous internal version: