Re: Seeking summary of March 20-21 discussions

We have a lot of items to change in the spec, but most of them will be
in the recommendations/best practices section. (Which I think
currently does not exist, so we accomplished a lot in fleshing out
what that will do.)

The biggest API-affecting change is the addition of an object literal
constructor to clean up multi-argument construction for the more
complex use cases, and, more important in terms of functionality, to
clarify the language around |type| (which Robin mentioned). The
language in the spec sometimes seems to demand MIME types and other
places to allow other types. This was the result of uncertainty of how
we were going to handle this, which I'm going to repair that to be
much more clear. Here's my notes on changes there:

"""
**not add "format" or something

**widen to allow not only mime types (spec currently inconsistent
about this -- has good language, but edit at 3.4)

**for mime types, binary data will go as url (including data and blob
urls), string data goes as string. Services are encouraged to specify
their exact acceptance types, although mime wildcards are allowed,
they should be used only for things like image/* and video/* where
there might be a very long list of alternatives. Type matching for
MIME types with wild cards will be loose, but all other types,
including MIME types, is going to be exact.

For non-MIME types, users should write guidelines about what the
type's format is. For schema.org/*, the format will be a javascript
object, with fields corresponding to the attributes of the schema.org
type. Write an example for this case.
"""

So the discussions have really helped to nail down this important
issue. I think various pieces of the spec had this right here and
there, but didn't present a really understandable and coherent picture
(because it didn't exist :-))

The other changes are important, but there are quite a few, ranging
from suggestions to the UA about defaulting behavior to private
browsing behavior to better registration documentation and suggestions
for examples.

Two other important outcomes are writing documents explaining how UPnP
interactions will map to intents, and how contacts data will map to
intents. These documents won't be part of the draft API spec, but will
illustrate how to document a new use case or exchange data type, which
can then be used by others building on top of the API. (timeless
suggested just such a set of docs last year, so we have good
candidates for examples now.)



On Wed, Mar 21, 2012 at 8:24 AM, Robin Berjon <robin@berjon.com> wrote:
> On Mar 21, 2012, at 22:12 , Arthur Barstow wrote:
>> Hi All - since it appears that some of the folks interested in Web Intents were unable to attend this week's f2f meeting, I think it would be useful if someone that attended the meeting would provide a short summary of the related discussions (e.g. hot issues, important agreements, next steps, etc.).
>>
>> Would someone please do that? (I noticed the raw minutes are at [Mar-20] and [Mar-21]).
>
> I think that that would be a great idea, I'm unsure how to proceed to make it simple (and not too much extra work). I know that both James and Greg wrote down a lot of the things they were going to do — do you guys have that in electronic form? It could make for a good skeleton onto which we could then tack some extra details where needed.
>
> We should probably also write down the brainstorming from the restaurant about the type attribute, using URIs rather than media types, dropping the encoding attribute, passing blobs/URIs, etc. (but not now, now is time for sleep — I only say this not to forget tomorrow :).
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Received on Wednesday, 21 March 2012 23:38:59 UTC