Pick Media Intent Review

Dear DAP WG,

I took some time to go through the Media Pick Intent specification.
This specification seems already in good shape and is easy to read, which is good!

Please find below some comments that came to mind when reading the spec.
Even though I certainly miss some context information, I hope that this feedback will be of some use.
I will try to send some feedback to the Web Intent spec as well.

Regards,
                Youenn


1. Media Type Filtering
One important filtering case may be based on media types.
Requesting images or mp3 may be different. This may lead a user to select different providers.
If a provider supports several media types, the provider may use a different initial UI depending on the suggested type: initial view could show 'Music' or 'Pictures' folder...
How would happen that kind of filtering?

One straightforward option would be to use the MIME matching type parameter filtering capacity.
A user agent would be able to filter the number of potential pickers based on that parameter.
The action value could be changed to something more precise (http://webintents.org/pick/media?).

2. Keyword filtering
While I see a potential use for the 'limit' member, I am less sure about the search feature (filters and search parameters).
Would filtering be best handled by the web intent provider itself, with a UI well-known to the user?

3. Persistency
In the case a user is doing a photo album or an image mosaic, she may select some images iteratively.
In that case, the same intent provider may be called more than once by the same web application.
It would be very handy if the provider could keep some knowledge of the past interactions.

One option would be for providers to use some user-agent cache techniques: to keep filtering keywords, existing displayed images...
Another option would be to allow the user agent to reuse the past provider page (e.g. stored in the browser page cache) , for instance if the same Intent object is used several times to start an activity.
I am unsure whether the Web Intent specification enables or precludes this particular behavior.

4. Blobs & URIs
There are currently two content access mechanisms defined in the pick media intent spec: blob and URI.

4.1
In the case of a local media picker, the media content may be retrieved using the File API.
In such a case, it may be nice to provide the data as a blob and not as a URI.
The current specification states that the URI is mandatory which may not be practical in that case.
Would it make sense to state that at least one of either URI or blob member is required?

4.2
I wonder whether it would be convenient to let the web intent client ask for either blob or URI as data access.
Otherwise, it will always need to handle both cases.

4.3
The security implications are important for media since it may make difficult some media processing capabilities such as canvas, web audio API...
It would be interesting for web intent clients to state whether they want 'full access' to data or not.
At first I was thinking that this information could be communicated as 'do you want URI or Blob', but the separation is more subtle than that.
Maybe the real issue is deeper and should be treated at another layer.
Anyway, if a web intent provider knows what access type is needed by the web intent client, the provider can agree/disagree to that access type.
If agreeing, the provider can select the best way to transfer the data (XHR blobs, URIs, ArrayBuffer...) so that the client can readily use the media content.

5. Media dictionary
5.1
There are four mandatory attributes (content, description, title and type).
I understand why content and type are mandatory but I wonder why both description and title are mandatory attributes.
For instance a local file media picker may only know file names, but not description or title.

5.2
Some properties but not all have a meaning well defined in the Media Ontology core set.
If that is the case, would it make sense to make precise reference for each of these fields?

5.3
Would it make sense to align the filename property to the name property of the File interface?

5.4
I am curious about the reason to restrict the media id representation to URI.

5.5
If it makes sense in the future to create a save/share media intent API, it may be nice to share the Media dictionary members for both pick and save/share intents.
Is it envisioned as part of the design of the Media dictionary?
Is it a work that is envisioned within the WG?

6. MediaError
It seems like the MediaError dictionary could be applied to about any web intent provider error message.
Would it make sense to reuse that pattern for other intents and actually advertise that pattern somewhere? As a best practice? As an interface?

7. Typo
Section 3.3 user agents -> user agent