soa interfaces for the integrated prototypes · pdf file3.2.1.3 types ... table 5. schemas in...

Inclusive Future Internet Web Services

SOA interfaces for the integrated prototypes Deliverable D7.1 :: Public

Keywords: SOA, REST, interfaces, prototypes, imergo

SOA interfaces for the integrated prototypes I2Web project (Grant no.: 257623)

Version 2.0 of 41 © I2Web Consortium 2012

Table of Contents

Executive Summary .................................................................................................................... 5

1 Introduction ........................................................................................................................ 6

2 I2Web Architecture ............................................................................................................ 7

2.1 Delivery system............................................................................................................ 9

2.2 Authoring system ......................................................................................................... 9

2.3 Accessibility Expert Viewer .......................................................................................... 9

3 SOA interfaces .................................................................................................................. 11

3.1 Web Services ............................................................................................................. 11

3.1.1 The echo service ................................................................................................. 12

3.1.1.1 Requests ...................................................................................................... 12

3.1.1.2 Example Requests ....................................................................................... 12

3.1.1.3 Responses ................................................................................................... 12

3.1.2 The test service .................................................................................................. 13

3.1.2.1 Requests ...................................................................................................... 13

3.1.2.2 Example Requests ....................................................................................... 13

3.1.2.3 Responses ................................................................................................... 14

3.1.2.4 Example Responses ..................................................................................... 15

3.2 Schemas ..................................................................................................................... 16

3.2.1 The “test” schema .............................................................................................. 16

3.2.1.1 Namespaces ................................................................................................ 16

3.2.1.2 Relationship and Dependencies ................................................................. 17

3.2.1.3 Types ........................................................................................................... 17

3.2.2 The “public” schema .......................................................................................... 19

3.2.2.1 Namespaces ................................................................................................ 19

3.2.2.2 Relationship and Dependencies ................................................................. 20

3.2.2.3 Types ........................................................................................................... 20

4 Conclusions ....................................................................................................................... 26

5 Appendix........................................................................................................................... 27

5.1 XML Schemas ............................................................................................................. 27

5.1.1 Namespace “test” .............................................................................................. 27

5.1.2 Namespace “public” ........................................................................................... 29

5.2 JSON Schemas ............................................................................................................ 37

5.2.1 Namespace “test” .............................................................................................. 37

5.2.2 Namespace “public” ........................................................................................... 37



6 References ........................................................................................................................ 40

Appendix: List of abbreviations and acronyms ........................................................................ 41

List of Figures

Figure 1. I2Web delivery system. ............................................................................................... 7

Figure 2. I2Web authoring system. ............................................................................................ 8

Figure 3. I2Web complete architecture overview. .................................................................... 8

Figure 4. Accessibility Expert Viewer architectural components. ............................................ 10

Figure 5. The Web Evaluation API in context. .......................................................................... 11

Figure 6. Relationship and Dependencies of the test service. ................................................. 17

Figure 7. Overview of the test schema. ................................................................................... 18

Figure 8. Schema of type "test". .............................................................................................. 18

Figure 9. Schema of type "content". ........................................................................................ 19

Figure 10. Schema of type "testCriteria". ................................................................................ 19

Figure 11. Schema of type "testCriterion". .............................................................................. 19

Figure 12. Overview of the "public" schema. .......................................................................... 20

Figure 13. Schema of type "agent". ......................................................................................... 21

Figure 14. Schema of type "project". ....................................................................................... 21

Figure 15. Schema of type "projectConfiguration". ................................................................. 22

Figure 16. Schema of type "run". ............................................................................................. 22

Figure 17. Schema of type "reference". ................................................................................... 23

Figure 18. Schema of type "header". ....................................................................................... 23

Figure 19. Schema of type "headerContainer". ....................................................................... 23

Figure 20. Schema of type "httpPostReference". .................................................................... 24

Figure 21. Schema of type "httpReference". ........................................................................... 24

Figure 22. Schema of type "crawlerConfiguration". ................................................................ 25

List of Tables

Table 1. Request information for the "echo" service. ............................................................. 12

Table 2. Response information for the "echo" service. ........................................................... 12

Table 3. Request information for the "test" service. ............................................................... 13

Table 4. Response information for the "echo" service. ........................................................... 14

Table 5. Schemas in the “test” namespace. ............................................................................. 16

Table 6. Imported schemas. ..................................................................................................... 17

Table 7. Schemas in the “public” namespace .......................................................................... 20



Contractual Date of Delivery to the EC: 31st July 2011 + 60 days

Actual Date of Delivery to the EC: 26th September 2011, Revised 13th April 2012

Editors: Carlos A Velasco (FhG/FIT), Philip Ackermann (FhG/FIT), Evangelos Vlachogiannis (FhG/FIT)

Contributors: I2Web Consortium

DOCUMENT HISTORY

Version Version date Responsible Description

0.1 07/04/2011 TXT Initial Table of Contents

0.9 29/06/2011 FIT Draft proposal of interfaces

1.0 31/07/2011 FIT Final version of interfaces

2.0 13/04/2012 FIT Updated version of interfaces

The information and views set out in this publication are those of the author(s) and do not necessarily reflect the official opinion of the European Communities. Neither the European Union institutions and bodies nor any person acting on their behalf may be held responsible for the use which may be made of the information contained therein.

Copyright © 2011—2012 I2Web Consortium.

Permission is granted to copy, distribute and/or modify this document text and its contained artworks under the Creative Commons Attribution License 3.0 as described at http://creativecommons.org/licenses/by/3.0.

http://creativecommons.org/licenses/by/3.0



Executive Summary

This document is the first deliverable from Task T7.1. It is intended to be an accompanying document to the common SOA interfaces. The main issue for these prototypes is to enable the communication with the evaluation tool imergo® and the accessibility expert viewer component to be developed in WP6. To better understand the meaning of these interfaces, Section 2 presents an overview of the I2Web architecture. These interfaces have reached at this stage a high degree of stability.

