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 | ATT
-Original Message-
From: Marcos Caceres [mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] wrote:
Hi Art,
The MWBP WG consolidated comments are attached as a HTML document.
Best regards,
Bryan Sullivan | ATT
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of Arthur Barstow
Sent: Thursday, July 31, 2008 5:25 AM
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Date: June 26, 2008 4:46:23 PM EDT
To: [EMAIL PROTECTED]
Cc: Marcos Caceres [EMAIL PROTECTED]
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
