This document sets out the Requirements for defining a set of Core
Presentation Characteristics. The purpose of defining these Core Presentation
Characteristics is to provide a common set of property or attribute
definitions that can be reused in many contexts in which the presentation
capabilities of a presentation device need to be considered. The use of
well-defined Core Presentation Characteristics will simplify the task of
adapting content to a specific presentation delivery context. The document
sets out what is meant by 'core' and 'presentation,' what should be included
in the definition of each characteristic, what should be defined when grouped
characteristics into collections, and what kind of characteristics should be
included in the core. It also suggests some use cases.
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status
of this document series is maintained at the W3C.
This document is a public W3C Working Draft for review by W3C members and
other interested parties. It is a draft document and may be updated,
replaced, or made obsolete by other documents at any time. It is
inappropriate to use W3C Working Drafts as reference material or to cite them
as other than "work in progress." A list of current public W3C Working Drafts
can be found at http://www.w3.org/TR.
This is a working draft of a possible future W3C Note.
This document is published as part of the W3C Device Independence Activity
by the Device Independence Working Group. It is a deliverable as defined
in the charter
of that group. An earlier
version was made available as an informal public draft by the working
group.
Comments on this document may be sent to the public www-di@w3.org mailing list (archived at
http://lists.w3.org/Archives/Public/www-di/).
Patent disclosures relevant to this document may be found on the WG patent disclosure
page.
Information characterizing the delivery context of a web access mechanism
is a critical enabler for device independence. To that end, the Delivery
Context Overview for Device Independence document [DCO]
summarizes the various techniques currently used within the industry for
representing, conveying and processing delivery context information. Most of
these approaches like OMA UAProf [UAProf] and CSS Media
Queries [CSSMediaQ] have also specified
partial or complete sets of capabilities related to their application
specific context of usage and implementation. However, a standardized
definition of key presentation characteristics is lacking, which would likely
be used across applications universally and specifically for the purposes of
device independent adaptation and rendering. The absence of a well-defined
core set of characteristics can lead to the proliferation of incompatible yet
overlapping repositories of properties or attributes that may conflict and
detriment from the selection of an appropriate presentation. Consequently,
there is a need to harmonize existing semantics, syntax and definitions for
describing delivery context information while also providing opportunities
for extensibility and forward compatibility with new capabilities and
features that have not yet been conceived.
An attempt to address these issues was first initiated in the context of
CC/PP. In fact, the CC/PP specification [CC/PP]
provides a sample non-normative "core" vocabulary for CC/PP aware devices.
While the CC/PP Implementer's Guide [CC/PP-Guide] identified and listed
existing vocabularies that could conform to the CC/PP structure and schema
and provided illustrations to that effect, it did not specifically attempt to
coalesce and unify the definition and semantics of the various attributes
within each vocabulary into a common core. The burden of such harmonization
was left to individual groups themselves with the expectation that they, as
good citizens of the Web, would ensure that the future evolution of the
vocabularies would converge to a common core. In the interim, the
impact is being felt by the developer community that strives to build device
independent applications in spite of the difficulty of interoperation between
these vocabularies.
In light of these issues, this document proposes and
outlines a core set of presentation characteristics that refer to the
presentation capabilities of a device or its user agent and which are a
subset of the full delivery context. By showing their relationship to
existing vocabularies, the Device Independence Working Group hopes that
future vocabularies can reuse these definitions. Authors of web applications
will then have a sound basis for expressing the adaptation of their content
to device presentation capabilities. This version of the core presentation
characteristics specification will concentrate on the most essential
presentation characteristics, while enabling more characteristics to be added
later.
To further the foreseen evolution of the
document, the W3C Device Independence Working Group will liaise with
representatives from groups that define UAProf, CSS Media Queries, and IETF
Media Feature Sets. The goal of this cooperation will be to work towards
establishing a consensus on a set of characteristics that will benefit and be
compatible to future vocabulary definitions.
2 Purpose and Scope
The intended purpose of the Core Presentation Characteristics
recommendation will be to define a common set of presentation properties or
attributes that:
- can be reused in different delivery context vocabularies
- share common semantics
- simplify the task of interpreting these attributes when adapting or
authoring content for presentation in different delivery contexts
Therefore, the scope of the Core Presentation Characteristics definitions
is restricted to attributes that are 'core' for the 'presentation' of web
content. A more thorough explanation of the meaning of these two terms
is presented below.
Presentation characteristics are those properties that define some
aspects of the way in which content may be presented to a user of an access
mechanism. Presentation characteristics are directly related to the
presentation model being used. For example, when rendering some HTML with CSS
visual styling, CSS defines a presentation model which includes, for example,
the visual area within which the presentation is to be made, and the fonts
with which text can be rendered. Similarly, when requesting an image to be
rendered as part of a presentation, there is a presentation model which
includes the image size and resolution at which it is to be displayed. For an
audio presentation of some text using a text-to-speech model, the
presentation model may include the available voices with which the text can
be rendered.
Core presentation characteristics are those that are relevant to
almost every device using a particular presentation model. This excludes from
the core any attributes that are specific to only a small subset of devices
using a given presentation model.
The purpose of this document is to set out specific requirements to be
satisfied in a future Core Presentation Characteristics Recommendation.
Specific information such as defining the purpose and application of existing
vocabulary sets are beyond the scope of this Requirements document. The
proposed Core Presentation Characteristics will be related to those of
existing vocabularies as part of the future recommendation. However, the
proposed core characteristics will not be simply a union or intersection of
existing vocabularies because of difficulties outlined in the next
section.
Characteristics related to a specific protocol, access rights, dynamic
behavior, or persistence are outside the scope of this document and are not
addressed. The aim of this document is not to provide information regarding
the purpose of delivery context and various access mechanisms. These are
discussed in other publications from this group such as the Device
Independence Principles document [DIP] and the Delivery
Context Overview for Device Independence [DCO].
Dublin Core [DC] defines a set of attributes that are
relevant to document description and which have been reused in many contexts
that need to refer to common document metadata. In a similar way, we will
define a set of attributes that can be reused in many contexts that need to
refer to common presentation characteristics.
The following examples illustrate difficulties in using existing
vocabularies with regards to specific criteria that are relevant to authoring
for device independence.
- Existing properties and attributes cover a wide range of device
capabilities - some of which are implementation-specific and others
are generic. For the sake of device independence, emphasis should be
placed on attributes that are relevant to presentation and independent of
the details of the device-specific implementation.
For example, an attribute defining the amount of memory available in
the device is effectively meaningless without detailed knowledge of the
device's implementation.
- Similar properties and attributes have been given non-uniform names
For example, screen size has been designated in various ways in
different vocabularies: in IETF Media Feature set [MFS] it has been named 'pix-x' and 'pix-y,' in SMIL 1.0
[SMIL1] 'system-screen-size,' in SMIL 2.0 [SMIL2] 'systemScreenSize,' and in CSS Media Queries [CSSMediaQueries] 'device-width' and
'device-height.'
- Syntax is different for different vocabularies. Some of this syntax is
easily translatable to XML, but in some cases this translation is not as
obvious.
For example, screen size may be given as separate values for width
and height, as in IETF Media Feature set [MFS] and
CSS Media Queries [CSSMediaQueries], or as
a compound value, such as 'heightxwidth' in SMIL [SMIL]
or 'widthxheight' in UAProf [UAProf].
- Different approaches have been taken to defining the allowable values,
or type, of an attribute.
For example, a natural language description is used in IETF Media
Feature set [MFS], SMIL [SMIL], and
UAProf [UAProf], whereas an RDF schema is used in the
CC/PP example vocabulary [CC/PP].
- The semantics of the attributes are often unclear.
For example, what is the meaning of display size being defined as a
signed integer in IETF Media Feature set [MFS]?
- Attributes with similar names may have very different semantics
For example, the semantics of the attribute 'color' is represented in
a variety of ways; 'color' is represented by an enumerated selection in
IETF Media Feature set [MFS] but as a number of bits in
CSS Media Queries [CSSMediaQueries] .
'ColorCapable' is defined as a boolean in UAProf [UAProf].
The following requirements have been divided into three categories:
requirements that define the structure and properties of the individual
attributes, requirements that define the collection of characteristics, and
requirements that indicate whether a characteristic is suitable for inclusion
in the core set.
4.1 Requirements defining the structure and properties of
individual attributes
Each individual core presentation characteristic
definition of an attribute must include the following:
- CPCR01 a universally unique
identifier
- CPCR02 an XML Schema Data type definition for
its allowable attribute values
- CPCR03 at least one literal syntactic
representation for each attribute value
- CPCR04 a natural language semantic definition
(that is as unambiguous as possible without formalism)
- CPCR05 an illustration of how the attribute
could be used in adapting content for presentation
If an attribute is associated with a measurable numeric value:
- CPCR06 the unit of measurement associated
with the attribute needs to be expressed in a non-ambiguous way, but only
if a unit of measurement can be associated with the attribute.
An attribute may have a value that is not a simple value when:
- CPCR07 the option of expressing a compound value for an
attribute, such as a set or sequence, is theoretically possible.
Where the description is available in the official language of the W3C:
- CPCR08 - Natural Language:At least one version of natural
language definitions, explanations, and other textual descriptions should
be provided in American English.
4.2 Requirements defining the collection of
characteristics
CPCR09 - Reuse: The overall set of Core
Presentation Characteristics must be defined as:
- one or more XML schemas (with URI)
- and/or one or more RDF schemas (with URI)
- and/or one or more CC/PP schemas (with
URI)
in order to allow unambiguous reuse of the core
attributes in different application contexts.
CPCR10 - Extensibility: It must be possible to
add additional presentation attributes beyond the Core Presentation
Characteristics to make a presentation-specific vocabulary.
CPCR11 - Modularity: The core attributes must be
grouped into related subsets to allow reuse of selected subsets in defining
future vocabularies.
CPCR12 - Versioning: The Core Presentation
Characteristics Recommendation should make proposals that address how adding,
removing or changing attributes in a vocabulary should be handled in order
to:
- clearly identify the applicable attribute definition
in any instance
- maximize the backward and forward compatibility with
existing and future applications
4.3 Requirements about what characteristics
are in the core
CPCR13 - Related
work: Related work of UAProf, CC/PP, CSS
Media Queries, and IETF Media Feature sets must be taken into account. The
Core Presentation Characteristics should use these specifications as a
starting point for defining core presentation attributes.
CPCR14 - Common Adaptation: The Core
Presentation Characteristics must be useful for common adaptation
tasks.
CPCR15 - Support for modalities: The Core
Presentation Characteristics should provide means to describe the modalities
of a device.
CPCR16 - Separation of input and
output: The Core Presentation
Characteristics should allow the author to specify whether an attribute is
applicable to output, input, or both.
CPCR17 - Navigation capabilities: The Core Presentation Characteristics should provide a
means to express the navigational capabilities of a device.
CPCR18 - Interoperability: The Core Presentation
Characteristics should only contain attributes that can be measured in a
reliable and interoperable way. It must be possible to compare different
instances of an attribute.
CPCR19 - Minimal initial set: The Core
Presentation Characteristics should focus on a minimal initial set of
attributes that are agreed to be highly useful, and accept that further
attributes could be added later as their need becomes obvious.
The following use cases are intended to motivate the need for Core
Presentation Characteristics in a few well-defined situations.
Some use cases are shown as requests for particular resources. Not all the
attributes may need to be sent with each request, depending on the protocol
used in the request. For example, in CC/PP or UAProf, attributes can be
included as part of an HTTP request either explicitly or by reference to a
base profile. It is not the purpose of the proposed recommendation to specify
which representation and protocol should be used for conveying attributes.
One use case is shown as the definition of a document profile. It is
intended that the attributes associated with a document could be used as part
of content negotiation to match the document to a request for a specific
delivery context. Again, it is not the purpose of the proposed recommendation
to specify a particular content negotiation mechanism. However, the value of
using comparable attributes in a document request and in a document profile
should be obvious.
The example attributes listed as part of the use cases are not intended to
define the exact attribute names or the syntactic representations to be used
in the final recommendation. These example attributes are also not intended
to be the only attributes needed in these use cases. The proposed
recommendation will need to consider which attributes should be defined as
core. The assumption should not be made that the following examples will be
included in the core.
5.1 Request for a static image resource
Summary
A user agent wishes to fetch a static image resource and include it as
part of a presentation.
Context
This is a common situation when a web browser fetches an image for
inclusion in a web page. It could also apply when fetching an image for
display on its own, such as in a photo album appliance. An alternative
scenario would be a web browser that already has a reference to an image
resource but wishes to present it in some alternative form, such as text or
speech.
Variants
The user agent may require the presented image to fit within a certain
display area. The image resource may be available in different formats and
resolutions. The user agent may wish to fetch a textual summary of the image
rather than the image itself.
Attributes
The following Core Presentation Characteristics could therefore be
relevant as part of making the request for the resource:
- acceptable image formats and versions: e.g. GIF89a, JPEG-2000
- desired image size: e.g. 400 x 300 pixels
- desired image colors: e.g. 24-bit rgb color per pixel
- pixel geometry: e.g. 4 : 3
- gamma: e.g. 0.45
- acceptable alternative formats: e.g. text/plain, text/html
Discussion
Although the user agent may suggest a desired image size, there is no
guarantee (depending on the extent to which the delivery path supports
content negotiation and adaptation) that the delivered image will be that
particular size. Browsers themselves are often able to scale an image to the
size they need. However, including a specific target size provides the origin
server or intermediate image proxy with the opportunity to select an
appropriate version of the image, provided this is possible and
permitted. Within the delivery context protocol, further controls over
intermediate processing may be needed.
5.2 Request for an HTML resource
Summary
A user agent wishes to fetch an HTML resource and render it within the
constraints of the delivery context.
Context
This is a common situation when a web browser fetches an HTML web page for
display in a browser window. It could also apply when a proxy fetches some
HTML for display within a defined area within a portal presentation.
Variants
The user agent requires the presentation to fit within a certain viewing
area such as a browser window, a pane of a portal, or a fixed-size display
such as a projector. When rendering the presentation, the user agent is
still allowed to adapt the content to fit into this viewing area or to scroll
within the viewing area as needed. The resource may be available in different
versions of HTML. The resource may use different techniques for adding
presentation styling. The user agent may support only a limited set of fonts.
The presentation may be designed for viewing from a certain distance. The
viewer may prefer the presentation not to include small text.
Attributes
The following Core Presentation Characteristics would therefore be
relevant as part of making the request for the resource:
- acceptable content formats and versions: e.g. HTML 4.0, XHTML 1.0
- acceptable content modules: e.g. XHTML Frames
- acceptable styling formats and versions: e.g. CSS 1.0, CSS 2.0 Mobile
Profile
- acceptable font families: e.g. sans-serif, serif
- acceptable fonts: e.g. Arial, Times New Roman
- acceptable languages: e.g. en, fr, de
- desired presentation size: e.g. 300 x 150 pixels
- desired presentation colors: e.g. 8-bit color per pixel from a palette
of 64K colors
- desired text viewing distance: e.g. 40cm
- preferred minimum text size: e.g.10 point
Discussion
The user agent is responsible for rendering the HTML in
an appropriate way, including matching it to the available display area and
available fonts. However, by suggesting acceptable and desired attributes, the opportunity exists for the origin server, or
some intermediate proxy, to support this goal by providing the most
appropriate version of the resource. For example, an abbreviated and more
simply formatted version of of the resource may be sent to a small display
such as those on a PDA or phone.
Remark: The scenario in this use case does not demand
or assume that the server is able to deliver a preformatted HTML resource
that fulfills all of the Core Presentation Characteristics. The only
expectation is that the server sends the most appropriate version of the
requested resource.
5.3 Request for an interactive resource
Summary
A user agent wishes to fetch an interactive resource and include it as
part of a presentation.
Context
This situation occurs when a web browser fetches an HTML web page which
includes some interactive elements, such as a form. It builds on the previous
example of a simple HTML page, and therefore could be used in similar
situations and require similar attributes for the display aspects of the
presentation. The additional burden on the user agent is how the interactive
parts of the presentation can be matched in the best way to the input
capabilities of the presentation device.
Variants
Interaction may relate to navigation and selection, such as the ability to
choose from a menu or to select by pointing or tabbing and click on a link.
It may also relate to the ability to enter arbitrary text in specific
alphabets.
Attributes
The following additional Core Presentation Characteristics would be
relevant to making the request for a resource:
- acceptable interaction formats: e.g. HTML 4.0 form elements, XForms
1.0
- acceptable input modalities: e.g. text, pointer, tabbing, voice
- acceptable text input languages: e.g. en, fr
- acceptable speech recognition grammar size: e.g. 100 words
Discussion
By suggesting acceptable interaction attributes, the opportunity exists
for the origin server, or some intermediate proxy, to do a better job of
providing an appropriate version of the resource. For example, a version of
the resource with simpler navigation requirements may be sent to a device
with no pointing input such as a phone or a speech browser.
5.4 Profile of a document
Summary
A document has attributes that express its delivery expectations.
Context
The author of an HTML document or the authoring tool which created it may
express the conditions under which this document should be considered
suitable for a particular delivery context. Content negotiation [Conneg] suggests there is a need to match the attributes
of the resources available for delivery (which could be expressed in a
document profile) with the attributes of the delivery context. CSS Media
Queries [CSSMediaQueries] already provides a
mechanism for allowing an author to specify alternative styles appropriate to
different delivery contexts.
Variants
Some aspects of a document are intrinsic to the document itself, such as
the markup language and version, or the fonts used. Other aspects
may be constraints imposed by the author, such as the minimum presentation
size for which the document has been designed.
Attributes
The following Core Presentation Characteristics could therefore be
relevant as part of the document profile:
- markup format and version: e.g. HTML 4.0, XHTML Transitional
- modules used in document: e.g. XHTML Frames
- text languages used in document: e.g. en, de
- font families used in document style: e.g. sans-serif
- fonts used in document style: e.g. Arial
- minimum target presentation size: e.g. 640 x 480 pixels
Discussion
Some of these attributes can be extracted from the document markup itself
(or its associated style sheet), such as the markup language and version or
the fonts it uses. Some early ideas on document profiles were produced by the
HTML working group [DocProfile]. Further work in
this area is within the charter of the Device Independence Working Group [DI-charter]. However, this use case should be
considered speculative at this stage.
- [CC/PP]
- http://www.w3.org/Mobile/CCPP/
- [CC/PP: Structure and Vocabularies]
- http://www.w3.org/TR/CCPP-struct-vocab/
- [CC/PP Implementors Guide]
- Harmonization with Existing Vocabularies and Content Transformation,
W3C Note,
- http://www.w3.org/TR/2001/NOTE-CCPP-COORDINATION-20011220/
- [Conneg]
- IETF
Content Negotiation Working Group, concluded October 2000
http://www.ietf.org/html.charters/OLD/conneg-charter.html/
- [CSS Media Queries]
- http://www.w3.org/TR/css3-mediaqueries/
- [DC]
- Dublin Core Metadata Initiative
http://dublincore.org/
- [DCO]
- Delivery Context Overview for Device Independence
http://www.w3.org/2001/di/public/dco/
- [DI-charter]
- W3C
Device Independence Working Group Charter
http://www.w3.org/2002/06/w3c-di-wg-charter-20020612.html
- [DIP]
- Device
Independence Principles, W3C Working Draft 18 September 2001
For latest version see: http://www.w3.org/TR/di-princ/
- [ocProfile]
- XHTML Document Profile
Requirements
http://www.w3.org/TR/xhtml-prof-req
- [FSM]
- Feature Set
Matching, sample software by Graham Klyne
http://www.ninebynine.org/Software/Conneg-FSM/
- [HTTP]
- http://www.w3.org/Protocols/rfc2616/rfc2616.html
- [MFS]
- A Syntax for Describing
Media Feature Sets, IETF RFC-2533 March 1999
http://www.ietf.org/rfc/rfc2533.txt
- Media Features for Display,
Print and Fax, IETF RFC-2534 March 1999
http://www.ietf.org/rfc/rfc2534.txt
- [MQ]
- Media
Queries, W3C Candidate Recommendation 8 July 2002
For latest version see: http://www.w3.org/TR/css3-mediaqueries/
- [P3P]
- Platform for Privacy Preferences
Project, W3C Initiative
http://www.w3.org/P3P/
- [SMIL]
- http://www.w3.org/AudioVideo/
- [SMIL1]
- http://www.w3.org/TR/REC-smil/
- [SMIL2]
- http://www.w3.org/TR/smil20/
- [UAProf]
- User
Agent Profiling Specification, WAP Forum 20 October 2001
For latest version see: http://www.wapforum.org/what/technical.htm
Other References:
The following definitions are taken from the HTTP/1.1 specification (RFC
2616) [HTTP] and the Device
Independence Principles [DIP].
- attribute
- A data element described with a specific associated name-value pair.
[HTTP]
-
- access mechanism
- A combination of hardware (including one or more devices and network
connections) and software (including one or more user agents) that
allows a user to perceive and interact with the Web using one or more
interaction modalities (sight, sound, keyboard, voice etc.). [DIP]
- device
- An apparatus through which a user can perceive and interact with the
Web. [DIP]
- delivery context
- A set of attributes that characterizes the capabilities of the access
mechanism and the preferences of the user. [DIP]
- origin server
- The server on which a given resource resides or is to be created.
[HTTP]
- proxy
- An intermediary program which acts as both a server and a client for
the purpose of making requests on behalf of other clients. Requests are
serviced internally or by passing them on, with possible translation,
to other servers. A proxy must implement both the client and server
requirements of this specification. A "transparent proxy" is a proxy
that does not modify the request or response beyond what is required
for proxy authentication and identification. A "non-transparent proxy"
is a proxy that modifies the request or response in order to provide
some added service to the user agent, such as group annotation
services, media type transformation, protocol reduction, or anonymity
filtering. Except where either transparent or non-transparent behavior
is explicitly stated, the HTTP proxy requirements apply to both types
of proxies. [HTTP]
- representation
- An entity included with a response that is subject to content
negotiation. There may exist multiple representations associated with a
particular response status. [HTTP]
- request
- An HTTP request message [HTTP]
- response
- An HTTP response message [HTTP]
- resource
- A network data object or service that can be identified by a URI.
Resources may be available in multiple representations (e.g. multiple
languages, data formats, size, resolutions) or vary in other ways.
[HTTP]
- server
- An application program that accepts connections in order to service
requests by sending back responses. Any given program may be capable of
being both a client and a server; our use of these terms refers only to
the role being performed by the program for a particular connection,
rather than to the program's capabilities in general. Likewise, any
server may act as an origin server, proxy, gateway, or tunnel,
switching behavior based on the nature of each request. [HTTP]
- variant
- A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these representations
is termed a `variant.' Use of the term `variant' does not necessarily
imply that the resource is subject to content negotiation. [HTTP]
- user agent
- The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
[HTTP]
A process within a device that renders the presentation data for a web
page into physical effects that can be perceived and interacted with by
the user. [DIP]
This document was produced by members of the W3C Device Independent
Working Group. Special thanks for their contributions, suggestions and
discussions in the preparation of this document are due to the following:
- Michael Wasmund, IBM
- Shlomit Ritz Finkelstein
- Rotan Hanrahan, MobileAware
- Mark Butler, HP
- Roland Merrick, IBM
- Guido Grassel, Nokia
- Luu Tran, Sun Microsystems
We also thank Graham Klyne, Larry Masinter, Martin Jones and Håkon Wium
Lie for their comments on the earlier informal draft, and have made several
changes in response. However, there may still be aspects with which they
disagree.
The full membership of the group at the time of publication is shown
below.
- Roger Gimson, HP (Chair, Co-Author)
- Markus Lauff, SAP (Co-Editor, Co-Author)
- Amy Yu, SAP (Co-Editor)
- Lalitha Suryanarayana, SBC Technology Resources (Co-Author)
- Mark Butler, HP
- Guido Grassel, Nokia
- Franklin Reynolds, Nokia
- Rhys Lewis, Volantis Systems
- Mark Watson, Volantis Systems
- Rotan Hanrahan, MobileAware
- Eamonn Howe, MobileAware
- Luu Tran, Sun Microsystems
- Greg Ziebold, Sun Microsystems
- Candy Wong, NTT DoCoMo
- Masashi Morioka, NTT DoCoMo
- Yoshihisa Gonno, Sony
- Steve Farowich, Boeing
- Roland Merrick, IBM
- Michael Wasmund, IBM
- Andreas Schade, IBM
- Dennis Bushmitch, Panasonic
- Ryuji Tamagawa, Sky Think System
- Abbie Barbir, Nortel Networks
- Tayeb Lemlouma, INRIA
- Shlomit Ritz Finkelstein
- Jason White, University of Melbourne
- Stan Wiechers, Merkwelt
- Kazuhiro Kitagawa, (W3C Activity Lead)
- Stephane Boyera, (W3C Staff Contact)