This version contains a major review of the interfaces, incorporating the feedback of the implementation efforts of the project in the previous months. Furthermore, we have initiated conversations with W3C representatives to standardise these interfaces to enable interoperability between different compliance testing services.



1 Introduction

The I2Web project is constituted of several modules, described in Section 2. On account of the interoperability of these components and their interaction with the different web applications, the consortium has opted to use a set of REST-based interfaces (Fielding, 2000). The deliverable presents an overview of these interfaces. To facilitate the understanding of these interfaces, we provide in the following section a rough overview of the I2Web architecture.



2 I2Web Architecture

The architecture of the system has two main components:

Delivery system: this is the part delivering content and applications from the partners’ components to the end users. This is represented in Figure 1.

Authoring system: this is the part of the architecture that integrates the evaluation tools and the results of the Accessibility Expert Viewer in the authoring environments of the partners. This is represented in Figure 2.

Figure 1. I2Web delivery system.

There is a third component mentioned already, the Accessibility Expert Viewer, which could act as a post-evaluation tool, where the delivered web content and applications are examined by experts, or as a design tool, where developers in the different IDEs or CMSs evaluate their applications and correct their accessibility errors (see Figure 2).



Figure 2. I2Web authoring system.

All components of the architecture interact with each other as depicted in Figure 3.

Figure 3. I2Web complete architecture overview.



2.1 Delivery system

This is the part of the architecture delivering content and applications from the partners’ components to the end users. In this system, the modelling infrastructure plays a key role because to function efficiently, I2Web needs to gather in real-time information about users, devices, user agents and applications.

User and device modelling User and device models are closely linked. User characteristics and preferences have a clear influence in modifying the device profiles, and therefore they should be implemented using the same technology, like CC/PP as described in the corresponding deliverable.

Application modelling The application models are decoupled from the previous ones. They respond to their structure to be able to react to their needs. The deliverable D5.1 discusses all implementation possibilities, but the Consortium decided to use models based upon Semantic Web technologies like WAI-ARIA,1 which are going to be extended.

Modelling proxy This is the component collecting and processing modelling information. It may be divided in a local and a remote component.

2.2 Authoring system

This is the part of the architecture that integrates the evaluation tools and the results of the Accessibility Expert Viewer in the authoring environments of the partners. As seen in Figure 2, the components to be designed are the communication plugin with the evaluation tool and the interfaces with the application modelling.

The former are based upon SOA-based interfaces, preferably following a REST architecture. Standards to be followed are:2

Content in RDF

HTTP in RDF

Pointers in RDF

Evaluation and Report Language (EARL)

2.3 Accessibility Expert Viewer

The functionality of the foreseen Accessibility Expert Viewer covers aspects like:

Support for manual accessibility tests. The tool will present to the expert the tests that need to be done, after pre-processing, i.e., excluding not applicable tests and highlighting the content areas to be tested.

Support in the decision process to check whether a test passes or fails.

Storage and merging of results with those of the automatic testing in the given resource.

1 http://www.w3.org/TR/wai-aria/

2 See an overview of these standards in http://www.w3.org/WAI/intro/earl.

http://www.w3.org/TR/wai-aria/

http://www.w3.org/WAI/intro/earl



Pre-selection of sample test pages by applying a random process or selecting the Core Resource List of the Unified Web Evaluation Methodology (UWEM3, version 1.2).

Provision of statistical analysis of the site and aggregation of reports targeted to different audiences.

From a components perspective, this can be represented like in Figure 4.

Figure 4. Accessibility Expert Viewer architectural components.

3 http://www.wabcluster.org/uwem1_2/

http://www.wabcluster.org/uwem1_2/



3 SOA interfaces

All the components described here are Open Source with an Apache-like software license. The corresponding license is linked from every online document.

3.1 Web Services

This section describes the API of the web services that are available and that are used by the Accessibility Expert Viewer Software (i.e., the Web Compliance API). As mentioned earlier, our intention is to standardise these interfaces, thus any compliance application that implements them could be used by the Accessibility Expert Viewer. For the I2Web project two service interfaces have been implemented. It should be emphasized, that the Accessibility Expert Viewer solely depends on the API so that the concrete implementation can be exchanged at any time. The following diagram visualizes this dependencies and relations.

Figure 5. The Web Evaluation API in context.

Currently the API defines two services. The echo service is a test service where the input is echoed to the client. The test service represents the real evaluation service and serves as communication channel between the Accessibility Expert Viewer or other authoring environments and for example imergo®.

Both services support two request formats as input: XML (with application/xml or text/xml mime types) and JSON (mime type: application/json). The test service allows the evaluation of an online web resource (HTML, images, PDF, etc.) identified by a HTTP reference and the evaluation of a serialized web resource that is sent within the request.

The response of the test service is an evaluation report in EARL (Evaluation and Report Language) format (Abou-Zahra, S., 2011) represented as RDF (mime type: application/rdf+xml). EARL is a language for describing evaluation and test results. Those test results contain different information like for example



who performed the test(s) (e.g., person, software application)

what was tested (i.e., the test subject, e.g., a website or an authoring tool)

what test(s) were performed (e.g., accessibility guidelines or quality assurance requirements)

3.1.1 The echo service

This service sends the content of the request back to the client.

3.1.1.1 Requests

URL http://imergo.com/service/api/echo

Supported request formats

application/json

application/xml

text/xml

Supported request methods POST

Table 1. Request information for the "echo" service.

3.1.1.2 Example Requests

<?xml version = "1.0" encoding = "UTF-8"?>

<test:test xmlns="http://imergo.com/ns/3.0/test/"

xmlns:public="http://imergo.com/ns/3.0/public/"

xmlns:test="http://imergo.com/ns/3.0/test/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

