Re: [widgets] OMTP input to W3C Widget Requirements (2 of 2)

Hi Doug, All,
below is the plain text edition of the email. It can also be found in
the archive:

http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0302.html

---

Dear Art, Marcos and all,



Please find attached the second set of OMTP BONDI input to the W3C Web
Applications WG Widget Requirements last call as outlined in my last
email. The relevant text from the document is extracted below:



Expressing Widget Dependency Information in Widget Packaging



Introduction

OMTP is a forum backed by many of the largest mobile operators and has
members from many hardware and software vendors across the value
chain.

It was set up with the aim of gathering and driving mobile terminal
requirements to ensure consistent and secure implementations, thereby
reducing fragmentation and simplifying the customer experience of
mobile data services. OMTP recommendations benefit carriers, content
providers, middleware vendors and handset manufacturers to develop
open and compatible mobile devices.  OMTP have created their BONDI
initiative to specifically address the problem of fragmentation in the
evolution of the mobile web and to ensure the protection of the user
from malicious web based services. The BONDI initiative will be
delivering documentation throughout 2008 with the aim of driving
activities in other appropriate standardisation and industry bodies
such as W3C.

Devices supporting some of the features of BONDI will become available in 2009.



This proposal is intended as input to the W3C Web Applications work
group and represents a snapshot of current discussions on including
Widget Dependency Information for both heterogeneous (e.g. Mobile) and
homogeneous (e.g. PC) environments in the Widget Configuration
Document as defined in the W3C Widget Packaging and Configuration
specification (Section 6: Configuration Document).






Terminology




The following terms are used in this document:



Widget Package - A collection of resources required by a widget
(including a Widget Configuration Document) that is packaged for
distributive purposes (from W3C).



Widget Configuration Document - an XML document that has <widget> as
its root. Used to describe the configuration of a Widget Package (from
W3C).



Widget Dependency Information - a combination of Resource Information
and Device Capability Information that may be included in a Widget's
Configuration Document. Widget Dependency Information is a
super-component of Resource Information and Device Capability
Information.



Resource Information - a collection of references and/or inferences to
External Widget Resources (e.g., Widget Packages, APIs, Javascript,
CSS, XSLT files and packages) that are not included in a Widget's
Packaging. Resource Information can be mandatory or optional (see
definitions in proposal below). Resource Information is a
sub-component of Widget Dependency Information.



Device Capability Information - a collection of references and/or
inferences to Device Capabilities either mandatory or optional (see
definitions in proposal below) to provide the functionality of a
widget. Device Capability can be hardware-based (e.g., Operating
System, Provision of device features such as Camera, etc) and/or
software-based (e.g., Specific Browser is available, Specific codec is
available, etc). Resource Information can be included either as
required (mandatory) or optional in order to provide the functionality
of a widget. Device Capability Information is a sub-component of
Widget Dependency Information.






Requirements




Widget Dependency Groupings



The Widget Dependency Information required in Widget Packaging falls
in to two categories:



1.	Resource Information. External Widget Packages, Device APIs
(Address Book API, Location API, etc) / Non-Device APIs (e.g.
Javascript Toolkits such as Dojo, Yahoo UI, etc) and other web-based
resources (e.g., CSS, XSLT, Folders) required to provide the
functionality of a widget.
2.	Device Capability Information. Minimum environment configuration
required to provide the functionality of a widget (e.g., a camera, a
particular sub-class of device, etc).



In addition, each component of Widget Dependency Information should either be:



1.	Mandatory - a Resource must be present to install (if required),
load and run the core features of the widget. In the case that a
mandatory dependency cannot be provisioned a fatal error may occur.
2.	Optional - a Resource may be present but could be provisioned later
and/or at runtime or not at all to run peripheral / non-core
functionality of the widget. In the case that a optional dependency
cannot be provisioned a non-fatal error may occur.



The W3C Widget Packaging specification may wish to define how the
widget handling environment will treat dependencies marked as
Mandatory and Optional.



Resource Information and Device Capability Information requirements
are discussed below.



Widget Dependency Information



A widget developer should include all Widget Dependency Information in
their widget configuration document.



By including this information it is foreseen that the widget developer
will be improving the overall experience for their consumers by
allowing the intended device to check if the required dependencies are
provisioned and/or available to be provisioned prior to the
provisioning of the full widget.



