The package contains the mobileOK Checker Java library that is a reference implementation of the W3C mobileOK Basic Tests 1.0 standard, and may be used to claim mobileOK conformance, or in a more generic way to build a moki representation of a Web resource and run a series of tests against it.
The Javadoc contains details about the classes of the mobileOK Checker. Methods and fields are not entirely documented.
The library was developped with extensibility in mind. The library in itself only contains tests and material required to check whether a Web resource is mobileOK, but can be easily completed without having to change the code of the library itself to support more URI schemes, different processing rules, different tests, ...
The library may either be used as a real library and hooked up in another application, or as a standalone command-line application.
The main entry-point of the library is the {@link org.w3c.mwi.mobileok.basic.Tester} class. Processing is splitted in 2 steps:
moki representation of the resource is created.moki representation of the resource.The {@link org.w3c.mwi.mobileok.basic.Preprocessor} class handles the pre-processing. Its goal is to generate the moki representation of the resource under test. The moki representation of a given resource contains more information than just the resource in itself. It also contains information about the stylesheets that may be referenced by the resource, the images and objects that may be embedded in the content, and links that may appear in the resource under test.
The moki representation is thus created from a list of retrieved {@link org.w3c.mwi.mobileok.basic.Resource}s. A Resource is defined as:
Each created Resource is:
The processing goes on until all the resources needed to build the final moki representation of the initial resource have been retrieved and decoded.
Resource retrieval is done by a {@link org.w3c.mwi.mobileok.basic.ResourceRetriever}, based on the scheme of the URI to retrieve. mobileOK only applies to HTTP/HTTPS URIs, and so the only implementation in the library is the {@link org.w3c.mwi.mobileok.basic.HttpResourceRetriever} class.
Resource retrieval generates a list of {@link org.w3c.mwi.mobileok.basic.RetrievalElement}s that represent the client/server exchanges needed to retrieve the resource. The last RetrievalElement of the list should be the actual retrieved representation of the resource (or a {@link org.w3c.mwi.mobileok.basic.FailedRetrievalElement} if some network error occurred).
Once retrieved, a Resource is decoded and validated against its supposed content-type. Decoded content is created by a {@link org.w3c.mwi.mobileok.basic.DecodedContentFactory}. Decoded content extends the {@link org.w3c.mwi.mobileok.basic.DecodedContent} class.
The mobileOK-specific decoded content factory is implemented in the {@link org.w3c.mwi.mobileok.basic.MobileOKDecodedContentFactory} class. It creates various types of decoded content depending on the context that gave birth to the resource and on the content-type of the retrieval representation:
image/gif imagesimage/gif imagesThese classes can be serialized to their moki representation through a call to the {@link org.w3c.mwi.mobileok.basic.DecodedContent#toMokiNode(Document, Node)} function.
Once decoded, a Resource is parsed by one or more {@link org.w3c.mwi.mobileok.basic.ResourceExtractor}(s) to extract additional resources that need to be retrieved to build the final moki representation of the initial resource. Each ResourceExtractor should handle one type of resources to extract.
mobileOK defines the following resource extractors:
The list of extractors that are applied to resources may be overridden prior to running the pre-processing.
Note extractors create new resources that are in turn retrieved, decoded and parsed.
The Checker simply applies a list of {@link org.w3c.mwi.mobileok.basic.TestImplementation}s to the moki representation created during the pre-processing step.
A TestImplementation must return a {@link org.w3c.mwi.mobileok.basic.TestResult} that will be used to generate the final report returned by the Checker.
The list of tests to apply may be overridden prior to running the Checker.
Although the mobileOK Checker library was developped as a reference implementation of the mobileOK standard, the library was written so that it can be used as a more generic resource checking framework. Many common needs that extend the purpose of the mobileOK standard can be implemented without having to change code in the library. If you think your specific need cannot be addressed without tweaking the code of the library itself, feel free to discuss it on the public-mobileok-checker@w3.org mailing-list. We would be happy to make the library more generic.
The flexibility comes from the fact that the configuration of the checker allows anyone to override mobileOK-specific settings. The configuration parameters are defined in the {@link org.w3c.mwi.mobileok.basic.TesterConfiguration} class.
The following sub-sections describe potential needs you may have, along with possible implementation solutions that do not require changes in the code of the library. The overall flexibility is somewhat slightly reduced by the schema of the moki representation. The schema may have to be updated in a future release to describe resources in a more generic way.
The mobileOK Checker uses specific values for the User-Agent, Accept, and Accept-Charset HTTP headers, as defined in the HTTP Request section of the mobileOK standard. To override these default values, simply define the new values when creating the instance of the TesterConfiguration class that will be used by the Checker, using the keys defined in {@link org.w3c.mwi.mobileok.basic.HttpResourceRetriever}:
Tests must implement the {@link org.w3c.mwi.mobileok.basic.TestImplementation} interface. The list of tests that need to be applied needs to be defined when the configuration of the Checker is set anyway, so you simply need to define your own list of tests to have them run on the moki representation of the resource under test.
{@link org.w3c.mwi.mobileok.basic.MobileOKConfiguration#getMobileOKTests()} returns the mobileOK-specific list of tests.
Let's say you want to add support for the file scheme. You need to:
FileRetrievalElement class that implements the {@link org.w3c.mwi.mobileok.basic.RetrievalElement} interfaceFileResourceRetriever class that implements the {@link org.w3c.mwi.mobileok.basic.ResourceRetriever} interface and generate a list of FileRetrievalElementsFileResourceRetriever when appropriate. The other schemes (http/https in practice) may be delegated to the {@link org.w3c.mwi.mobileok.basic.MobileOKResourceRetrieverFactory} classmoki representation of the resource under testLet's say you want to add support for image/png images. You need to:
PngImageContent class that extends {@link org.w3c.mwi.mobileok.basic.ImageContent} (or directly {@link org.w3c.mwi.mobileok.basic.DecodedContent} depending on your needs)PngImageContent when necessary. The newly created factory class may rely on the {@link org.w3c.mwi.mobileok.basic.MobileOKDecodedContentFactory} for all the other cases.image/gif nor image/jpeg{@link org.w3c.mwi.mobileok.basic.XhtmlContent} and {@link org.w3c.mwi.mobileok.basic.CssContent} derive from {@link org.w3c.mwi.mobileok.basic.TextContent} that only truly supports UTF-8. There is no easy way to add support for additional encodings for the time being. You would need to implement a new class that extends TextContent, and thus re-implement XhtmlContent and CssContent.
Support for an explicit list of encodings will probably be added to the TextContent class in some future release of the library.
Parsing of decoded resources to extract additional resources rely on a list of {@link org.w3c.mwi.mobileok.basic.ResourceExtractor}s. Again, all you have to do if you need to change or complete the extraction rules defined in mobileOK is to set your own list of ResourceExtractors that the Checker will use.