test:ruleSet="http://www.w3.org/TR/WCAG20/">

<public:httpReference public:method="GET"

public:uri="http://www.google.com"

xmlns:public="http://imergo.com/ns/3.0/public/">

</public:httpReference>

<test:testCriteria>

<test:testCriterion>http://imergo.com/ns/tests/F30.rdf</test:testCriterion>

</test:testCriteria>

</test:test>

Example 1. A simple example for a request in XML format.

{

"httpReference": {

"uri" : "http://www.google.com",

"method" : "GET",

}

}

Example 2. A simple example for a request in JSON format.

3.1.1.3 Responses

Depending on the request that was sent, the response is either in XML or JSON format.

Supported response formats (request dependent)

application/json

application/xml

Table 2. Response information for the "echo" service.



3.1.2 The test service

This service performs a test according to the information inside the request. The root element of a request is of type test, which has the following child elements:

httpReference (required): This identifies the web resource that should be tested. A HTTP reference consist of an URI, an HTTP method (e.g., GET, POST) and optionally a list of headers.

content (optional): If no content is provided within the request the content is fetched based on the given HTTP reference. If on the other hand, content is provided, then this content is evaluated.

crawlerConfiguration (optional): This configuration contains information about the crawler like the crawler depth and the maximum number of web resources to be fetched.

testCriteria (required): This defines the criteria that should be tested. It is basically a list of URIs that identify them.

Further information on the namespaces that are used can be found in the documentation of the test and the public schemas (see section 3.2). In summary there are the following use cases:

Validate a single web resource by specifying httpReference and testCriteria

Validate a serialized web resource by specifying httpReference, content (with

binary web resource) and testCriteria

Validate a snippet of HTML by specifying httpReference, content (with binary

HTML) and testCriteria

Validate a web site by specifying httpReference, testCriteria and

crawlerConfiguration (with appropriate crawler settings)

Validate a part of a web site by specifying httpReference, testCriteria and

crawlerConfiguration (with appropriate crawler settings)

3.1.2.1 Requests

URL http://imergo.com/service/api/test

Supported request formats

application/json

application/xml

text/xml

Supported request methods POST

Table 3. Request information for the "test" service.

3.1.2.2 Example Requests

The following example shows a request for the “test” service that contains a HTTP reference and a list of four test criteria. No content that should be tested is sent within the request and no crawler settings are provided.

<?xml version = "1.0" encoding = "UTF-8"?>

<test:test xmlns="http://imergo.com/ns/3.0/test/"




xmlns:test="http://imergo.com/ns/3.0/test/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

test:ruleSet="http://www.w3.org/TR/WCAG20/">

<public:httpReference public:method="GET"

public:uri="http://www.google.com"

xmlns:public="http://imergo.com/ns/3.0/public/">

<public:headerContainer>

<public:header public:name="User-Agent" public:value="Mozilla/5.0" />

<public:header public:name="Connection" public:value="Keep-Alive" />

<public:header public:name="Accept"

public:value="text/html,application/xhtml+xml,application/xml" />

<public:header public:name="Accept-Charset"

public:value="ISO-8859-1,utf-8" />

<public:header public:name="Accept-Encoding"

public:value="gzip, deflate" />

</public:headerContainer>

</public:httpReference>

<test:testCriteria>





</test:testCriteria>

</test:test>

Example 3. Example of a request for the “test” service in XML format.

The following example is the JSON equivalent to the XML request from the previous example.

{"httpReference": {

"uri" : "http://www.google.com",

"method" : "GET",

"headerContainer": {

"header": [

{

"name":"User-Agent",

"value":"Mozilla/5.0"},

{

"name":"Connection",

"value":"Keep-Alive"},

{

"name":"Accept",

"value":"text/html,application/xhtml+xml,application/xml"},

{

"name":"Accept-Charset",

"value":"ISO-8859-1,utf-8"},

{

"name":"Accept-Encoding",

"value":"gzip, deflate"

}

]

}

},

"testCriteria": {

"testCriterion": [

{"id":"http://imergo.com/ns/tests/F27.rdf"},



{"id":"http://imergo.com/ns/tests/F30.rdf"}

] }

}

Example 4. Example of a request for the “test” service in JSON format.

3.1.2.3 Responses

Supported response formats (request dependent)

application/rdf+xml

Table 4. Response information for the "echo" service.

The response of the test service is an EARL report described in RDF. Basically the report contains assertions (earl:Assertion), which describe who performed the test (earl:assertedBy), what was tested (earl:subject), which test was performed (earl:test) and what was the result of the test (earl:result). Detailed information about the location of errors or warnings is expressed using the Pointer-in-RDF 1.04 ontology. Detailed information about the HTTP request and the HTTP response (e.g., header information, status code) are described using the HTTP-in-RDF 1.05 ontology.

3.1.2.4 Example Responses

<?xml version="1.0" encoding='UTF-8'?>

<rdf:RDF xml:base=""

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:earl="http://www.w3.org/ns/earl#"

xmlns:foaf="http://xmlns.com/foaf/0.1/#"

xmlns:doap="http://usefulinc.com/ns/doap#"

xmlns:dc="http://purl.org/dc/terms/"

xmlns:pnt="http://www.w3.org/2009/pointers#">



<earl:Software rdf:about="http://www.example.org/tools/#cooltool">

<doap:name xml:lang="en">Cool Tool</doap:name>

<doap:description xml:lang="en">

Accessibility evaluation tool

</doap:description>

<doap:created>2011-11-27</doap:created>

<doap:homepage rdf:resource="http://example.org/tools/cool/" />

<doap:release>

<doap:revision>1.0.4</doap:revision>

</doap:release>

</earl:Software>



<earl:Assertion rdf:about="#assertion_F30">

<earl:assertedBy rdf:resource="http://www.example.org/tool/#cooltool" />

