W3C mobileOK Scheme 1.0

1.1 What is mobileOK?

mobileOK is a scheme comprised of two content labels, called mobileOK Level 1 (working name) and mobileOK Level 2 (working name) . These machine-readable labels may be applied to content to indicate that the content and its delivery pass a suite of tests based on the Mobile Web Best Practices document [BestPractices] ; consequently their presence implies that users accessing the content from a mobile device may expect an effective and usable interaction.

The "mobileOK Level 1" and "mobileOK Level 2" working names are only placeholders. The group wishes to assign names that indicate that the first level represents a first step towards creating an effective user experience for mobile users, and that the second level represents a substantially larger step towards that end. Names like "mobileOK Core" and "mobileOK Basic" have been discussed for the first level, and "mobileOK" or "mobileOK Complete" for the second level.

The labels apply to a URI (or group of URIs), meaning that under the right circumstances, accessing that URI will retrieve content that conforms to a set of tests defined by mobileOK, and that its delivery also conforms. That is to say, the labels do not apply solely to content or document instances. Many best practices relate not just to the document (e.g. well-formed markup), but to how it is delivered to a mobile device (e.g. caching headers in the HTTP response). For convenience, this document will hereafter refer to "mobileOK content" with the understanding that mobileOK labels apply to more than just the content itself.

mobileOK Level 1 tests are based upon a limited subset of the Mobile Web Best Practices and are all machine-verifiable. Conformance to mobileOK Level 1 requirements is thus simple to check or verify. Content bearing this label has taken basic steps to provide an effective experience for mobile users.

mobileOK Level 2 tests are based upon a significantly larger subset of the Mobile Web Best Practices, and are a superset of mobileOK Level 1 tests. These tests are not all machine-verifiable and require verification by a human. Content bearing this label has taken significant steps to provide an effective experience for mobile users.

Note that not all Mobile Web Best Practices map to a test in mobileOK conformance tests. Some best practices, like EXPLOIT_DEVICE_CAPABILITIES , are advisable but do not meaningfully translate into concrete tests, whether machine- or human-verifiable.

mobileOK says nothing about what may be delivered to non-mobile devices from that URI; however, note that a mobileOK URI must return mobileOK content by default if the nature of the user agent (desktop or mobile) cannot be reliably determined.

A mobileOK label also does not imply endorsement or suitability of content. For example, it must not be assumed that mobileOK content is of higher informational value, is more reliable, more trustworthy or is appropriate for children.

1.2 Why mobileOK?

The Mobile Web Best Practices document [BestPractices] and Techniques document [Techniques] have already enumerated much of what it takes to deliver an effective user experience to users of mobile devices. mobileOK complements this effort by providing machine-readable labels for mobileOK content. The presence of standard mobileOK labels may catalyze production of effective content for mobile users, and tools to create and detect this content, and even create demand for this content. It is hoped that this ultimately improves the quantity, quality and usability of Web content available to mobile devices.

1.3 Who is mobileOK for?

mobileOK has value at many points in the content authoring and delivery chain for mobile devices:

Content Developers

Developers who create content which follows Mobile Web Best Practices, and which passes tests outlined in this document, have added value for mobile users. They can advertise this to consumers of their content through the mobileOK labels.

Tools

Likewise, tools that can produce, parse, adapt or manipulate mobileOK content (browsers, content management systems, authoring tools, content adaptation systems, etc.) add value for authors, and can advertise this capability.

Content Providers

Sites that are concerned with providing a quality experience to mobile users can look for a mobileOK label when acquiring content and tools.

Content Discovery Services

Search engines, content aggregators, and other services which locate content for mobile devices can look for a mobileOK label and possibly prioritize mobileOK content.

Content Consumers

End consumers of content may also treat mobileOK content differently, preferring sites that advertise mobileOK content.

Certification Provider

Certification providers may wish to offer to certify conformance to mobileOK tests; entities such as content providers that come to rely on mobile content may require more verification that content they provide is mobileOK.

1.4 Form of the mobileOK label

