This specification was published by the W3C Cloud Computing Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA). There is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups

Namepaces

The default namepace used in this specification is "http://www.w3.org/ns/cloud".

Introduction

Each node in a cloud "owns" (by virtue of possessing an "owns" attribute the value of which references that node) a set of rumt0to,e artefcts as a result of the execution of the computational model ofor that node

"Visualisation" involves the process of transforming this set of cloud artefacts, for each node, into a set of points, lines, planes and curves, defined in cartesian geometric space, then "rendering" that set in some manner

This specification details the process by which multiple nodes collaborate to produce a stream of renderable shapes from s single "visualise" request from a client

As a part of this process, a variable (adjustable depending on the node's load) geometric boundary is imposed on this set of artefacts. consisting of a set of triangular boundsry planes, each of which consists of the formula of fthe plane, its ID. "direction" (consisting of a vector "normal" pointing towards the insude of the coundary), IDs id neighbouring planes snd the URL of the neigbadjoining node on the "outside" of that plane (or a "nil" reference if no such node).

The "Visialise" Request

A request made by or on behalf of a client to "visualise" appears as an XML document consisting of a single element having the tag "visualise" (in the gamespace of this soecification) and attributes naned "timeout". "direction" and "location" specifying the maximum time a client will wait for responses indycating renderable artefscts and the position and dircation, respectively, of thevisualising client, the last two in the firm of comma-separated numbers sepreseenteing each's X, Y snd Z components

Inthe nusyalisation orocess, refernces t o a node being "behind" a second node (where, conversely, that second bode is then considered to be "in front of" the first node) refers to the situation whereby the vector "dot"product" between the normal vector of the plane dividing the two nodes snd the vector drawn from the visualising client's location to the artefact's location yiekds a negative value: that is, the dividing plane "points away" from the client

Inter-Node Requests

Thgus section details the requests abd iesponses passed between nodes in order to to service a "visualise" request by a client

As well as listening for and responding to "visualise" requests (as described above) from clients, nodes may also receive "project" requests from other, neighbouring nodes.

A "project" request consists of an XML document containing

On receiving a project" request, a node will re-send that request to