<earl:subject rdf:resource="http://www.example.org/" />

<earl:test

rdf:resource="http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/F30.html" />

<earl:result rdf:resource="#result_F30" />

</earl:Assertion>

<earl:TestResult rdf:about="#result_F30">

<dc:title>No meaningful alternative text for non text element

</dc:title>

<dc:description rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

No meaningful alternative text for non-text element.

</dc:description>

<dc:date>2011-11-30</dc:date>

<earl:outcome rdf:resource="http://www.w3.org/ns/earl#cantTell" />

<earl:pointer rdf:resource="#pointer_result_F30" />

</earl:TestResult>



<pnt:EquivalentPointers rdf:about="#pointer_result_F30">

<pnt:groupPointer rdf:resource="#pointer_result_F30" />

<pnt:groupPointer rdf:resource="#linechar_pointer_result_F30" />

<pnt:groupPointer rdf:resource="#charoffset_pointer_result_F30" />

</pnt:EquivalentPointers>

<pnt:XPathPointer rdf:about="#xpath_pointer_result_F30">

<pnt:expression rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

/pfx0:html[1]/pfx0:body[1]/pfx0:div[1]/pfx0:p[1]/pfx0:img[1]

</pnt:expression>

<pnt:namespace>

<pnt:XMLNamespace>

4 http://www.w3.org/TR/Pointers-in-RDF10/

5 http://www.w3.org/TR/HTTP-in-RDF10/

http://www.w3.org/TR/Pointers-in-RDF10/

http://www.w3.org/TR/HTTP-in-RDF10/



<pnt:namespaceName

rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

http://www.w3.org/1999/xhtml

</pnt:namespaceName>

<pnt:prefix

rdf:datatype="http://www.w3.org/2001/XMLSchema#string">

pfx0

</pnt:prefix>

</pnt:XMLNamespace>

</pnt:namespace>

</pnt:XPathPointer>

<pnt:LineCharPointer rdf:about="#linechar_pointer_result_F30">

<pnt:charNumber

rdf:datatype="http://www.w3.org/2001/XMLSchema#positiveInteger">

131

</pnt:charNumber>

<pnt:lineNumber

rdf:datatype="http://www.w3.org/2001/XMLSchema#positiveInteger">

83

</pnt:lineNumber>

</pnt:LineCharPointer>

<pnt:CharOffsetPointer rdf:about="#charoffset_pointer_result_F30">

<pnt:offset rdf:datatype="http://www.w3.org/2001/XMLSchema#positiveInteger">

2126

</pnt:offset>

</pnt:CharOffsetPointer>

</rdf:RDF>

Example 5. An example for a response of the validation serivce in EARL format.

3.2 Schemas

3.2.1 The “test” schema

3.2.1.1 Namespaces

Table 5 presents the schemas that are used in the test namespace, Table 6 gives an overview about the imported namespaces.

Namespace prefix

Namespace URI Description Schemas

test http://imergo.com/ns

/3.0/test/ Namespace for representing requests for evaluation.6

test.xsd

content.xsd

testCriteria.xsd

testCriterion.xsd

Table 5. Schemas in the “test” namespace.

Namespace prefix


public http://imergo.com/ns

/3.0/public/ Namespace for representing the

agent.xsd

project.xsd

6 A complete documentation can be found under http://imergo.com/ns/3.0/test/html/index.html

http://imergo.com/ns/3.0/test/html/index.html#type-test

http://imergo.com/ns/3.0/test/html/index.html#type-content

http://imergo.com/ns/3.0/test/html/index.html#type-testCriteria

http://imergo.com/ns/3.0/test/html/index.html#type-testCriterion

http://imergo.com/ns/3.0/public/html/index.html#type-agent

http://imergo.com/ns/3.0/public/html/index.html#type-project

http://imergo.com/ns/3.0/test/html/index.html



Namespace prefix


imergo® public objects.7

projectConfiguration.xsd

crawlerConfiguration.xsd

run.xsd

reference.xsd

header.xsd

headerContainer.xsd

httpPostReference.xsd

httpReference.xsd

Table 6. Imported schemas.

3.2.1.2 Relationship and Dependencies

The following figure shows the relationship and dependencies of all the schema files that are used by the test web service.

Figure 6. Relationship and Dependencies of the test service.

3.2.1.3 Types

This section describes the types defined by this schema. Not that some data types that are

used in this schema are part of the public schema, which data types are not repeated here and which is described in detail in the next chapter.

test: this includes information about a web compliance test that should be performed.

content: this specifies the content that should be tested.

testCriteria: this defines the criteria that should be tested.

7 A complete documentation can be found under http://imergo.com/ns/3.0/public/html/index.html

http://imergo.com/ns/3.0/public/html/index.html#type-projectConfiguration

http://imergo.com/ns/3.0/public/html/index.html#type-crawlerConfiguration

http://imergo.com/ns/3.0/public/html/index.html#type-run

http://imergo.com/ns/3.0/public/html/index.html#type-reference

http://imergo.com/ns/3.0/public/html/index.html#type-header

http://imergo.com/ns/3.0/public/html/index.html#type-headerContainer

http://imergo.com/ns/3.0/public/html/index.html#type-httpPostReference

http://imergo.com/ns/3.0/public/html/index.html#type-httpReference

http://imergo.com/ns/3.0/public/html/index.html




testCriterion: this specifies a single the criterion.

Figure 7. Overview of the test schema.

Type test

Figure 8. Schema of type "test".

A request for testing a web resource. It contains an HTTP reference to that web resource and optionally the encoded content of the web resource. If only the HTTP reference is provided the content is fetched from that reference. Note that even if the content is provided in the request there MUST be a HTTP reference that identifies the web resource to be tested. Additionally the test criteria have to be specified. This is basically a list of URIs that identify the tests. Optionally crawler settings like crawler depth and maximum number of objects to be crawled can be set.

