Cloud Visualisation

Processing Related to Rendering of Clouds by Visualising Agents

Final Community Group Specification 3 April 2013

This Version:

Latest Version:

Russell Potter

Table of Contents

1. Name-spaces
2. Terminology
3. Introduction
4. Overview
5. The "visualise" Request
6. The "visualise" Response
7. Inter-Node requests and responses
7.1. The "project" request
7.2. The "name" request
7.3. The "query" request
7.4. The "query" response

1. Namespace

The default namespace used by XML documents in this specification is "http://www.w3.org/ns/cloud"

The "xml" namespace, used on the specification of IDs, [XML11] is "http://www.w3.org/XML/1998/namespace"

The "xlink" namespace, used in hyper-linking [XLINK] is "http://www.w3.org/XML/1999/xlink"

2. Terminology

Visualising Agent
A user agent issuing "visualise" requests to some cloud
A single computational entity within a cloud

3. Introduction

"Visualisation" involves the process of transforming a set of cloud artefacts, such that each node in the cloud responds to the visualisation request by with a set of points, lines and planes as a visual representation of the cloud artefacts that lying within one of the defined geometric spaces "belonging" to that node

The boundary surface of each of these spaces consists of a set of triangular planes, each of which, in turn, consists of an identifier, the Cartesian co-ordinates of the its vertices, a normal vector (pointing toward the in-side of the bounded volume) and the IRI [IRI] , usually in the form of a fragment identifier, of each neighbouring surface

4. Overview

The visualisation process consists of the following general steps (as demonstrated in Figure 1):

  1. A visualising agent issues a "visualise" request to some cloud node, which then sends a "project" request, detailing the artefacts it wishes to render, on to those nodes located behind that node
  2. Each receiving node then renders both the requested artefacts, request, as well as its own artefacts, passing that combination on, in turn up a "project" request of those nodes behind that node (with respect to the visualising agent),
  3. when a node, on receiving a "project" request, detects it has no additional artefacts to render, the accumulated rendered artefacts are repeatedly passed through the chain of nodes through which the "project" request was communicated

Note: references to a node as "behind" a second node (or, conversely, that second node as "in front of" the first node) refers to a situation whereby the vector "dot product" between the normal vector of the plane dividing the two nodes and the vector difference between the location of the visualising agent and the artefact's location yields negative value: that is, the dividing plane at that location "points away" from the client

5. The "Visualise" Request

The visualisation process is initiated by a "visualise" request, issued by a visualising agent

This request made by an agent to "visualise" some cloud, an consists of an HTTP [HTTP] "GET" request, the body of which contains a single XML element having the tag "visualise" (in the name-space of this specification), having an attribute, named "timeout", specifying the maximum time, in milli-seconds, a visualising agent will wait for nodes to respond with visible artefacts, attributes, named "position" and "last_position" ,containing the current and last (respectively) position of the visualising client, attributes named "direction" and "last_direction" containing the current and last (respectively) direction the in which the last four in the form of comma-separated numbers representing the X, Y and Z components of the these vectors and attributes named "h_angle" and "v_angle", specifying the horizontal and vertical (respectively) viewing angle, in radians, of the visualising agent

If the last position and direction of the "last_position" and "last_direction" attributes ate unspecified, they ate assumed to have remained unchanged

The following example "visualise" request illustrates a visualise request for a visualising agent having current and last locations of (0, 0, 0) and (0, 0, 1) (respectively) and current and, directions of (1, 1, 1) and (1, 1, 2) (respectively) and horizontal and identical viewing angles of 0.2 and 0.25 radians (respectively)

<visualise timeout="20"
            location="0, 0, 0"
            last_location="0, 0, 1"
            direction="1, 1, 1"
            last_direction="1, 1, 2"
            v_angle="0.25" />

6. The "visualise" response

On receipt of a "visualise" request, a node sends send a "200 OK" HTTP message, the body of which contains an XML document contains two elements having the tags "gained" and "lost", containing an XML serialisation of those artefacts whose visibility was gained by and the IDs of those artefacts whose visibility was lost to, respectively, the visualising agent (due to direction or position changes) since the agent's last visualisation

The following example illustrates a "visualise" response in which three artefacts were added and an artefact having ID "xyz" was lost

