Communication between mobile clients and server consists of messages expressed as XML documents or document fragments. Because it appears that all such things must have a snappy name, this protocol is called ConteXtML, indicating both its primary function of exchanging contextual information and its basis in XML, the eXtensible Markup Language.

Normally, ConteXtML messages are grouped within a <context> tag or element. For example, the following might be sent by a client to indicate its current location (the <spatial> element) and that it requires notes containing a data item called "landuse" with the value "pasture" (the <require> element).

The <context> message may contain information about the client’s current context, its required context, or data such as FieldNotes or map objects. The current context simply describes some aspects of the client’s current environment, and may include location, velocity, details of people involved in the mobile task, and other arbitrary data items of relevance to the current activity. The required context represents the client’s "context of interest" and specifies a set of constraints that the server should apply in choosing which FieldNote or map data to send. In this example, the client’s location is regarded as part of its current context, and the <require> element informs the server of its required context.

In the absence of any required context, the server defaults to sending no information other than general information messages or messages for the specific user. These are formatted as PCDATA within a <message> element. An earlier implementation defaulted to sending all FieldNotes within a pre-determined radius whenever the client provided their location as a <spatial> element. With any moderately large collection of notes, this approach might result in sending many unwanted notes, so the alternative default of sending no data unless requested by an explicit <require> was adopted.

To initiate a communication session, the mobile device sends a <context> message to the server with an empty or "new" session attribute. In its simplest form the context message contains no other data:

or, because the session value defaults to "new",

The server generates a new session identifier and returns it in the session attribute of a similar message

The session identifier is used to maintain state between messages and allow multiple client sessions to coexist on the same server. In the current prototype implementation there is no attempt to address security issues, so any client could impersonate any other provided that it knows their current session identifier. Although the server only responds to messages with a "new" or currently active session identifier, it generates identifiers as sequential numbers, so it would be a trivial task to find identifiers for other sessions. Security issues such as use of passwords or encryption of messages need to be addressed in a future version.

A session remains active until the client sends a context message with the action attribute set to "close":

The server closes the session snd responds by returning an identical message. Subsequent attempts to use the same session identifier will result in an error. This, like other error messages sent by the server, is wrapped in an <error> tag. In the current implementation of the protocol, <error> is the only tag other than <context> that can be used as the root or document type element of a message.

A somewhat more useful way of initiating a session is to include some current contextual information about the client’s environment:

Here, the <person> element provides the name of the user and the <spatial> element indicates their current location. Other persons can be named and given a role by adding extra <person> elements. The location will usually be specified as a point, but there is no reason why other spatial object types, such as lines, polygons or boxes, should not be used.

The server caches all contextual data associated with a session. When it receives subsequent context messages from the same client it will update their cached current context, so the following will only change the client’s location leaving other context intact:

Previous client context is not over-written, but is stored in the database as a temporal object with timestamps indicating its validity. The server can track changes in the client’s current context and thus could support applications such as vehicle tracking.

In addition to information about people and location, any arbitrary data item of relevance to the application may be sent in a <dataitem> element. The server records this data and its association with the particular session in the database for use as required by applications.

If the client wishes to receive data such as maps or FieldNotes they must also send one or more <require> messages to define their required context. For example, to specify the required map data, the client sends a message such as:

Requests for a set of notes are similar:

The <map> or <note> elements within a <require> tag are combined using a logical OR operation. Within a <map> element the attributes are combined by a logical AND, as are <person> and <data> elements within a <note> tag. So, the first of the above states that the client requires map data matching the constraint:

In the second case, the client requires notes matching the constraint:

The <person> element is identical to that used in <context> and <FieldNote> tags. The <data> element corresponds to the <dataitem> element of a FieldNote, but differs in providing an op (operator) attribute so that Boolean expressions other than equality can be used in require messages. For example,

and

Range queries can be achieved simply by combining pairs of <data> tags within a single <note> tag:

Currently, the valid operators correspond to those of simple Boolean expressions in SQL, they are:

Note and map requirements may be combined in a single <require> tag, so the earlier examples might also be expressed as

The following is not finalised.

Timestamp, spatial and temporal constraints may also be included in the <require> element. These allow the client to specify the ranges of creation dates, spatial and temporal coverages of notes or maps required from the server. The <spatial> and <temporal> elements are identical in form to those used in FieldNotes, described below.