Properties



public:httpReference

test:content

test:testCriteria

public:crawlerConfiguration

Type content

Figure 9. Schema of type "content".

The content element represents the serialized content of a web resource. The type of that web resource is defined by the contentType property, i.e., the MIME-type, the encoding is defined by the encoding property. Both properties are mandatory to ensure the correct deserialization of that web resource by processing services.

Type testCriteria

Figure 10. Schema of type "testCriteria".

A container for the test criteria to allow evaluation of a web resource against different tests.

Type testCriterion

Figure 11. Schema of type "testCriterion".

A test criterion identified by an URI.

3.2.2 The “public” schema

3.2.2.1 Namespaces

Table 7 presents the schemas that are used in the public namespace.

Namespace

prefix

Namespace URI Description Elements

public http://imergo.co

m/ns/3.0/public/ Namespace for representing the

agent.xsd

project.xsd


http://imergo.com/ns/3.0/test/html/index.html#type-content

http://imergo.com/ns/3.0/test/html/index.html#type-testCriteria


http://imergo.com/ns/3.0/public/html/index.html#type-agent

http://imergo.com/ns/3.0/public/html/index.html#type-project



Namespace

prefix

Namespace URI Description Elements

imergo® public objects.8

projectConfiguration.xsd

run.xsd

reference.xsd

header.xsd

headerContainer.xsd

httpPostReference.xsd

httpReference.xsd

crawlerConfiguration.xsd

Table 7. Schemas in the “public” namespace

3.2.2.2 Relationship and Dependencies

The following figure gives an overview on how the schemas relates to each other.

Figure 12. Overview of the "public" schema.

3.2.2.3 Types

This section describes the types defined by this schema.

agent: This includes information about an agent. Agents can be for example single users or companies.

project: This is a workspace for an agent.

projectConfiguration: A project can have one of more configurations for running evaluations and managing the results.

run: For each project configuration the agent can execute multiple evaluation runs.

reference: This specifies a single reference.

header: This specifies a single header.

headerContainer: This specifies bunch of headers.

httpPostReference: This specifies a single HTTP POST reference.

httpReference: This specifies a single HTTP Reference.

crawlerConfiguration: This specifies a single crawlerConfiguration.

8 A complete documentation can be found under http://imergo.com/ns/3.0/public/html/index.html

http://imergo.com/ns/3.0/public/html/index.html#type-projectConfiguration

http://imergo.com/ns/3.0/public/html/index.html#type-run

http://imergo.com/ns/3.0/public/html/index.html#type-reference

http://imergo.com/ns/3.0/public/html/index.html#type-header

http://imergo.com/ns/3.0/public/html/index.html#type-headerContainer

http://imergo.com/ns/3.0/public/html/index.html#type-httpPostReference






Type agent

Figure 13. Schema of type "agent".

An agent can be a user, a company, an organization or whatever other party interesting in doing evaluation. It contains login name, password, email address and a list of projects an agent can be member of.

Properties

public:loginName

public:password

public:email

public:projects

Type project

Figure 14. Schema of type "project".

The workspace for working with the evaluation tool. This consists of the name of the project and a list of project configurations with an attribute that indicates the unique active one.

Properties

public:name

public:projectConfigurations



Type projectConfiguration

Figure 15. Schema of type "projectConfiguration".

A configuration allows a project to handle multiple sites under specific parameters and store all related data for testing and reporting. A project configuration contains a combination of start reference, run parameters, runs and results under such parameters. An agent can create several project configurations under a project and activate one each time.

Properties

public:name

public:startReference

public:headerContainer

public:credentials

public:handlingCookies

public:referenceContainer

public:locale

public:period

public:crawler

Type run

Figure 16. Schema of type "run".

A run is initiated whenever an agent execute an evaluation based on a specific project configuration. It

consists of the exact time and date of the evaluation execution and also a container with all the results

(EARL report) this will come up with.



Properties

public:timeDateStamp

public:resultContainer

Type reference

Figure 17. Schema of type "reference".

A reference is a way to uniquely identify a resource. This contains only the URI of the reference.

Properties

public:uri

Type header

Figure 18. Schema of type "header".

An HTTP header with pairs of names and values used for requests and responses.

Properties

public:name

public:value

Type headerContainer

Figure 19. Schema of type "headerContainer".

A container for the HTTP headers. This contains a list of header elements.

Properties

public:header



Type httpPostReference

Figure 20. Schema of type "httpPostReference".

A HTTP POST reference. This contains the data sent through HTTP POST similar to the way an HTML form is filled and posted to the server. This also contains the URI to which the data are sent, the method used and the header container element.

Properties

public:uri

public:method


public:urlEncodedFormHttpEntity

Type httpReference

Figure 21. Schema of type "httpReference".

A HTTP reference.This contains the data sent through HTTP. This contains the URI to which the data are sent, the method used and the header container element.

Properties

public:uri

public:method




Type crawlerConfiguration

Figure 22. Schema of type "crawlerConfiguration".

Crawler specific configuration. This defines the maximum crawling depth and the maximum number of objects to be fetched.

Properties

public:maxDepth

public:maxNumberOfObjects




4 Conclusions

We have presented in the document an overview of the different interfaces that constitute this prototype. The interfaces are REST-based (Fielding, 2000), which facilitates interoperability and scalability of the different components as defined in the architectural overview section. The interfaces have been tested and improved with different configurations of the partners and proved to be effective.

As mentioned earlier, we have initiated conversations with W3C representatives to standardise these interfaces to enable interoperability between different compliance testing services.



5 Appendix

5.1 XML Schemas

5.1.1 Namespace “test”

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://imergo.com/ns/3.0/test/"


targetNamespace="http://imergo.com/ns/3.0/test/"

elementFormDefault="qualified">

