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

Hi, David-

The preferred format for comments is actually just plain email.  Many of 
the people on this list use email clients that only display as text.

I understand that many organizations use formats such as Word or PDF for 
official liaisons, but W3C prefers more accessible plain text or HTML 
formats.  It is much easier to process and respond to comments that are 
sent as text email.  It is also useful to break comments down to one 
topic per email, to facilitate threaded conversations.

If you could please resend your comments as one or more emails in 
plain-text form, that would be very helpful and greatly appreciated.

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

David Rogers wrote (on 8/1/08 7:41 AM):
> 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 Friday, 1 August 2008 17:14:51 UTC