- From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
- Date: Wed, 23 Jan 2013 13:37:35 +0100
- To: "'Frederick.Hirsch@nokia.com'" <Frederick.Hirsch@nokia.com>, "fredandw@live.com" <fredandw@live.com>
- CC: "public-pua@w3.org" <public-pua@w3.org>, "public-web-intents@w3.org" <public-web-intents@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, "dom@w3.org" <dom@w3.org>
- Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA35D819E38D0@seldmbx03.corpusers.net>
+1 From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] Sent: den 22 januari 2013 21:14 To: fredandw@live.com Cc: Frederick.Hirsch@nokia.com; public-pua@w3.org; public-web-intents@w3.org; public-webapps@w3.org; dom@w3.org Subject: Declarative invocation and progressing Web Intents Fred I object to this being a resolution, since I never saw a formal "Call for Consensus" sent to the WebIntents list. I saw an informal discussion of ideas and an offer to provide proposals, not a proposal to change where standards are delivered. I know the DAP WG has not had a chance to discuss or agree to this resolution. In addition, currently members of DAP have work items to progress both Web Intents and Web Activities and we have not stopped this work - though we need to review the status. I also am not clear on the IPR implications of work being done in the PUA CG versus/with a working group. I suggest a change to what you propose. I would like to suggest that the PUA CG consider Declarative Invocation in cooperation with the WebIntents Task Force, and provide input regarding Web Intents development, but not take over development of this standardization. I suggest the standard remain a joint deliverable from DAP (and WebApps) WGs as joint deliverables until we formally decide otherwise. I think first steps for declarative invocation, however, might be documenting use cases and requirements. What do others think? Thanks regards, Frederick Frederick Hirsch, Nokia Chair, W3C DAP Working Group On Jan 21, 2013, at 7:15 PM, ext Fred Andrews wrote: Given that there have been no objections, the PUA CG accepts the development of the 'Declarative Invocation' standard. This technology has great potential for securing the users private UA state and is well aligned with the charter of the PUA CG. Given that this will likely require a rewrite of the Web Intents proposal the PUA CG will also take over the development of a suitable replacement. Members of the Web Intents Task Force are invited to join the PUA CG for further discussions. cheer Fred Chair Private User Agent Community Group ________________________________ From: fredandw@live.com<mailto:fredandw@live.com> To: jhawkins@google.com<mailto:jhawkins@google.com> CC: public-web-intents@w3.org<mailto:public-web-intents@w3.org>; public-pua@w3.org<mailto:public-pua@w3.org> Date: Wed, 9 Jan 2013 03:19:31 +0000 Subject: RE: Declarative invocation Dear James, The declarative invocation markup would ideally support multiple inputs from a webpage and multiple outputs back to the webpage. There might be multiple intents supported on a page, and perhaps there might even be overlap between the inputs and outputs. For example, a file input element could declare the mime type(s) accepted, and this could be used with a pick intent to return a blob (single output). This blob might be then be usable as a further input to an 'image edit' intent that returns an updated blob (single input, single output). Finally when the input form is submitted the blob is sent. This could allow a webpage without JS enabled to upload an edited image captured from a device camera, all from within the web browser. The user can use trusted web apps for the image capture and for the image editing without exposing the camera API and without sharing UA state via an image editing web app. For example, a section of an input form with contact inputs (name, address, etc), could be used with an intent that can search a trusted 'contacts' web app using supplied fields to direct the search and returning the requested fields that are used to populate the input form (multiple input, multiple output). The user might make some changes to the address and invoke another web intent to save the new contact address (multiple input, no output?). There may be some opportunity to coordinate the required markup with general 'semantic web' markup, such a microdata. The web browser could then implement the UI and invocation without the webpage needing to add the UI support, and this might be done in a manner that is less vulnerable to spoofing. I would also be keen to explore how this could help accessibility of webpage input forms. For example, a photo viewing webpage might markup a slideshow allowing a presentation web app, that is specifically adapted to a limited device, to show the slide show and this could be invoked via a web intent (multiple input, no output). The direction to take with the webpage UI support for invoking web intents is not clear to me yet. It would be good to support buttons that can invoke an intent, such as a 'share' intent button, and this would allow a webpage to voluntarily place and style invocation buttons. Buttons might also by placed around form input elements, such as a text input form element. Other options being explored are allowing a web app to take over an element or region of a webpage when invoked - for example could a web app invoked via web intents might take over a webpage text input form element within the page to offer a rich HTML editor. Other options are to overlay a webpage region, or a popup? Support is also needed for legacy webpages, without semantic markup and web intents invocation buttons etc. This might not need a standard, and might be a matter for the web browser, but it could use the infrastructure provided for declarative invocation. For example a web browser might offer a content menu option to invoke a range of web intents for a file input element and remember the choice, or offer a range of intents to edit a text input element, etc. A database of useful intents for various web pages might be maintained. The PUA CG is chartered to develop extensions that improve the security of private UA state and could take on the task developing declarative markup for invoking web intents? cheers Fred ________________________________ From: jhawkins@google.com<mailto:jhawkins@google.com> Date: Wed, 2 Jan 2013 11:09:15 -0800 To: fredandw@live.com<mailto:fredandw@live.com> CC: public-web-intents@w3.org<mailto:public-web-intents@w3.org> Subject: Re: Declarative invocation I agree that declarative invocation would be pretty awesome. I think the list is generally in agreement; however, it hasn't been very high on the list of things to spec out, so it hasn't happened yet. Do you want to provide some examples of what you think it may look like? Thanks, James On Sat, Dec 8, 2012 at 7:45 PM, Fred Andrews <fredandw@live.com<mailto:fredandw@live.com>> wrote: Web Intents would appear to be well suited to supporting rich interactive UI via apps in webpages without Javascript enabled. This requires a declarative invocation specification. For example, editing a textbox, or filling a contact input form, providing an image input blob, social share widgets, etc. It might be useful to allow input forms to be marked up with Web Intent inputs and result outputs plus the intent action and type. Web browser might be able to guess or remember appropriate intents to use for input forms even on pages not marked up for this. For example, a wikimedia textbox for which the user can choose a rich app to edit or generate content. A new fallback element might also be handy, for example if a browser does not support declarative web intents then this element could include a default html editor for a text/html textbox, or include a group of popular social widgets for sharing. This might work in a similar way to the <noscript> element, or might be the body of a web intent invocation element for which the body is ignored if web intents are enabled. Declarative invocation might also be easier for web authors. There appears to be potential for helping users that choose to only enable javascript on trusted webpages because the user would gain the choice of using a rich app from a trusted website to perform some common tasks. cheers Fred
Received on Wednesday, 23 January 2013 12:38:11 UTC