W3C mobileOK Scheme 1.0

Editor's Draft 6 August 2008

This version:: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/20080806
Latest Editor's version:: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/latest
Previous version:: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/mobileOK-Trustmark/080408
Editors:: Phil Archer, Family Online Safety Institute; Jo Rabin, dotMobi
Previous Editors:: Sean Owen, Google; Charles McCathieNevile, Opera Software

Abstract

mobileOK allows content providers to promote their content as being suitable for use on mobile devices. From a user's perspective, mobile search engines can increase the rankings of mobile friendly content so provide swifter access to more usable content. This document sets out exactly what a claim of conformance with mobileOK means and how to make it.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is an Editor's Draft of the W3C MobileOK Scheme. It follows a period of evolution during when the Working Group considered defining two levels of mobileOK conformance, each with its own set of tests. mobileOK is presented here as a simplified and unified scheme in which the relationship with the Best Practices document, the Basic Tests and the Checker is made explicit. It represents substantial change from previously published expectations of mobileOK.

The Working Group expects to publish this as a Note and not as a Recommendation track document.

Publication as a Editor's Draft does not imply endorsement by the Best Practices Working Group or by W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the Mobile Web Best Practices Working Group as part of the Mobile Web Initiative. Please send comments on this document to the working group's public email list public-bpwg-comments@w3.org , a publicly archived mailing list.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Introduction

mobileOK is designed to improve the Web experience for users of mobile devices and to reward content providers and service operators that adhere to good practice when developing for mobile. It is a claim that content dereferenced from a given URI conforms to mobileOK Basic 1.0 Tests [mobileOK] and hence will provide at least a functional user experience on mobile devices. The claim may be made by the content publisher themselves or any third party.

The sole basis for making a legitimate claim of conformance with mobileOK is adherence to the mobileOK Basic Tests [mobileOK]. That Recommendation sets out a number of tests that content must pass in order to be confident of displaying well across a wide variety of basic mobile devices.

mobileOK Basic is itself based on Mobile Web Best Practices [BP], which gives a set of 60 guidelines for making content work well across a wide variety of mobile devices. mobileOK turns the Best Practice Statements into machine processable deterministic tests applicable to baseline devices, and specifically to the hypothetical user agent called the "Default Delivery Context" (DDC).

A claim of mobileOK may only be made of a URI that when dereferenced in the manner described in [mobileOK] yields content that passes all the mobileOK Basic Tests.

A suite of software known as the mobileOK Checker, has been developed to provide automated checking of conformance. This tool is also available via a Web interface as part of the W3C Validator [CHECK].

Claims of conformance with mobileOK should be discoverable primarily by machines and, optionally, by humans. In practice, this means applying metadata to the content and, where relevant, displaying the mobileOK logo. The latter is most appropriately used on desktop representations of a resource for which a mobileOK representation is also available. In such a situation it acts as a signal to a desktop user that the content or service they're using is also available on a mobile device. Display of the mobileOK logo is usually inappropriate on a mobile device since whether the content is usable on their device or not will be fully apparent without it.

mobileOK says nothing about what may be delivered to non-mobile devices; furthermore, mobileOK 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, is or it not appropriate for children etc.

1.1 Who is mobileOK For?

mobileOK has value at many points in the content authoring and delivery chain for mobile devices. These are developed in more detail in the Use Cases, but the main audiences are briefly listed here:

1.2 Relationships to Other Recommendations

1.2.1 Relationship to mobile BP

Not sure how much detail we need here, could be that we flesh out the intro a bit more.

1.2.2 Relationship to Basic Tests

Not sure how much detail we need here, could be that we flesh out the intro a bit more.

1.2.3 Relationship to mobileOK Checker

Not sure how much detail we need here, could be that we flesh out the intro a bit more.

2. Claiming mobileOK Conformance

As noted above, a claim of conformance with mobileOK should be made in such a way that is machine-readable which, in practical terms means associating the mobileOK resource with metadata in some way. Visual, i.e. human readable, cues that a given URI is capable of yielding mobileOK content may also be provided but this is secondary.

It is noteworthy that a claim of conformance with mobileOK is always associated with the person, organization or other entity that makes it. Content providers should be mindful of the (obvious) fact that if an end user regards "Organization A" as more trustworthy than "Organization B," then a claim of mobileOK conformance made by organization A will have the greater value.

Need to explain somewhere how it can be that two different orgs can express an opinion, maybe move the above para.

2.1 mobileOK in RDF

To support claims of conformance with mobileOK, we define a one-class RDF vocabulary. The namespace is http://www.w3.org/2008/06/mobileOK# and the class has the name Conformant. The following RDF triple therefore asserts that some URI, u is mobileOK conformant:

2.2 Claiming mobileOK Conformance using POWDER