This section still subject to significant change as the form of the mobileOK labels has not been finalized.

The precise form of the mobileOK label has not yet been finalized, however, MWBP notes the work of the [WCL] . The abstract model put forward by the WCL-XG fits the mobileOK use case; indeed, its first use case is the mobileOK label. It is reasonable therefore to use the WCL-XG model in this Working Draft, noting that its final report is likely to be published in the very near future.

This section outlines the form of the mobileOK label with examples. A full technical specification may be found in the Label Technical Specification below.

The abstract model for mobileOK exists independently of any particular technology. However, the expectation is that mobileOK will typically be encoded in [RDF] and delivered in an RDF instance that has the following basic structure:

• Metadata
  • Who created the mobileOK label?
  • When?
• Scope
  • A list of domains to which the mobileOK label can be applied
  • An optional set of simple rules that determine areas of those domains or individual URIs to which the mobileOK label can be applied
• The Label
  • Classification as mobileOK

For example, assuming suitable namespaces have been declared, an actual mobileOK label for mobileOK level 2 would look like this:

<wcl:ContentLabel rdf:ID="cl_1">
  <mwbp:mok rdf:resource="http://www.example.org/2006/09/mobileOK#level_2" />
</wcl:ContentLabel>

It is an RDF description that includes a URI which, when dereferenced, gives the definition of mobileOK level 2. This definition would be expressed as:

<wcl:ContentLabel rdf:ID="level_2">
  <wcl:include rdf:resource="#level_1" />
  <mok:ACCESS_KEYS rdf:resource="&wcl;true" />
  <mok:AVOID_FREE_TEXT rdf:resource="&wcl;true" />
  ...
</wcl:ContentLabel>

The above says that mobileOK level 2 will include mobileOK level 1 plus a set of atomic descriptors (for tests). The scope of a mobileOK label is defined in a separate block like this:

<wcl:Ruleset rdf:ID="ruleset">
  <wcl:hasScope>
    <wcl:Scope>
      <wcl:host>resources.example.co.uk</wcl:host>
      <wcl:host>resources.example.com</wcl:host>
    </wcl:Scope>
  </wcl:hasScope>
  <wcl:hasDefaultLabel rdf:resource="#cl_1" />
</wcl:Ruleset>

This states that the resources on the two listed hosts are covered and are described by the label with the ID cl_1 by default. There are mechanisms for applying different labels to different URIs and groups of URIs on those hosts but this serves as an adequate introduction.

A third block of data gives information about when the mobileOK label was created and by whom:

<rdf:Description rdf:about="#ruleset">
  <dc:creator>
    <foaf:Organization>
      <foaf:homepage rdf:resource="http://labelauthority.example.org" />
    </foaf:Organization>
    ...
  </dc:creator>
</rdf:Description>

Such a block of data may also link to supplementary information such as an [EARL] test result.

Because the RDF instance as well as the block of data defining the scope of the mobileOK label and the label itself within that RDF instance all have URIs, it is possible to make further statements about them. For example, a content provider may wish to have their conformance with mobileOK to be certified by an independent third party. Such a certificate would take the following form:

<rdf:Description rdf:about="http://resources.example.com/mobileOK.rdf">
  <wcl:certifiedBy rdf:resource="http://certification.example.org" />
</rdf:Description>

Another relevant issue is linkage -- linking content to its mobileOK label. This is one valid way to do it within an XHTML document:

<link rel="meta" href="/mobileOK.rdf" type="application/rdf+xml" />

While this is valid, the link relationship type "meta" is rather loose and a more specific link type is likely to prove useful. The expectation is that a metadata profile will be defined in the WCL group that gives cLabel as a link type. Furthermore, this group, MWBP, will create a mobileOK profile that will reference the WCL profile. An XHTML document that is mobileOK should therefore include the following:

<head profile="http://www.example.org/wcl-profile http://www.example.org/mobileOK#level_2">
  <link rel=""cLabel" href="/mobileOK" type="application/rdf+xml" />
</head>