The containment semantics of a box or polygon are, hopefully, obvious, but the meaning of points and lines in a required context is less so. For a point or line, the preferred interpretation would be to return notes that lie within some agreed distance. The simplest solution might be to add one or more attributes to the spatial element to allow this distance to be specified and to use a ‘sensible’ value if it is missing. It is worth noting that a default distance will often be dependent on the client’s dynamics. Typically a user on foot would require information covering a smaller range than one in a vehicle, whilst one in an aircraft would require a yet greater range. Note that the current context may include a <velocity> element that might be used here.

There is also the issue of the scope of the spatial and temporal coverage within a require block. Typically, a user would require a set of data where all items refer to the same spatial area or temporal period. If we were to follow the pattern of OR and AND semantics described above, then each <note> or <map> element would need identical <spatial> and <temporal> constraints just to ensure that each referred to the same area or time period. Not only is this unnecessarily repetitive, but it also introduces a potential for error and leads to greater complexity in the query generation part of the server.

The chosen solution is to allow <spatial> or <temporal> constraints to apply to the whole <require> block, and not to permit their use within a <note> block. Then, if different areas or periods are required for different groups of notes, these must be specified in separate <require> blocks. This approach also allows these constraints to be applied to maps, in which case, the xmin, ymin, xmax and ymax attributes of a map element should be ignored in a require block. It is worth noting that there are circumstances in which a <temporal> constraint might be also be applied to a map when the information presented applies to a period other than its creation date.

A further question is how best to deal with a require block without spatial or temporal constraints. The obvious answer is to say that the returned data is not constrained in these dimensions and to trust that the specified note or map constraints are sufficient to limit the amount of data returned to a reasonable level. Perhaps we need the option to specify a maximum result size as an attribute of the <require> element?

For many, if not most, applications, the location specified in the current context might be the same as that specified in a require block, so that new information is sent as needed when the client moves through space. In this case it seems needlessly repetitive to repeat the same information in the require block. For this reason, we adopt the following conventions:

1. that, in the absence of a spatial constraint in the require block, the user’s location and dynamics (if known) should be used to determine the spatial requirement constraint, and
2. that spatial constraints in the require block override any consideration of the user’s location in determining which data the server should send.

Multiple <spatial> or <temporal> constraints within a <require> block are combined into a single group by logical OR. This group is then combined with <note> or <map> constraints by logical AND. This is illustrated by the following example:

Thus, using the labels on the right to stand for the full constraint, the above require block means return maps constrained by

((sp1 OR sp2) AND (t1 OR t2) AND (m1 OR m2))

OR FieldNotes constrained by

((sp1 OR sp2) AND (t1 OR t2) AND ((n1.p1 AND n1.d1) OR n2.p2))

Two attributes of the <note> element allow constraints to be applied to the prefix part of the FieldNote identifier and the creation date timestamp. For details, see the example below and description of the <note> tag later in this document.

The default action at the server is to add a new set of required context constraints to those already cached. In other words, the new constraints are OR-ed with existing ones. The same is true when mutiple <require> elements occur within the same <context>. Alternatively, the action attribute may be set to "replace", in which case the cached constraints may be replaced by a new set. For example,

implies that the constraints should be added, and is equivalent to

but

requests the server to replace any current constraints by those supplied in this element. Note that it is legal, if pointless, to have multiple <require action="replace"> elements within a single message. The semantics is identical to that of separate messages in which the earlier <require> elements are replaced by the later ones.

The element is used to send predefined or ad hoc queries to the server. The response is enclosed within a <result> element.

The result of a "who" query should be extended to include the current location of the person, if known.