By specifying the Widget Dependency Information in the Configuration
Document it may be possible for a consuming device to query the
Configuration Document either prior to download of the entire widget
package OR prior to installation/execution of a widget once it has
been downloaded to a device. This may be particularly useful in
environments that exhibit limited bandwidth and/or where cost is
incurred in the download of data (e.g., mobile environments). It may
also be used to manage user expectations that the widget will work on
their intended device. A user may have the ability to check if the
intended widget is likely to run on the intended device prior to
incurring the cost and inconvenience of downloading, installing and/or
executing the full widget package.



The Widget Dependency Information may be used by the consuming device
to make decisions on which resources the widget is allowed to use. For
example, access to resources declared in the Widget Dependency
Information may be allowed or denied according to the security policy
defined on the device. A consuming device may also allow access to
resources that are requested programmatically but not declared in the
Widget Dependency Information.



It is recommended that developers include all Widget Dependency
Information in their Widget Configuration Document to aid the widget
provisioning process. The security impact of omitting resources the
Widget Dependency Information is currently under discussion within
BONDI. For example, failure to declare a widget dependency may result
in the device denying widget access to the omitted dependency.

The intention is that Widget Dependency Information in a Widget's
Configuration Document shall not infer any specific means of enforcing
security.



Resource Information



It should be possible to reference multiple external Widget Resources
in a Widget's Configuration Document. External Widget Resources may
include Widget Packages, Javascript files, Javascript/Non-Javascript
APIs, CSS files, XSLT files and Folders. The reference to any of these
Widget Resources must be possible by either:



§  direct reference to the actual location of that resource (e.g. the
URL where the resource resides); OR by,

§  indirect inference to the resource type, class or unique identifier
(e.g. to allow a third-party mechanism to infer the required resource
from a selection of similar resources intended for different platforms
and environments).



It shall be possible to specify the version / revision number of a
resource. The version or revision number can be either a single value
(e.g. v1.5.3) or bounding values (e.g. v1.5.3 to v1.7) that are
compatible with the intended widget.



It shall be possible to specify a friendly (display) name for each
Resource Dependency required.



It shall be possible to state whether a Resource Dependency is
Mandatory or Optional for installation and/or execution of the
intended widget. The intention is to enable developers to
programmatically provide fail-safe functionality (i.e., Exception
Handling) when Optional Resource Dependencies are not present on the
device. For example, if the Location API is not installed on the
intended device, a Widget will can still execute and is able to
display maps in the widget but cannot pinpoint the user's location as
part of its function.



It may be possible to indicate where a Resource Dependency should be
placed in relation to the Widget Package once it has been provisioned
on a device (e.g., Referred Javascript files may be required at a
certain point in the relative widget directory path).



It may be possible to include a hash checksum of the external
dependency for each External Resource included in the Configuration
Document. This may be used by a device to check the integrity of an
external dependency prior to provisioning of the external resource.



Device Capability Information



It should be possible to reference multiple Device Capabilities (e.g.,
Device Type, Operating System, Peripheral Device Support, etc) in a
Widget's Configuration Document. This may be based on the
specifications provided by the W3C Ubiquitous Web Applications Working
Group on Delivery Context Ontology, Interfaces and Functions or some
equivalent device capability profiling initiative.



It shall be possible to specify an exact match requirement on Device
Capability required by a Widget. By this we mean that it should be
possible to specify whether a Device should match exactly the
information provided in the Device Capability Information to ensure
proper function.



In the case where an exact match is required on an abstract Device
Capability node, a Boolean matching expression may be used to indicate
if the required Device Capability is available (e.g., an intended
device must have a browser = true, rather than a requirement on a
specific browser being available).



It shall be possible to specify a bounding requirement on Device
Capabilities required. It should be possible to specify whether the
Device should match based on being greater than, less than or equal to
a range of responses available (e.g., OS version is less than or equal
to v8 and greater than v6).

--------  END OF DOCUMENT  --------









Thanks,





David.



David Rogers
OMTP Director of External Relations
m: +44 (0) 7771 838197  david.rogers@omtp.org
skype: dg.rogers

linkedIn: http://www.linkedin.com/in/davidrogersuk


OMTP Ltd.
Marble Arch Tower
55 Bryanston Street
London
W1H 7AJ

www.omtp.org

P Please consider the environment - don't print this mail unless you
really need to...

Received on Saturday, 2 August 2008 00:13:24 UTC