The Protocol for Web Description Resources [POWDER] provides a means through which a claim of mobileOK conformance may be made about many resources at once, such as all those available from a Web site. Importantly, POWDER also provides a means of identifying the person, organization or entity that made the claim. These two features make POWDER's Description Resources an ideal transport mechanism for mobileOK conformance claims (mobileOK was a key use case for POWDER).

In the following (fictitious) example, on 25th June 2008, the organization described at http://www.example.com/company.rdf#me claimed that all the resources available from example.com were mobileOK.

1  <?xml version="1.0"?>
2  <powder xmlns="http://www.w3.org/2007/05/powder#">

3    <attribution>
4      <issuedby src="http://www.example.com/company.rdf#me" />
5      <issued>2008-06-25T00:00:00</issued>
6      <supportedby src="http://validator.w3.org/mobile/" />
7    </attribution>

8    <dr>
9      <iriset>
10       <includehosts>example.com</includehosts>
11     </iriset>

12     <descriptorset>
13       <typeof src="http://www.w3.org/2008/06/mobileOK#Conformant" />
14       <displaytext>The example.com webiste conforms to mobileOK</displaytext>
15       <displayicon src="http://www.w3.org/ICONS/mobileOK.png" />
16     </descriptorset>
17   </dr>

18 </powder>

http://www.example.com/company.rdf#me (line 4) should lead to an RDF resource that describes the entity (either the foaf:Agent or dcterms:Agent) that provided the Description Resource. It is open to that organization to provide authentication methods to support its claim of mobileOK conformance. Note also in line 6 that POWDER's supportedby element has been used to refer to the mobileOK Checker, the implication being that the content of the described Web site has been tested using the Checker. Lines 14 and 15 provide textual and graphical data that user agents may display to end users.

2.3 Claiming mobileOK Conformance using RDFa

Note that the following would actually make the resource not mobileOK Basic, so furhter expalnation needed here

RDF Annotation [RDFa] can be used to embed a claim of mobileOK conformance directly in an XHTML document as shown in the following example.

The version attribute on the html element is optional but is a clear signal to a processor that the document contains RDF annotations. The typeof attribute on the head is a shorthand way used in RDFa to assert the rdf:type relationship so that an RDFa-aware user agent will extract the RDF triple:

i.e. that the current document is an instance of the class of resources that conform to mobileOK.

Note that using RDFa to claim conformance with mobileOK implies that the entity making the claim is the content creator. Furthermore, user agents are given no clue as to how they may authenticate the claim. Therefore this method should not be seen as an equivalent method to using POWDER.

2.4 The mobileOK Trustmark

3. Change Log

Basically re-wrote more or less everything, kept 'who is it for' and moved the use cases to an appendix. introduced the RDF vocab, POWDER and RDFa examples.

4. Acknowledgements

The editors would like to thank members of the BPWG for contributions of various kinds. and acknowledge significant written contributions from:

5. References

Appendix A: Use Cases and Requirements for mobileOK

A.1 Use Cases

A.1.1 Certification Provider

Ace Content Provision has a substantial desktop presence and wants to reach a mobile audience with its new service. Naturally it is keen to have its content display as well as possible on mobile devices and so develops its web site in accordance with the Best Practices.

Ace is keen to advertise the existence of its mobile tailored services and show that its high quality brand value extends to this area. It believes that the mobileOK claim will carry more weight, especially among search engines tuned to mobile devices, if endorsed by a trusted third party. This is particularly true of those claims related to non machine-testable aspects of mobileOK.

One of Ace Content Provision's main distribution channels is a mobile network operator that requires content on its portal to be certified as being mobileOK by one of a short list of preferred certification providers. In order to offer a flexible and competitive service, the certification provider offers several levels of service. These range from automated checking of machine-testable Best Practices through to frequent checks by human reviewers. For Ace Content Provision, this is worthwhile as an ongoing service. For other providers the balance of cost and assurance is best met by assessment at service launch and on major update thereafter.

A.1.2 Content Adaptation

A content developer wants to create high quality user experiences on multiple devices. Sensibly, the developer chooses to use an adaptation approach which supports mobileOK. They create device independent content together with styling and layout, using W3C standards such as DIAL and CSS.

When a device makes a request, the adaptation system uses the various materials provided by the author to construct and deliver an appropriate page that conforms to mobileOK. It automatically marks the page with the mobileOK label. If the author has requested inclusion of the mobileOK logo, the adaptation system adds it to the page.

A.1.3 Content Syndication / Aggregator

A content syndicator / aggregator gets content from many sources. Some may be internal to the company, some may be external partner companies; in fact some content from partners can be sent directly to the client using inclusion via iFrames for example. In short, the content syndicator has, in some sense, very little control over the syndicated content.

