RE: ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]

Good points Bryan.

Regarding the user-agent, accept and profile headers to which you refer, these are indeed data used by the DDR to identify the device in use and subsequently adapt to that device using previously recorded capability information. The DDR uses the concept of "Evidence" as the key to perform that lookup. To date, the overwhelming source of evidence is the HTTP headers, though we could also envisage that such evidence might come from the application, from the user, from some third-party monitoring, an Ajax agent and many more potential sources. The DDR has envisaged these possibilities.

However, the established practice in almost all cases is to base evidence on the HTTP headers, particularly the User-Agent and Accept headers. (Not necessarily to parse what is contained in those headers, but instead to use them as a "fingerprint" that can be used as a key to find the real capabilities. After all, who believes an accept header that says "*/*"?)

I am encouraged by the recent support for acknowledgement of the role of context/capability awareness in Web applications, particularly the mobile space where diversity is the norm.

---Rotan.

-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Sullivan, Bryan
Sent: 16 October 2008 08:12
To: Mobile Web Best Practices Working Group WG
Subject: RE: ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]

Hi all,

Following up on this issue with further information. Testing I have done with various web applications, both mobile and desktop, show that the webapps do specify a particular user-agent header (or extend the web runtime default header, including host device information) and in some cases specific accept-types that are supported or relevant to the particular request. This tells me that there is value in identifying the application via the user-agent header, and the capabilities via the accept header at least.

Also, they are not limited to sending requests to one server, but can and do send requests to multiple domains based upon the content they are retrieving.

In contrast, if we narrow the MWABP focus to:
- webapps that are distributed as browser-based Javascript applications and thus are restricted to cross-domain script limitations (while those constraints still exist)
- webapps that are specialized to operate per the inherent expectations of the content server, or vice versa, content servers that provide content to webapps with an inherent assumption of the webapp's capabilities (and those of the host platform)

Then, IMO, we are not adding a lot of value with the MWABP in the area of context/capability awareness (like we did at least with BP1), since ignoring that objective will not reflect the reality of the webapps market, which has already expanded beyond the browser.

At the least, it would be beneficial if the server can determine the host device type so that it can adapt content to the device capabilities. I don't see why we went to all the trouble of the DDR in the DDWG if we are to ignore that work by saying that webapps don't have to tell the server what type of device is in use. That info is one of the keys to DDR lookup, and is essential for any server application which is concerned with content adaptation/personalization.

We could of course leave all this off the table and let webapps do such capabilities disclosure at the application layer. But that is just punting the issue into a non-standardized space, or one where the proposed standards seem to be having real market traction issues (e.g. DCCI). I don't see how that serves the developer and content provider, when we have a widely deployed practice available, thru the user-agent, accept, and profile headers.

I have not heard, on this list, convincing arguments why context/capability awareness is a non-issue with web applications. In the absence of such, why would we ignore the existing best practices in this area?

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Mobile Web Best Practices Working Group Issue Tracker
Sent: Friday, September 26, 2008 8:52 AM
To: public-bpwg@w3.org
Subject: ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]


ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]

http://www.w3.org/2005/MWI/BPWG/Group/track/issues/281


Raised by: Bryan Sullivan
On product: Mobile Web Applications Best Practices

The MWABP should make recommendations on the use of Widget interface features and Javascript functions (e.g. XMLHttpRequest) to achieve what the MWBP comments to the Widgets 1.0 Requirements were attempting to promote, e.g. interoperability, through:
(a) identification of the widget in HTTP requests (user-agent header)
(b) disclosure of Widget and device capabilities (Profile and Accept headers)

Example:
var client = new XMLHttpRequest();
client.open('GET', 'http://dcd.server.com/channel?ID=21');
client.setRequestHeader('User-Agent', 'DCD Widget/1.0');
client.setRequestHeader('Accept', 'application/vnd.oma.dcd, multipart/mixed, multipart/related');
client.setRequestHeader('Profile', '"http://megawidgets.com/dcd-widget1.0..rdf"');
client.send();

These methods ensure that the capabilities of Web Applications are disclosed (or at least the application identity is disclosed, which is useful as a lookup key for detailed info in a DDR), and thus the Content Provider can adapt services appropriately. Web Applications are expected to have diverse purposes/capabilities and use diverse content types, so it's important that we carry forward and extend as needed the "adapt services to device capabilities" guidance that we provided for browsers in BP1. Because these capabilities may not be disclosed by default though the underlying platform features (XHR or other native HTTP request API), the Web Application developer should be prepared to disclose them directly.

Received on Thursday, 16 October 2008 07:39:06 UTC