RE: Declarative invocation and progressing Web Intents

+1

Regards,
Jungkee
2013. 1. 23. 오후 9:38에 "Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>님이
작성:

> +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
> 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****
>
> ** **
>
> ** **
>
> ** **
>