Re: Comments/Questions on WebIntents editors draft 19 June

Greg, see inline for suggestion regarding "absolute URL" text clarification

regards, Frederick

Frederick Hirsch
Nokia



On Jul 12, 2012, at 5:29 PM, ext Greg Billock wrote:




On Wed, Jul 11, 2012 at 10:14 AM, James Hawkins <jhawkins@google.com<mailto:jhawkins@google.com>> wrote:
+Greg for some questions.

Replies in-line.

On Mon, Jul 9, 2012 at 3:20 PM, <Frederick.Hirsch@nokia.com<mailto: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.

Yes, that's right.


[fjh] that was my guess but it wasn't obvious. I would suggest the following revision

"When present, this field provides a list of suggested Service URLs, each of which is an absolute URL that the Client is aware  of and which can handle the intent. "



"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?


In other discussions, I think we've decided to change this to make |extras| a member. There are some implementation hurdles -- we just need to make sure the JS makes sense. It's the desirable thing, though. Using |getExtra| was an attempt to get around the difficulties of that problem, but just returning the |extras| member is what we want to do.


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/]]<http://dev.w3.org/html5/postmsg/%5D%5D>."


sgtm

I think this is already in and working, in at least a couple places. If there are any leftover glitches, they're just typos.


(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






For my information, should I get a new repository for editing the draft going forwards? I want to make sure the edits show up in the correct place. How are the links to the spec being handled? We've built up some link juice to the existing document URL. Will we forward that URL to the new location? I want to make sure we're updating the right document and that there aren't a live and stale copy both floating around. :-)

-Greg