+1
Thanks for writing this
> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> Sent: Tuesday, January 22, 2013 3:14 PM
> 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
> To: jhawkins@google.com
> CC: public-web-intents@w3.org; 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
> Date: Wed, 2 Jan 2013 11:09:15 -0800
> To: fredandw@live.com
> CC: 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>
> 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
>
>
>
>
>
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.