Cloud Visualisation
Processing Related to Rendering of Clouds by Visualising Agents
Final Community Group Specification 3 April 2013
- This Version:
- http://www.sr2u.com/w3c/cloud-vsltn-20130403.html
- Latest Version:
- http://www.sr2u.com/w3c/cloud-vsltn.html
- Editor:
- Russell Potter
Copyright © 2010-2012 the Contributors to the Cloud Processing 1.0 Specification, published by the Cloud Computing Community Group under the W3C Community Final Specification Agreement (FSA). A human-readable summary is available.
Table of Contents
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"
"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
The visualisation process consists of the following general steps
(as demonstrated in Figure 1):
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
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 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
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
The following example illustrates a "project" request by a
visualising agent facing The behaviour of a node on receipt of a The 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"
The 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 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
The 2. Terminology
3. Introduction
4. Overview
5. The "Visualise" Request
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"
h_angle="0.2"
v_angle="0.25" />
6. The "visualise" response
<gained xmlns ex=http://www.example.com>
<ex:a>
<ex:b>
<ex:c>
/gained>
<lost>
<d xml:id=xyz>
</lost>
7. Inter-Node requests and responses
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
(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" />
<artefacts>
<x xml:id="a" />
<y xml:id="b" />
<z xml:id="c" />
</artefacts>
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
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
<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" />
</name>
7.3. The "query" request
query request is a mechanism by
which a node may determine, by interrogating a
neighbouring node, the artefacts contained within
two named regions
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
<query from="#x" to="#y" />
7.4. The "query" response
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
References