Scope of User Contexts specification

This is my somewhat opinionated response to the scope discussion at the
meeting.

The purpose of the User Contexts spec is to enable disclosure of the user's
needs/preferences to a Web application so that it can adapt its UI
appropriately. The handling of the user's "context" may broadly be understood
by reference to a three-stage pipeline:

1. The context, consisting of need/preference assertions, is collected by the
user agent. There may, in principle, be multiple sources of contextual
assertions: explicit configuration parameters set in the UI of the UA;
information acquired from the operating system; information retrieved from a
preference server (as in the GPII), and so forth.

A question arises as to how much of this collection phase is within the scope
of the User Contexts specification and which aspects are left to the
implementation. This includes the question of how multiple sources of context
(e.g., explicit configuration settings or information about assistive
technologies available from the operating system) are reconciled in case of
inconsistencies, and whether such reconciliation behaviour lies inside or
outside the purview of the specification.

In my judgment, a large part of this collection phase should be left to the
implementation, but some aspects of it may need to be specified to avoid
conflicting behaviour among different user-agents. For example, one user agent
may give priority to explicit configuration settings, whereas another may
treat information obtained via operating system APIs as having higher
precedence. What information is collected from which sources will of course be
implementation-dependent, since this largely depends on the operating system
and the capabilities of the UA.

2. The context, a set of need/preference assertions, is disclosed via an API
implemented in the user-agent that may be called by Web applications. This is
the core of the spec - we need to define at least the vocabulary of available
assertions and the API functions/data structures that applications can use. I
think this was common ground at the meeting, although the question of
vocabulary extensibility remains open, as noted in the discussion. As a
special case, an existing user context (a need/preference profile) may be
modified by inserting, deleting or substituting items.

3. The Web application adapts its user interface according to the
needs/preferences asserted by the UA. The UI is thus context-sensitive in a
very specific sense. The adaptations are dependent on the Web application, but
may involve style properties, the content and structure of the delivered
document as presented in the DOM, the behaviour that arises in response to
the user's actions, etc., all of which aspects can be customized by the
application according to the received contextual information. The adaptations
are not specified; they are outside the scope of standardization efforts.
However, the proposal discussed at the meeting indicates that the application
should achieve a "best match" of its capabilities with the expressed
need/preference profile of the user. This suggests that some aspects of the
application's behaviour will need to lie within the scope of the spec, and
this should be more clearly delineated.

Thus I think the "middle" of the pipeline constitutes a well defined
requirement for standardization, but the scope of the spec needs to be better
defined in respect of both endpoints, namely stages 1 and 3 above.

It is possible that a UA can satisfy certain needs/preferences within its own
user interface, without requiring cooperation from the Web application. Such
adaptive behaviour by the UA is, I think, outside the scope of this spec, but
issues may arise regarding interactions between UA preferences and what the
Web application is required to do by way of adapting to the asserted user
context.

To reiterate: I understand the purpose of this work as solving the problem of
forwarding need/preference profiles (contexts) to Web applications, i.e.,
scripts/programs running in the UA and originating from a Web server.

Received on Thursday, 7 February 2013 00:43:14 UTC