RE: [widgets] CCPP in widgets, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD

Hi Marcos,
Responding a little late (vacations etc),

The CCPP use I've proposed is fairly simple, ala the delivery of a link to a capabilities document that is hosted on a web server, and semantically useful. This is what mobile devices have done for years via the OMA UAProf (using the "x-wap-profile" header over-the-air, which is sometimes mapped to the "profile" header in WAP gateways), and while not universal and not without limitations (some of which we are addressing via OMA DPE, W3C MWI/DDWG, and W3C UWA), it represents the only semantically useful way to disclose detailed application characteristics (at least widely deployed and used).

Note that the "must" is to the "conforming specification" (it must include this requirement) but the level of the requirement in the conforming specification is "should" (there are, understandably, technical limitations in some cases).

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Marcos Caceres [mailto:marcosscaceres@gmail.com] 
Sent: Thursday, August 14, 2008 12:11 AM
To: Sullivan, Bryan
Cc: Arthur Barstow; Mobile Web Best Practices Working Group WG; Web Applications Working Group WG
Subject: [widgets] CCPP in widgets, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD

Hi Bryan,
I'm wondering if you could provide us more details about the following
requirement:

> Rxx. User-Agent Profile Header
> A conforming specification must specify that the widget should
> identify its capabilities in HTTP requests through the Profile header
> as described by [CCPPexchange]
> (http://www.w3.org/TR/NOTE-CCPPexchange).
>
> Motivation:
>
> Current development practice or industry best-practices, interoperability.
>
> Rationale:
>
> To provide the ability for web servers to determine if it is possible
> to serve the widget, or to adapt to the capabilities or special
> requirements of the widget, using semantic methods based upon detailed
> capabilities information provided by the widget.

I haven't seen CCPP used anywhere in the widget space. I'm wondering
if you could provide some more use cases for this requirement? It
seems a bit strong to have this a "must" requirement particularly as
CCPP exchange seems to add quite a bit of complexity to
implementations.

Kind regards,
Marcos

On Fri, Aug 1, 2008 at 12:28 PM, Sullivan, Bryan <BS3131@att.com> wrote:
> Hi Art,
> The MWBP WG consolidated comments are attached as a HTML document.
>
> Best regards,
> Bryan Sullivan | AT&T
> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org
> ] On Behalf Of Arthur Barstow
> Sent: Thursday, July 31, 2008 5:25 AM
> To: public-bpwg@w3.org
> Cc: ext Marcos Caceres
> Subject: Fwd: Request for Comments on Widgets 1.0 Requirements Last Call WD
>
>
> This is a reminder August 1 is the end of the comment period for the Widgets
> 1.0 Requirements Last Call Working Draft.
>
> -Regards, Art Barstow
>
>
> Begin forwarded message:
>
>> From: Arthur Barstow <art.barstow@nokia.com>
>> Date: June 26, 2008 4:46:23 PM EDT
>> To: public-bpwg@w3.org
>> Cc: Marcos Caceres <m.caceres@qut.edu.au>
>> Subject: Request for Comments on Widgets 1.0 Requirements Last Call WD
>>
>> Dan, Jo, MWBP WG,
>>
>> On June 25 the Web Applications WG published a Last Call Working Draft
>> of the Widgets 1.0 Requirements document:
>>
>> [[
>> <
> http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/>
>> Abstract: This document lists the design goals and requirements that a
>> specification would need to address in order to standardize various
>> aspects of widgets. Widgets are small client-side Web applications for
>> displaying and updating remote data, that are packaged in a way to
>> allow download and installation on a client machine, mobile phone, or
>> mobile Internet device. Typical examples of widgets include clocks,
>> CPU gauges, sticky notes, battery-life indicators, games, and those
>> that make use of Web services, like weather forecasters, news readers,
>> email checkers, photo albums and currency converters.
>>
>> Introduction: A widget is an interactive single purpose application
>> for displaying and/or updating local data or data on the Web, packaged
>> in a way to allow a single download and installation on a user's
>> machine or mobile device. A widget may run as a stand alone
>> application (meaning it can run outside of a Web browser), or may be
>> embedded into a Web document. In this document, the runtime
>> environment on which a widget is run is referred to as a widget user
>> agent and a running widget is referred to as an instantiated widget.
>> Prior to instantiation, a widget exists as a widget resource. For more
>> information about widgets, see the Widget Landscape document.
>> ]]
>>
>> We would appreciate any comments your WG has on this LC document,
>> especially those requirements relevant to your WG's domain/scope.
>> The comment period ends 1 August 2008.
>>
>> -Regards, Art Barstow
>>
>
>
>



-- 
Marcos Caceres
http://datadriven.com.au

Received on Wednesday, 3 September 2008 23:20:37 UTC