RE: [widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD

Hi Marcos,
I was starting to respond and thank you for the inclusion in the previous email when I saw this... having been out for vacation etc I did not get a chance to respond earlier.

I would like the opportunity to discuss these in detail and support the rationale on the Widgets call. I don't understand the justification for rejection you have described. Overall the requirements represent the core (a limited set) of some pragmatic considerations that will affect the success of widget frameworks in real-world deployments, especially in the mobile device context.

As you stated: "The main reason for rejecting the feedback was that the proposed requirements were: (a) had limited impact on the actual specs (in normative terms),  (b) were overly prescriptive and should really be left as an implementation detail on which implementations can compete, (c) added complexity on either the client side or the server side."

(a) Is unclear (which specs are you talking about?). The Widget Requirements spec is the one being commented on, and it is giving direction to "conforming specification" writers (presumably in W3C and externally). Several of the proposed additions were written in normative terms and meant to be so.

(b) In which cases were they overly prescriptive. This seems to me to be a value judgment based upon some criteria. The criteria I use is whether there will be significant negative effects on usability, interoperability, or efficiency if the requirements are not supported. Especially in the mobile case, the normative requirements I proposed can be supported in one or more of those terms.

(c) Re complexity, little of value comes free. But overall I don't think any of the proposed normative requirements could reasonably be called complex. I am willing to explain why if given the opportunity.


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

Hi Bryan, MWBP WG,
FYI, we discussed the MWBP input in last nights teleconf:

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

In summary, although I had included most of the requirements proposed
by the MWBP WG in the Requirements document, the WebApps WG members
overrode my decisions and chose not to include your recommended text
into Requirements document. I have now removed the text I added
earlier (below) from the Requirements document. The main reason for
rejecting the feedback was that the proposed requirements were: (a)
had limited impact on the actual specs (in normative terms),  (b) were
overly prescriptive and should really be left as an implementation
detail on which implementations can compete, (c) added complexity on
either the client side or the server side.

If MWBP WG has concerns with the omission of any proposed requirement,
we are happy to discuss anything further to reach consensus before we
take the Requirements document to CR. Please note that WebApps is on
an extremely tight schedule and we intend to move the Requirements to
CR within three weeks; so if we don't hear back from MWBP we will
assume that you are in agreement with WebApp's decisions.

Having said that, I want to say that the feedback from the MWBP WG was
extremely useful because it allowed the WebApps WG to more narrowly
focus the architectural aspects of the Widgets 1.0 family of
specifications. We want to continue coordinate with members of the
MWBP WG on architectural decisions and guidance on best practices for
widgets and mobile-based client side web applications.

Kind regards,
Marcos

On Thu, Aug 14, 2008 at 7:45 PM, Marcos Caceres
<marcosscaceres@gmail.com> wrote:
> Hi Bryan, MWBP WG,
> 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.
>>
>> General comments:
>>
>> Somewhere, perhaps in section 4.2, there should something about how
>> resources (media etc) need to be compatible with the target device
>> types, and that resource dependencies (screen, input device, network,
>> processing, etc.) need to be spelled out. Widgets should be able to
>> express these dependencies in a semantically useful way through a
>> standardized schema and attribute ontologies/vocabularies such as W3C
>> has been working on, e.g. the MWI DDWG's DDR Core Vocabulary, DDR
>> Simple API, and the ongoing work of the UWA's Delivery Context
>> Ontology.
>
> Although these are great technologies and I see the value that they
> could add to Widgets overall, the WebApps Working Group has yet to
> evaluate the suitability of these specification to Widgets. From our
> initial investigation, some of these technologies have the potential
> to significantly complicate widgets as a platform and I am personally
> concerned that they could become a barrier to the adoption of Widgets.
> Personally, I would like to see the progressive inclusion of the
> technologies you mention as they become more prevalent in the mobile
> space and as developers start asking for them. I am also of the
> opinion that our primary focus right now (version 1.0 of Widgets)
> should be on specifying packaging and the core APIs.
>
>>The specific text below related to expression of user agent
>> characteristics (via the User Agent, Accept, and Profile headers in
>> HTTP requests) is important in the meantime as a standardized way to
>> at least disclose web application (and host device) capabilities, but
>> longer term a way of expressing dependencies is important also.
>>
>
> I agree conceptually with what you are saying, though I have concerns
> about the Profile headers side of things.
>
>>
>> Re R16 Visual Rendering Dimensions: the text states that there must be
>> a way of declaring initial dimensions in pixels, which is potentially
>> at odds with the limited canvas available on many mobile devices.
>> Resource/capability expression as described above would at least
>> ensure the dimensions were defined in a standardized way.
>
> The requirement reads "A conforming specification SHOULD specify a
> means for an author to declare the initial visual dimensions for an
> instantiated widget in a way that is device independent (e.g. via CSS
> pixels)."
>
> The requirement does not actually state that it must be be pixels (CSS
> pixels are an example), just that some means SHOULD be provided to
> declare the dimensions.
>
>>
>> Other that described in "R28. Network State Change Events", is there
>> something specific that can be said re requirements supporting widgets
>> that are intermittently connected?
>>
>
> The rationale now reads: "To allow authors to programmatically capture
> when the widget user agent has acquired or lost a network connection,
> particularly for cases when the device intermittently loses and
> regains the network connection."
>
>>
>> Suggestions for specific text:
>>
>>
>>
>> 1) As design goals, a new section 3.1 can specifically introduce the
>> mobile web best practices that W3C has developed / is developing. Here
>> is some proposed text:
>>
>> 3.1 W3C Mobile Web Best Practices
>>
>>
>> Some typical use cases for widgets are similar to use cases for mobile
>> Web browsing, and will benefit from consideration of objectives and
>> constraints similar to the mobile environment, e.g. usability,
>> interoperability, and resource efficiency. In particular, widgets that
>> are used in mobile devices should behave well as mobile web
>> applications,  i.e. as web applications running in mobile devices. For
>> widgets in mobile devices or similar contexts, widget specifications
>> should take into consideration the W3C recommendations in the Mobile
>> Web Best Practices 1.0 and Mobile Web Application Best Practices, and
>> where possible provide enabling capabilities so that widgets can more
>> consistently comply with the recommendations.
>>
>
> I've added the above text to the Widgets 1.0 Landscape document [1],
> but not the the Requirement's document. To add this text would mean
> that I would need to add sections for "relationship to
> internationalization" and "relationship to accessibility" etc.. We
> also want to keep this document as small as possible, which is why we
> have put all definitions and detailed design justifications into the
> Landscape document.
>
>> 2) Add the references:
>> MWBP
>>
>> Mobile Web Best Practices 1.0. J. Rabin, C. McCathieNevile, W3C
>> Recommendation, July 2008. Available at
>> http://www.w3.org/TR/mobile-bp/
>>
>> MWABP
>>
>> Mobile Web Application Best Practices. B. Sullivan. A. Connors, W3C
>> Working Draft (Recommendation), July 2008. Available at
>> http://www.w3.org/TR/mwabp/
>>
>>
>
> I added the references, and the "Current development practice or
> industry best-practices" design goal now reads: "A conforming
> specification needs to consider the development practices currently
> used by widget developers and promote relevant industry
> best-practices, such as [MWBP] and [MWABP]."
>
> <snipped r21as it is now in a different thread>
>
>>
>>
>> 3) Re "R36. Open Default System Web Browser", a proposed modification
>> (in red/underline below):
>>
>> A conforming specification SHOULD specify a means that allows authors
>> to open URLs in a browsing contexts outside the widget engine.
>>
>> Motivation:
>>
>> Current development practice or industry best-practices.
>>
>> Rationale:
>>
>> To allow author to open a URL in the default system web browser. For
>> example, in a news aggregator widget, to allow the end user to
>> navigate to the source of a particular news item. ***Alternatively, if
>> the widget has ability to directly present web content, a specific
>> resource may exceed its capabilities, thus the user can be offered the
>> option of opening the resource in the default system web browser,
>> which may have greater capabilities. ***
>>
>
> I rewrote your proposed text (and included it in the rationale):
> "Alternatively, if the widget deems that a specific content may be
> better experienced outside the context of the widget user agent, the
> user can be offered the option of opening the resource in the default
> system web browser."
>
>>
>>
>>
>> 3) In 4.5 User Agents, add the requirements:
>>
>>
>>
>> Rxx. User-Agent Header
>>
>>
>>
>> A conforming specification must specify that the widget must identify
>> itself in HTTP requests through the  user-agent header, either as the
>> complete header or as an extension to the default user-agent header
>> provided by the runtime environment.
>>
>>
>>
>> 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. For example, a widget may attempt to
>> access a service which is not compatible with the widget, and rather
>> than provide a possibly incorrect response (which could cause further
>> issues with the widget), the web server can provide a specific error
>> response noting the incompatibility.
>>
>
> Ok, I added this requirement with a few minor changes.
>
>>
>>
>>
>
> <sniped CCPP requirement into a separate thread>
>
>>
>> Rxx. Accept Header
>>
>>
>>
>> A conforming specification must specify that if a Profile header is
>> not included in HTTP requests, the widget must include all supported
>> MIME types for widget resources in the Accept header.
>>
>>
>>
>> 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.
>>
>
> Ok, added this requirement too with a few minor stylistic changes.
>
>>
>> Rxx. Default Use of Runtime Environment Configured Proxy
>>
>>
>>
>> A conforming specification must specify that by default, widget HTTP
>> requests must be made through the proxy server (if any) configured for
>> use in HTTP requests issued through the runtime environment or host
>> device.
>>
>>
>>
>> Motivation:
>>
>> Security, current development practice or industry best-practices, Web
>> and offline distribution, interoperability.
>>
>> Rationale:
>>
>> To ensure that widgets can be served in environments for which an HTTP
>> proxy is required to be used, or be given value-added services
>> available only through the HTTP proxy. For example, the runtime
>> environment may be pre-configured to offer proxy services for all HTTP
>> clients. Unless the widget has special requirements for use of a
>> different proxy, the default proxy configuration should be used.
>>
>>
>
> I think the current requirement text basically says what your
> requirement says, so I kept the current text. I did, however, use your
> rationale text.
>
> Thanks again for taking the time to provide feedback and for the new
> requirements. I'm looking forward to discussing some of these issues
> MWBP has raised further.
>
> Kind regards,
> Marcos
>
> [1] http://dev.w3.org/2006/waf/widgets-land/Overview.src.html
> --
> Marcos Caceres
> http://datadriven.com.au
>



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

Received on Thursday, 4 September 2008 05:43:38 UTC