The actual mobileOK data is in the local file called mobileOK.rdf . The profiles provide a hint to user agents that this information is carried in a Content Label (cLabel) and that the data is relevant to mobileOK. The system is fully extensible so that metadata other than mobileOK may also be contained in the same RDF instance.

Linkage is also possible using HTTP response headers. Indeed, for non-HTML documents this is the only way. The following HTTP response header is semantically equivalent to the previous example.

Link: </mobileOK.rdf>; /="/"; rel="cLabel" type="application/rdf+xml";

Note that content is not mobileOK unless a label has been explicitly applied to it; a resource cannot "accidentally" be mobileOK. For example, if a content provider advertises mobileOK content, then the content itself must bear a machine-readable mobileOK label.

1.5 Requirements

As we begin to define the form of the label, we list possible design goals for the label. Each of these is derived from use cases listed at the end of this document. This section may or may not appear in the final version of this document, and requirements are subject to change.

Machine-discoverable

The mobileOK label must be discoverable by a machine. See all use cases.

Self-labeling

It shall be possible to label content as mobileOK without specialized tools, expending a disproportionate amount of effort, and without the involvement of a third party. Anyone may label content as mobileOK, including its author. See use case A.5.

Third-party labeling

It shall be possible for a third party -- someone other than the author or host -- to claim that content and its delivery are mobileOK. See use cases A.1, A.2, and A.3.

List of mobileOK Resources

It shall be possible to publish and locate listings of one or more resources which bear the mobileOK label. See use cases A.1, A.6.

Partial Conformance

In addition to indicating whether a resource is mobileOK, it shall be possible to indicate partial conformance to the mobileOK test suite, ideally at the level of individual tests. See use case A.5.

Who

It shall be possible to determine who is claiming that the content is mobileOK. See use case A.3.

Version

It shall be possible to determine which version of the mobileOK label (e.g. 2007-01) is being claimed. See use cases A.1 and A.3.

Authenticity

It shall be possible for a third party to verify that a mobileOK claim was actually made by the party named in the claim, perhaps through the use of digital signatures. See use cases A.3, A.8 and possibly A.5.

Non-forgeability

It must be possible to make a mobileOK claim in a way that is very hard, if not impossible, to forge or replicate maliciously. See use case A.8.

2.1 Testing Parameters

Unless otherwise specified, tests should be conducted using the following parameters.

2.2 mobileOK Level 1

This section describes tests in the mobileOK Level 1 conformance suite. Tests are organized by the Best Practice from which they derive.

2.3 mobileOK Level 2

This section describes the additional tests in the mobileOK Level 2 conformance suite; that is, content must conform to Level 1 tests as well.

These tests should be considered particularly subject to change; currently the given definitions cover machine-testable aspects of these tests and not human-testable aspects.

2.4 Best Practices Outside mobileOK Scope

The following Best Practices do not map to a test in either conformance suite. They remain important best practices to be considered by content authors, but do not readily translate into concrete tests.

• BALANCE

• CAPABILITIES

• CENTRAL_MEANING

• CLARITY

• DEFICIENCIES

• SUITABLE

• TESTING

• THEMATIC_CONSISTENCY

  This best practice is under particular consideration for inclusion in mobileOK level 2 subject to agreement on a satisfactory test or set of tests. Tests along the following lines are in consideration:

  When comparing a desktop and mobile presentation of the resource resolved for a single URI:

  1. Logo. Where present, the content provider's logo is the same (although size and position may vary).
  2. Metadata. Except where the metadata refers explicitly to structure and technical characteristics of the resource, it must be identical in both cases. For example, the character encoding may change to suit the delivery context and metadata may say things like "this resource has been optimized for Nokia mobile devices," but things like title, keywords and cLabels must be identical.
  3. Redirect or fail gracefully. When accessing a URI from one class of device it is acceptable to be redirected to a different URI that offers a more suitable representation of the same resource. So, for example, accessing http://www.example.com from a mobile device may redirect to http://www.example.com/mobile/. If redirection is not used and if a service is only available on either a desktop or mobile device, then a message should be displayed explaining this to the user.

• URIS