Ad hoc queries can be expressed as SQL statements expressed as text within the <query> element (#PCDATA). This is useful but requires knowledge of the underlying database structure. Note that queries which attempt to modify the stored data are rejected. Future versions may permit trusted clients to directly modify the database, but this will require attention to security issues.

The server responds to ad hoc queries by returning the result relation as a set of <tuple> elements, each with one or more <el> elements representing the individual values.

An <el> with a null value is not sent, so tuples within a set may not all have the same number of <el>s.

A further form of query is envisaged, but not yet implemented. This will return lists of unique terms that might be used to populate a user interface listbox so that the user can choose from a constrained list of values.

The following sections describe the main ConteXtML elements. For further details see the DTD.

A map is a named map layer normally sent by the server to the client. The attributes proj, zone and datum provide basic georeferencing, and xmin, ymin, xmax, ymax define the bounds of the area covered. The use of name and class attributes is application dependent. For example, there might be maps with names "motorways", "major roads", "minor roads", all with the class name "roads". Further metadata, such as the survey date, resolution, etc. can be supplied in <dataitem> elements.

Note: the definition of map has not been finalised and is not fully supported in the current server.

The <FieldNote> element has attributes for identifier and timestamp, and may contain any number of <person>, <dataitem>, <spatial>, <temporal> and <comment> elements.

The timestamp represents the time of creation or last modification, and is mandatory. The identifier is in two parts, a prefix (idprefix) and a number (idnumber). The prefix is a mandatory string of no more than eight characters. Typically, it is used to distinguish a group of notes forming a project, for example the notes recorded at Falerii Novi in 1998 have the prefix "FN98". Where a project involves several client machines, these may be distinguished by adding a different code for each machine, for example "FN98A", "FN98B", and so on. The idnumber must be unique within an idprefix, but a mobile application is free to generate this by any means that comply with this constraint. A newly created note with the idnumber set to zero will be assigned a unique number when it is passed to the server.

A client program that permits notes to be modified must ensure that any changed note is sent back to the server. Ideally, it should only be necessary to send those parts of the note that have been changed, but current implementations require the complete note to be sent. At the server end, notes are versioned with timestamps, so when an updated note is received, its current stored record is stamped with an "end of validity" timestamp, and a new record inserted with its "start of validity" set to the same time. Internally, the server identifies different versions of a note by a unique object identifier, rather than the idprefix+idnumber pair.

The <person> element can occur one or more times as components of the client's current context, of a FieldNote, or within a <note> constraint element within a <require> element. It has role, first, last and name attributes. The role is a string describing why the person is recorded and is typically a single word such as "user", "author" or "recorder". Normally, the person's name is supplied in the first and last attributes. Use of the name attribute is deprecated. It is an alternative to the first, last pair and is present for historical reasons. If used, it should contain a first and last name separated by white space.

In current context or a Fieldnote, <person> should always include the role, first and last attributes. In a <require>, it may contain any one or more of these.

The <dataitem> element can occur one or more times as components of the client's current context or of a FieldNote. A modified form called <data> is used in the <note> constraint element of a <require> element. <dataitem> has name, type, and value attributes. An encoding attribute is defined in the DTD for possible use with inline encoded values for non character data types, but this has not been used in any current implementation. Also unused at present is an oid attribute intended for use when instances of this element form part of a nested data structure.

The name attribute holds the name of the variable or data item, the type holds a string giving a type name, and the value holds a string representation of its value. The default value of type is "string". There is currently no constraint on the content of the type attribute, although later versions may define a list of acceptable type names. In the current implementation, the server always stores the content of the value attribute as a string in the database, but applications are free to convert this to other representations appropriate to the specified type.

The <data> element is used only in the <note> constraint element of a <require> element. It has the name, type, and value attributes as in <dataitem>, plus op to support simple name-operator-value constraints.

The <spatial> element can occur singly as a components of the client's current context, and one or more times in a FieldNote, or a <note> constraint element within a <require> element. It is used to indicate the user's location in their current context, the spatial applicability of a FieldNote, or the spatial range of interest in the required context.

A spatial coverage is composed of one or more geometric elements (<point>, <line>, <poly>, <circle> or <box>). All geometric element types may include a id attribute (geometry identifier), points may include one or more associated <gps> elements

The <temporal> element can occur one or more times as components of the client's current context, of a FieldNote, or within a <note> constraint element within a <require> element. It is used to indicate the temporal applicability of a FieldNote, or the temporal range of interest in the required context.

There are two attributes, type and t. The first may contain one of "timestamp", "period" or "interval", with "timestamp" as the default. The t attribute contains a string representation of the temporal object, either in ISO format or in a derivative of that used for variable granularity and uncertain temporal objects in Bagg & Ryan 1997 (see also http://www.cs.ukc.ac.uk/people/staff/nsr/stdb/gr96/temptype.html).

Support for <temporal> elements is not yet fully implemented in the server.

The <comment> element can occur one or more times within a <context> or <FieldNote> element.