<gained xmlns ex=http://www.example.com>
    <d xml:id=xyz>

7. Inter-Node requests and responses

This section details the requests and responses passed between nodes in order to service a "visualise" request by visualising agents

In this respect, cloud nodes, as well as listening for and responding to "visualise" requests (as described above) from visualising agents, may also receive, and respond to, the following requests from other, neighbouring, nodes.

Where a response to a particular is not listed, is assumed to consists of s "200 OK" status response, containing no body

7.1. The "project" request

A project request consists of an XML document containing one element having the tag "project", having an "artefacts" child containing a sub-element the children of which represent an XML serialisation of the artefacts to render and attributes "artefacts", "direction" and "origin", containing the comma-separated co-ordinates of the current direction and location of the visualising agent

The following example illustrates a "project" request by a visualising agent facing (1, 1, 1) and located at (2, 2, 2) for artefacts with IDs "a", "b", and "c"

<project direction="1, 1, 1"
            origin="2, 2, 2" />
    <x xml:id="a" />
    <y xml:id="b" />
    <z xml:id="c" />

The behaviour of a node on receipt of a project request will be to, if it is determined that there are artefacts to render, will, typically, be to re-send the request, to each node determined to be "behind" the node (with respect to the direction of the original "visualise" request), using the same received artefacts, added to which are added those visible artefacts determined to be contained within the node's boundaries

7.2. The "name" request

The name request gives a "nick-name" to a boundary region of a node, so that references to such a region may nr made more succinct, rather than using explicit references to each constituent boundary vertex and/or region

The request consists of an HTTP "GET /name" request, the body of which is an XML document containing a single element with the tag 'name", representing the name of the region, and containing one or more "vertex" elements, each representing the IRI of a constituent boundary vertex, and one or more "region" elements, each representing a constituent boundary region

The following example illustrates the naming of s boundary region with "h", containing the boundary vertices having IDs "#x", "#y" and "#z" and boundary regions having IDs "$#i", "#j" and "#k"

<name xml:id="h"
    <vertex xlink:href="#x" />
    <vertex xlink:href="#y" />
    <vertex xlink:href="#z" />
    <region xlink:href="#i" />
    <region xlink:href="#j" />
    <region xlink:href="#k" />

7.3. The "query" request

The query request is a mechanism by which a node may determine, by interrogating a neighbouring node, the artefacts contained within two named regions

The determination of these queried artefacts is typically performed as a pre-cursor to the transfer of ownership of a set of artefacts from one node to another.

A node may wish to relinquish a set of artefacts in order to, for example, lighten an overly-heavy computational load or, conversely, to add artefacts to add to an overly-light computational load

In order to relinquish artefacts, a node first issues a query request to the node owning the artefacts in question, then actually relinquishing the returned artefacts (in some appropriate manner), while adding artefacts involves , similarly, first issuing a query request to relinquishing node, then adding the returned artefacts to the node's control in an analogous manner in which artefacts are relinquished

The request itself consists of an HTTP [HTTP] "GET /query" the body of which contains an XML document consisting of an element eth the tag "query" and attributes "from" and "to" representing the names of the bounding regions within which the artefacts must lie to be included in the query set

The following example illustrates a query for artefacts lying between boundary regions having IDs "x" and "y", respectively

<query from="#x" to="#y" />

7.4. The "query" response

The query response, representing the artefacts lying within a queried region, consists of an HTTP "200 OK" response the body of which consists of an XML document, itself containing an XML serialisation of those artefacts lying within the query's boundaries


M. Duerst; M. Suignard Internationalized Resource Identifiers (IRIs). January 2005. Internet Engineering Task-force Request for Comments 3987. URL: http://www.ietf.org/rfc/rfc3987.txt
R. Fielding et al Hypertext Transfer Protocol - HTTP/1.1. January 2005. Internet Engineering Task-force Request for Comments 2616. URL: http://www.ietf.org/rfc/rfc2616.txt
Tim Bray; Jean Paoli et al Extensible Markup Language (XML) 1.1 (Second Edition). 6 May 2010. W3C Recommendation. URL: http://www.w3.org/TR/xml11/
Steve DeRose; Eve Maler et al XML Linking Language (XLink) 1.1. 19 April 2012. W3C Candidate Recommendation. URL: http://www.w3.org/TR/xlink11/