W3C home > Mailing lists > Public > public-html-media@w3.org > March 2016

[media-source] Normative reference to the File API working draft

From: Yosuke Funahashi via GitHub <sysbot+gh@w3.org>
Date: Mon, 14 Mar 2016 10:54:06 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-140639837-1457952845-sysbot+gh@w3.org>
yfuna has just created a new issue for 
https://github.com/w3c/media-source:

== Normative reference to the File API working draft ==
The [File API](https://www.w3.org/TR/FileAPI/) spec, which MSE refers 
normatively, is not yet a Recommendation or Proposed Recommendation 
but still a Working Draft. It means that, before we submit our 
transition request to PR, we have to make it stable if needed. (See 
[Normative 
References](https://www.w3.org/2013/09/normative-references))

The File API spec currently covers five features:

1. Blob interface/object
2. File interface/object
3. FileList interface
4. FileReader API
5. Blob URL

Given that MSE only uses the fifth item, Blob URL, which is relatively
 a small portion and seems stable, there would be four ways we can 
take to achieve the stability.

1) If WPWG has no plan to develop the spec lately, we'll ask the WPWG 
chairs to make it PR.
2) If WPWG has a plan to develop the spec,
2-a) we'll ask the WPWG chairs to split the WD into two specs, one is 
about Blob URL and the other is for other stuffs, and make the Blog 
URL spec PR.
2-b) we'll ask the WPWG chairs to make it clear in the spec that the 
Blob URL part is stable and won't change in a short term.
3) If none of above is feasible, we copy'n'paste what we need from the
 File API spec to MSE with a note that we will change that part to a 
normative reference to the File API spec when WPWG make it a PR.

Through the initial conversation with the WPWG chairs, the team found 
that the option 1) was not the case there(the spec currently has a 
development proposal in the group), and the option 2-a) was not what 
the chairs wanted because they think they should keep the spec 
inclusive on file related features.

Thus, the options left to us currently are 2-b) and 3).

I'll start analyzing these two options and list up their pros and 
cons, while, at the same time, welcome your thoughts on other or 
different options we can pursue to resolve this issue. 


Please view or discuss this issue at 
https://github.com/w3c/media-source/issues/57 using your GitHub 
account
Received on Monday, 14 March 2016 10:54:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 14 March 2016 10:54:09 UTC