[todo] Response to your LC Comment -2419 on Media API spec

Robin is not fully satisfied with the following remaining issues.
We must respond to Robin on these issues.


>> 4 comments are not done yet (for 2 of them we need to contact other WG's, the other 2 require changes to the ontology document).
>
> Thanks! I would kindly request that you ping me again when these four comments are resolved so that we may ensure alignment. For any response not listed here please consider it assented to.


Issue 2419-A:
-------------
>> substantial: "Example on how to introduce this in HTML5 by making the HTMLMediaElement inherit from the MediaResource interface:" This shouldn't be an example. If a user agent is expected to expose this interface on media elements, then this has to be a MUST, possibly using an "implements" statement.
>> [MA] We will coordinate with the HTML WG on this issue.
>
> I am not certain that you need to coordinate with the HTML WG. This is mostly a Web IDL and testability issue. First, this can't be an example as it is a normative requirement on browsers. You therefore need a statement of the order "User agents that support [HTML5] MUST expose the MediaResource interface on objects that implement HTMLMediaElement." This can be further captured in Web IDL with the simple statement:
>    HTMLMediaElement implements MediaResource;


Issue 2419-B:
-------------
>> If that is not the case, the API *really* needs to be made asynchronous, otherwise it won't be usable in a browser context at all (or in any kind of performance-conscious environment, such as typically a web server).
>> [MA] We have added an asynchronous version of the getMediaProperty method as is used in the Geolocation API (http://dev.w3.org/geo/api/spec-source.html#geolocation).
>
> It was a mistake in XMLHttpRequest to include both synchronous and asynchronous variants for general consumption — it leads to bad practices, which we should be discouraging by design. What the rest of the Web JS API stack is doing now is to have asynchronous APIs in the regular browser context, and (optionally) synchronous variant only available to Web Workers. See for instance the multiple File APIs. I suggest that you either go full asynchronous, or likewise make the synchronous variant workers-only.
>
> Is there an updated draft where I can review the changes?


>> If it is the case, then instead of specifying a complex filter in getProperty's parameters, it would be a lot simpler to just expose the property and leave it up to code to do the filtering. So instead of
>>
>> props = mr.getProperty("title");
>> props = mr.getProperty("title", "#subchapter");
>> props = mr.getProperty("title", null, "tva");
>> props = mr.getProperty("title", null, null, null, "fr");
>>
>> you would just have
>>
>> props = mr.title;
>>
>> and leave it up to code to perform any kind of filtering on its own terms. This can then be abstracted into a library. It seems clearer, and much more idiomatic.
>> [MA] In fact, when none of the filters are included in the getMediaProperty parameters, the result array will hold all values. So if wanted the code can allways call the property without specifying the filters and do the filtering by itself.
>
> That does not address the idiomaticity issues — I would need to see the new draft to see if the asynchronous variant improves that.


Issue 2419-C:
-------------
>> substantial: I suggest exposing the properties directly on the object and removing getPropertyNamesWithValues.
>> [MA] We have changed the "getPropertyNamesWithValues" to "getPropertyNamesHavingValues".
>
> I'm sorry, can you please clarify how this addresses my concern?

Issue 2419-D:
-------------
>> ed.: "MAObject" is not a very descriptive name, 75% of it is dedicated to saying that it's an object, which one already knows from the fact that it has been retrieved as such. "MediaAnnotation" would be clearer.
>> [MA] Agreed.
>
> Has the change been accepted?


Issue 2419-E:
-------------
>> substantial: It is not clear "plain text" is for unstructuredValue. Is this the raw binary for binary formats? A piece of XML for XML formats?
>> [MA] The unstructuredValue holds the original metadata represented as a string. This can hold binary values from binary formats, XML elements, or anything else. The actual syntax is not defined and can be implementation dependent.
>
> I would strongly suggest that you reference https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html for this (as for instance http://dev.w3.org/2009/dap/file-system/file-writer.html does). Arbitrary data is not really well captured by strings.


Issue 2419-F:
-------------
>> substantial: It is quite counter-intuitive to have:
>>
>> var lang = foo.getProperty("language").value;
>> when one could equally have:
>> var lang = foo.language;
>>
>> The same applies to other properties, such as description.
>> [MA] We consider the fact that requesting for one property can result in several results, depending on sub types, source formats, languages and fragments.
>> Additionally, the different properties typically have different structure (e.g., language versus rating). We agreed on using only one method to access these properties, consequently
>> the different results need to implement the same interface, hence the "value" attribute.
>
> I am not entirely happy with this design but I guess that it can be wrapped in a library.

Issue 2419-G:
-------------
>> substantial: The section CreateDate has just "Date" in the interface name. It should probably be "CreationDate" in both.
>> [MA] We changed "Date" interface to "CreateDate" interface.
>
> Shouldn't that be CreationDate?


Issue 2419-H:
-------------
>> substantial: It's unclear what to return for Compression. Is JPEG a compression? Something more specific? Is it case sensitive? Partially controlled?
>> [MA] TODO This issue will be tackled in the ontology document.
>
> OK, please inform me of the resolution when it is ready.

Issue 2419-I:
-------------
>> substantial: The relationship of section 5 to HTTP is unclear. Is this needed?
>> [MA] Some of the status codes were re-used from HTTP. This section merely elaborates on the status codes and presents the system specific ones.
>
> It would be worth to indicate that this reuse is (presumably) just to pick something that developers are familiar with, and does not imply any specific link with HTTP.

Issue 2419-J:
-------------

>> substantial: Section 7 should be beefed up. Notably, if I can access geographic information it could be used to access someone's location without them agreeing to it. Likewise for name and a number of other things. In general, you probably need to think about privacy.
>> [MA] We have added a paragraph on this.
>
> Can I please see the paragraph? I would like the privacy experts in DAP to look over it.

Issue 2419-K:
-------------

>> note: integration with DAP's Media Capture is likely desirable.
>> [MA] TODO Communication with the Media Capture WG has been initialized.
>
> I think you mean DAP, but good!
>

Received on Wednesday, 29 September 2010 16:17:21 UTC