<xsd:import namespace="http://imergo.com/ns/3.0/public/"

schemaLocation="http://imergo.com/ns/3.0/public/httpReference.xsd" />

<xsd:import namespace="http://imergo.com/ns/3.0/public/"

schemaLocation="http://imergo.com/ns/3.0/public/crawlerConfiguration.xsd" />

<xsd:include schemaLocation="http://imergo.com/ns/3.0/test/content.xsd" />

<xsd:include schemaLocation="http://imergo.com/ns/3.0/test/testCriteria.xsd" />

<xsd:element name="httpReference" type="public:httpReference" />

<xsd:element name="crawlerConfiguration" type="public:crawlerConfiguration" />

<xsd:element name="testCriteria" type="testCriteria" />

<xsd:element name="content" type="content" />

<xsd:complexType name="test">

<xsd:annotation>

<xsd:documentation>

A request for testing a web resource. It contains an HTTP reference

to that web resource and optionally the content of the web resource

encoded as base64 binary. If only the HTTP reference is provided the

content is fetched from that reference. Note that even if the

content is provided in the request there MUST be an HTTP reference

that identifies the web resource to be tested, although it can be a

randomly generated one. Additionally the test criteria have to be

specified. This is basically a list of URIs that identify the tests.

</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element ref="httpReference" minOccurs="1" maxOccurs="1" />

<xsd:sequence>

<xsd:element ref="content" minOccurs="0" maxOccurs="1" />

</xsd:sequence>

<xsd:element ref="testCriteria" minOccurs="1" maxOccurs="1" />

<xsd:element ref="crawlerConfiguration" minOccurs="0"

maxOccurs="1" />

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

Listing 1. test.xsd






<xsd:complexType name="content">

<xsd:annotation>

<xsd:documentation>

The content encoded as base64 binary.


</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="xsd:base64Binary">

<xsd:attribute name="encoding" type="xsd:string" />

<xsd:attribute name="contentType" type="xsd:string" />

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:schema>

Listing 2. content.xsd







<xsd:include schemaLocation="http://imergo.com/ns/3.0/test/testCriterion.xsd" />

<xsd:element name="testCriterion" type="testCriterion" />

<xsd:complexType name="testCriteria">

<xsd:annotation>

<xsd:documentation xml:lang="en">

A container for the test criteria. A test criterion is identified by

an URI.


</xsd:annotation>

<xsd:sequence>

<xsd:element ref="testCriterion" minOccurs="0" maxOccurs="unbounded">

<xsd:annotation>

<xsd:documentation xml:lang="en">A test criterion.


</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

Listing 3. testCriteria.xsd


xmlns="http://imergo.com/ns/3.0/test/" elementFormDefault="qualified"

targetNamespace="http://imergo.com/ns/3.0/test/">

<xsd:complexType name="testCriterion">

<xsd:annotation>


A test criterion identified by an URI.


</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="xsd:string"></xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:schema>

Listing 4. testCriterion.xsd



5.1.2 Namespace “public”


xmlns="http://imergo.com/ns/3.0/public/"

targetNamespace="http://imergo.com/ns/3.0/public/"


<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/project.xsd" />

<xsd:element name="agent">

<xsd:annotation>

<xsd:documentation>

Comment describing your root element


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="loginName" type="xsd:string"

maxOccurs="1" minOccurs="1">

<xsd:annotation>

<xsd:documentation>

The agent's login ID for logging in to a

project


</xsd:annotation>

</xsd:element>

<xsd:element name="password" type="xsd:string"

maxOccurs="1" minOccurs="1">

<xsd:annotation>

<xsd:documentation>

The agent's password for logging in to a

project</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="email" type="xsd:string" maxOccurs="1"

minOccurs="1">

<xsd:annotation>

<xsd:documentation>

The agent's email for admin to contact.


</xsd:annotation>

</xsd:element>

<xsd:element name="projects" maxOccurs="1" minOccurs="0">

<xsd:annotation>

<xsd:documentation>

The projects an agent owns


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="project"

maxOccurs="unbounded" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Listing 5. agent.xsd







<xsd:include schemaLocation="projectConfiguration.xsd" />

<xsd:element name="project">

<xsd:annotation>

<xsd:documentation>

This is a project workspace for imergo. A project can be owned my one

or more agents. It has one or more configurations. One of these can be

active each time a new run is to be started. The project is

identified by a unique name.


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="name" type="xsd:ID" />

<xsd:element name="projectConfigurations">

<xsd:annotation>

<xsd:documentation>

Available project configurations


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="projectConfiguration" />

</xsd:sequence>

<xsd:attribute name="activeId" type="xsd:IDREF" />

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Listing 6. project.xsd





<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/reference.xsd" />

<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/referenceContainer.xsd"

/>

<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/headerContainer.xsd" />

<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/crawlerConfiguration.xsd"

/>

<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/run.xsd" />

<xsd:element name="projectConfiguration">

<xsd:annotation>

<xsd:documentation>

A configuration allow a project to handle multiple sites under

specific parameters and store all related data for testing and

reporting. A project configuration contains a combination of start

reference, run parameters, runs and results under such parameters .

An agent can create several project configurations under a project

and activate one each time.


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="name" type="xsd:ID" nillable="false" />

<xsd:element name="startReference" type="reference"

minOccurs="1" maxOccurs="1">

<xsd:annotation>

<xsd:documentation>

This is the starting URL of the project - where

the crawler to start. This is also the id of the

project configuration and unique under a

project.


</xsd:annotation>

</xsd:element>



<xsd:element name="headerContainer" type="headerContainer"

minOccurs="0" maxOccurs="1" />

<xsd:element name="credentials" minOccurs="0" maxOccurs="1">

<xsd:annotation>

<xsd:documentation>

A map of credentials the crawler might use to

access resources


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="username"

type="xsd:string" />

<xsd:element name="password"

