Re: Comments/Questions on WebIntents editors draft 19 June

+Greg for some questions.

Replies in-line.

On Mon, Jul 9, 2012 at 3:20 PM, <Frederick.Hirsch@nokia.com> wrote:

> Some questions and potential clarifications on the "Web Intents"  Editor's
> Draft of 19 June 2012,
> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html
>
> (1) Section 3.1.1 Dictionary IntentParameters Members
>
> what does "absolute" mean, it is not clear from the specification:
>
>
Agreed it's unclear.  Greg, did you mean absolute as in absolute vs.
relative URL here?  If we want to be specific here on the format of the
URL, we'll likely need to reference a formal definition of the requirement.

"When present, this field provides a list of (absolute) suggested Service
> URLs of which the Client is aware and which can handle the intent."
>
> if we removed "(absolute)" would the meaning change?
>
>
> http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#dictionary-intentparameters-members
>
> (2) Section 3.2, "Intent Object"
>
> What does "It is left up to the client page whether to launch multiple
> Intents simultaneously." mean?
>
> Presumably what is meant is that it is "up to the client page whether to
> have multiple actions in progress simultaneously, or whether to block an
> open action before initiating additional actions".
>
>
Agreed this needs to be clarified.


> (3) section 3.2.1, and elsewhere
>
> Should text formatted as |foo| instead be formatted as <code>foo</code> in
> the ReSpec source, producing more readable output; if not this format
> should be described earlier in the document (e.g. in section 2)
>
> example,  "Any ports used in the |transferList| of the constructor during
> invocation will be delivered to the service page in the |ports| attribute"
>
>
sgtm (Sounds good to me)


> (4) why are extras not part of the Intent object itself, but rather
> obtained via a method?
>
>
I actually don't know where this came from.  Greg?


> Is the reason is that they are not to be passed to the service?
>
>
Presumably not, since the service is expecting |extras|.


> (5) Section 3.2.2, proper reference needed for Web Messaging
>
> Is a web messaging spec reference required in biblio.js so that it can be
> referenced as expected in Web Intents?
>
> "W3CWeb Messaging spec [[!http://dev.w3.org/html5/postmsg/]]."
>
>
sgtm


> (6) Section 3.5
>
> Suggest changing "A User Agent must not deliver an Intent to a web app
> service page which does not include markup describing what intents it can
> handle which matches the intent being delivered"
>
> to
>
> "A User Agent MUST NOT deliver an Intent to a service page that does not
> include markup indicating it can handle that intent."
>
>
sgtm


> (7) Section 4
>
> "The User Agent may inspect the payload of intents and present specialized
> UI corresponding to well-known intent types. "
>
> I'd be interested in an example of this, not quite sure what this means.
>
>
'Picking' a 'png' file from the local hard drive.  The UA acts as a Service
in this case.  Perhaps the language should be modeled after this concept:
The UA may act as either a Client and/or a Service.


> (8) section 4,  is this v.next material, should it remain in this draft?
>
> "In the same way User Agents may dispatch Intents triggered by non-web
> mechanisms to web applications, User Agents may dispatch intents invoked by
> web applications to handlers which are not web applications. In those
> cases, the User Agent should provide a public API mechanism for external
> connection to the intent dispatch mechanism selected. For example, the User
> Agent may be able to run an Operating System command in response to an
> intent. The User Agent could provide a configuration interface such that
> the user can install handler applications, and a documented format in which
> intent payload data is translated to that application. In these cases, the
> requirement that User Agents pass any serializable object is relaxed for
> some kinds of handlers."
>
>
Yes, I think we should remove this.


> (9) Do not explicit intents open a hole in the user-control of intents?
>
> This sounds potentially serious. Perhaps more discussion is needed here.
>
>
Per discussion at the F2F, the addition of a speed bump (the answer of
which is sticky) should solve this issue.  I'll make sure we get that text
added to the spec.


> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
>
>