Since the mobileOK label can only apply to the full page delivered to the end user, the content syndicator must ensure in some fashion that the content from partners does not invalidate the label. Thus the syndicator wants partners to make mobileOK conformance claims about their content to which they can be held accountable. This may include information about who is making the claim.

A.1.4 Individual Content Author

Joe Lambda wants to make a web site about his holidays for a couple of friends to follow, and be sure that it can be read on mobile phones. He reads the mobileOK documents, and makes sure he follows the requirements, so he can put the mark on his pages and his friends can check they will work before they download them.

The use case requires no-cost use of the label and that the label should be sufficiently simple that it can be added by the normal processes used for web development.

It would be nice to have tools to assist in testing, to add the label when tests have been met, and to note that something important has changed and that content needs to be re-tested.

A.1.5 Search Engine

A search engine wants to provide search services over mobile content for the benefit of its mobile users. When crawling the web it wants to easily discover all content that is usable to a mobile device, especially content designed specifically for mobile devices. It wants to evaluate how good the mobile content is and index it. When serving queries from mobile devices, it wants to return the best mobile content that matches the query.

One might imagine several things a search engine would want from the mobileOK label. The one that seems vital to making mobileOK useful to the search engine is detecting that a page at least says it is mobileOK and thus is trying to be a good mobile page.

There are a couple things that would be nice to have. First is an easy way to discover many mobileOK resources at once -- for example all mobileOK URL in a directory or domain. Next is a way to at least partially verify that a page does comply with mobileOK tests as claimed. Last is a way to identify claims of partial conformance, so that the search engine can customize its offerings to a particular profile of requirements. For example in a real use case, I have a phone that has a certain set of constraints, but is much more powerful than the baseline device -- specifically I don't care whether content relies on JavaScript or not, since my browser supports it, so I want content that meets various other requirements whether or not they meet any requirements on script.

A.1.6 Software Developer

A software developer is prioritizing fixing problems in rendering content appropriately. Being able to gather a collection of mobileOK content provides a useful test set, that allows prioritizing development based on what we trust to be the approach to content that more people will be using -- chasing a growing, rather than diminishing, market.

So the use case would require a discoverability mechanism for mobileOK content, and people using mobileOK.

It would be very helpful to have some reasonably reliable and simple method of verifying the claim.

A.1.7 Operator

An operator might use the mobileOK label to predict which content and sites would work better on the mobile devices of its customers. By detecting the existence of this label, an operator might apply different prices to the data traffic, provide better network caching for those sites and in some cases enrich the communication (policies at network transcoders, more parameters, etc.).

A.1.8 Accepting or Rejecting a mobileOK claim

An agent is set to crawl the Web to collect content to be presented in an ATOM feed that is updated daily. Several criteria are used sequentially to decide whether content resolved at a particular URI should be included or not, including mobileOK conformance.

The crawler detects a mobileOK label describing content at http://mobile.example.org. The label itself comes from a server the crawler recognizes as being trusted. Although the label is digitally signed, for efficiency, this is not checked before the crawler passes the content on to the next stage in the evaluation process for possible inclusion in the ATOM feed.

At http://new.example.org content is again described by a mobileOK label. This time, however, the label is on a server the crawler has not encountered before and so it does not know, yet, whether to trust the claims or not. The data in the label carries a valid digital signature and so the content is passed on to the next stage in the evaluation process for possible inclusion in the ATOM feed. If it is subsequently included, the newly discovered server will be added to the list of trusted sources as will the digital certificate.

Finally the crawler discovers content at http://bad.example.org that is again claimed to be mobileOK. The server is not recognized and the digital signature is not valid for the data in the label. It is therefore rejected and content is not forwarded to the next stage in the evaluation process.

W3C mobileOK Scheme 1.0

Editor's Draft 6 August 2008

Abstract

Status of this Document

Table of Contents

Introduction

1.1 Who is mobileOK For?

1.2 Relationships to Other Recommendations

1.2.1 Relationship to mobile BP

1.2.2 Relationship to Basic Tests

1.2.3 Relationship to mobileOK Checker

2. Claiming mobileOK Conformance

2.1 mobileOK in RDF

2.2 Claiming mobileOK Conformance using POWDER

2.3 Claiming mobileOK Conformance using RDFa

2.4 The mobileOK Trustmark

3. Change Log

4. Acknowledgements

5. References

Appendix A: Use Cases and Requirements for mobileOK

A.1 Use Cases

A.1.1 Certification Provider

A.1.2 Content Adaptation

A.1.3 Content Syndication / Aggregator

A.1.4 Individual Content Author

A.1.5 Search Engine

A.1.6 Software Developer

A.1.7 Operator

A.1.8 Accepting or Rejecting a mobileOK claim

A.2 Requirements for mobileOK