type="xsd:string" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="handlingCookies" type="xsd:boolean"


<xsd:element name="runs" minOccurs="0" maxOccurs="1">

<xsd:annotation>

<xsd:documentation>

Under a certain configuration there might be one

of more runs. In practice this means that an

agent can select a web site with certain

parameters and run evaluations periodically.


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="run"

maxOccurs="unbounded"

minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element ref="referenceContainer" minOccurs="0"

maxOccurs="1" />

<xsd:element name="crawlerConfiguration"

type="crawlerConfiguration"


<xsd:element name="locale" type="xsd:language"


<xsd:element name="period" type="xsd:int" default="0"

minOccurs="0" maxOccurs="1">

<xsd:annotation>

<xsd:documentation>

For scheduling evaluations in hours


</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Listing 7. projectConfiguration.xsd







<xsd:element name="run">

<xsd:annotation>

<xsd:documentation>

A container of an EARL report with evaluation results


</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element name="id" type="xsd:ID" />

<xsd:element name="timeDateStamp" type="xsd:dateTime" />

<xsd:element name="resultContainer" type="xsd:anySimpleType">

<xsd:annotation>

<xsd:documentation>

This contains an EARL report


</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Listing 8. run.xsd





<xsd:complexType name="reference">

<xsd:annotation>


A reference is a way to uniquely identify a resource.


</xsd:annotation>

<xsd:attribute name="uri" type="xsd:anyURI" use="required">

<xsd:annotation>


The uniform resource identifier (URI). URI provide a simple

and extensible means for identifying a resource. (see

http://www.ietf.org/rfc/rfc2396.txt) of the reference.


</xsd:annotation>

</xsd:attribute>

</xsd:complexType>

</xsd:schema>

Listing 9. reference.xsd







<xsd:complexType name="header">

<xsd:annotation>


An HTTP header with pairs of names and values used for requests

and responses.


</xsd:annotation>

<xsd:attribute name="name" type="xsd:string" use="required">

<xsd:annotation>


The name of the HTTP header.


</xsd:annotation>

</xsd:attribute>

<xsd:attribute name="value" type="xsd:string">

<xsd:annotation>


The value of the HTTP header.


</xsd:annotation>

</xsd:attribute>

</xsd:complexType>

</xsd:schema>

Listing 10. header.xsd





<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/header.xsd" />

<xsd:complexType name="headerContainer">

<xsd:annotation>


A container for the HTTP headers.


</xsd:annotation>

<xsd:sequence>

<xsd:element name="header" type="header" minOccurs="0"

maxOccurs="unbounded">

<xsd:annotation>


A HTTP header.


</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

Listing 11. headerContainer.xsd







<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/httpReference.xsd" />

<xsd:element name="urlEncodedFormHttpEntity" type="urlEncodedFormHttpEntity" />

<xsd:element name="parameters" type="nameValuePairList" />

<xsd:element name="parameter" type="nameValuePair" />

<xsd:attribute name="name" type="xsd:string" />

<xsd:attribute name="value" type="xsd:string" />

<xsd:attribute name="encoding" type="xsd:string" />

<xsd:complexType name="httpPostReference">

<xsd:annotation>


A HTTP POST reference.


</xsd:annotation>

<xsd:complexContent>

<xsd:extension base="httpReference">

<xsd:sequence>

<xsd:element ref="urlEncodedFormHttpEntity"

minOccurs="0">

<xsd:annotation>

<xsd:documentation>

This contains the data sent through HTTP

POST similar to the way an HTML form is

filled and posted to the server.


</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="urlEncodedFormHttpEntity">

<xsd:sequence>

<xsd:element ref="parameters" minOccurs="0">

<xsd:annotation>

<xsd:documentation>

The parameters in pairs of name and value sent to the

server side


</xsd:annotation>

</xsd:element>

</xsd:sequence>

<xsd:attribute ref="encoding">

<xsd:annotation>

<xsd:documentation>The text encoding of the content


</xsd:annotation>

</xsd:attribute>

</xsd:complexType>

<xsd:complexType name="nameValuePairList">

<xsd:sequence>

<xsd:element ref="parameter" minOccurs="0" maxOccurs="unbounded" />

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="nameValuePair">

<xsd:attribute ref="name">

<xsd:annotation>

<xsd:documentation>The name of the parameter


</xsd:annotation>

</xsd:attribute>

<xsd:attribute ref="value">

<xsd:annotation>

<xsd:documentation>The value of the parameter


</xsd:annotation>

</xsd:attribute>

</xsd:complexType>

</xsd:schema>

Listing 12. httpPostReference.xsd







<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/reference.xsd" />

<xsd:include schemaLocation="http://imergo.com/ns/3.0/public/headerContainer.xsd" />

<xsd:element name="headerContainer" type="headerContainer">

<xsd:annotation>

<xsd:documentation>

A container with header (context) information for a request or

response.


</xsd:annotation>

</xsd:element>

<xsd:simpleType name="httpMethod">

<xsd:annotation>

<xsd:documentation>

This declares the method of the HTTP protocol is going to be used. It

can be GET, POST or HEAD depending on the purpose of the request.

These methods are defined and well documented in the HTTP protocol

specification (see

http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.1).


</xsd:annotation>

<xsd:restriction base="xsd:string">

<xsd:enumeration value="GET" />

<xsd:enumeration value="HEAD" />

<xsd:enumeration value="POST" />

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="httpReference">

<xsd:annotation>


A reference using HTTP.It extends reference and can contain headers

(grouped in a header container) and one of the HTTP methods. If no

HTTP method is given then the GET method is used.


</xsd:annotation>

<xsd:complexContent>

<xsd:extension base="reference">

<xsd:sequence>

<xsd:element ref="headerContainer" minOccurs="0"

maxOccurs="1">

<xsd:annotation>

<xsd:documentation>

A container with header (context)

information for a request or response.


</xsd:annotation>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="method" type="httpMethod">

<xsd:annotation>


The HTTP method.


</xsd:annotation>

</xsd:attribute>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:schema>

Listing 13. httpReference.xsd







<xsd:element name="crawlerConfiguration" type="crawlerConfiguration" />

<xsd:complexType name="crawlerConfiguration">

<xsd:annotation>

<xsd:documentation>

A configuration which contains crawler specific settings.


</xsd:annotation>

<xsd:sequence>

<xsd:element name="maxDepth" type="xsd:int">

<xsd:annotation>

<xsd:documentation>

Defines the maximum crawl depth.


</xsd:annotation>

</xsd:element>

<xsd:element name="maxNumberOfObjects" type="xsd:int">

<xsd:annotation>

<xsd:documentation>

Defines the maximum number of objects to be crawled.


</xsd:annotation>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:schema>

Listing 14. crawlerConfiguration.xsd



5.2 JSON Schemas

5.2.1 Namespace “test”

{

"description" : "http://imergo.com/ns/3.0/test/test",

"type" : "object",

"properties" : {

"httpReference" : {

"$ref" : "http://imergo.com/ns/3.0/public/httpReference" },

"content" : { "$ref" : "http://imergo.com/ns/3.0/test/content" },

"testCriteria" : { "$ref" : "http://imergo.com/ns/3.0/test/testCriteria" }

}

}

Listing 15. test.json

{

"description" : "http://imergo.com/ns/3.0/test/content",

"type" : "object",

"properties" : {

"content" : { "type" : "string" },

"encoding" : { "type" : "string" },

"contentType" : { "type" : "string" }

}

}

Listing 16. content.json

{

"description" : "http://imergo.com/ns/3.0/test/testCriteria",

"type" : "object",

"properties" : {

"testCriteria" : "array"

}

}

Listing 17. testCriteria.json

{

"description" : "http://imergo.com/ns/3.0/test/testCriterion",

"type" : "object",

"properties" : {

"name" : "string",

"value" : "string"

}

}

Listing 18. testCriterion.json

5.2.2 Namespace “public”

{

"description" : "http://imergo.com/ns/3.0/public/agent",

"type" : "object",

"properties" : {

"loginName" : "string",

"password" : "string",

"email" : "string",

"projects": {

"type":"array",

"items":{

"type":{ "$ref" : "http://imergo.com/ns/3.0/public/project" }

}

}

}

}

Listing 19. agent.json

{



"description" : "http://imergo.com/ns/3.0/public/project",

"type" : "object",

"properties" : {

"name" : "string",

"projectConfigurations": {

"type":"array",

"items":{

"type": { "$ref" : "http://imergo.com/ns/3.0/public/projectConfiguration"

}

}

}

}

}

Listing 20. project.json

{"projectConfiguration": {

"name": "String",

"startReference": {

"uri": "http://www.altova.com"

},

"headerContainer": {

"header": {

"name": "String"

}

},

"credentialsMap": {

"credentialsMapEntry": {

"username": "String",

"password": "String"

}

},

"handlingCookies": true,

"runs": {

"run": {

"timeDateStamp": "2001-12-17T09:30:47Z",

"resultContainer": {"result": "text"}

}

},

"referenceContainer": {

"references": {

"reference": {

"uri": "http://www.altova.com"

}

},

"created": "1967-08-13"

},

"locale": "en-us",

"period": 0

}

}

Listing 21. projectConfiguration.json

{

"description" : "http://imergo.com/ns/3.0/public/run",

"type" : "object",

"properties" : {

"id" : "integer",

"timeDateStamp" : "string",

"resultContainer": {

"$ref" : "http://imergo.com/ns/3.0/public/resultContainer" }

}

}

Listing 22. run.json

{

"description" : "http://imergo.com/ns/3.0/public/reference",

"type" : "object",

"properties" : {

"http" : "boolean",

"uri" : "string"

}

}



Listing 23. reference.json

{

"description" : "http://imergo.com/ns/3.0/public/header",

"type" : "object",

"properties" : {

"name" : "string",

"value" : "string"

}

}

Listing 24. header.json

{

"description" : "http://imergo.com/ns/3.0/public/headerContainer",

"type" : "object",

"properties" : {

"headers" : "array"

}

}

Listing 25. headerContainer.json

{

"description" : "http://imergo.com/ns/3.0/public/httpPostReference",

"type" : "object",

"properties" : {

"urlEncodedFormHttpEntity" : {

"$ref" : "http://imergo.com/ns/3.0/public/urlEncodedFormHttpEntity" }

}

}

Listing 26. httpPostReference.json

{

"description" : "http://imergo.com/ns/3.0/public/httpReference",

"extends" : "reference",

"type" : "object",

"properties" : {

"method" : { "type" : "string" },

"headerContainer" : { "$ref" : "http://imergo.com/ns/3.0/public/headerContainer" }

}

}

Listing 27. httpReference.json

{

"description" : "http://imergo.com/ns/3.0/public/crawlerConfiguration",

"type" : "object",

"properties" : {

"maxDepth" : "number",

"maxNumberOfObjects" : "number"

}

}

Listing 28. crawlerConfiguration.json



6 References

Abou-Zahra, S. (Ed.). (2011). Evaluation and Report Language (EARL) 1.0 Schema. Retrieved from http://www.w3.org/TR/EARL10-Schema/

Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures. Retrieved from http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

http://www.w3.org/TR/EARL10-Schema/

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm



Appendix: List of abbreviations and acronyms

An up-to-date list of common abbreviations and acronyms used in our documents can be found online at:

http://services.imergo.com/ns/abbreviations.html

http://services.imergo.com/ns/abbreviations.html

soa interfaces for the integrated prototypes · pdf file3.2.1.3 types ... table 5. schemas in...

Documents