W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: CfC - publication of Web MIDI API as First Public WD (Was: MIDI spec updates, as per telecon)

From: Chris Wilson <cwilso@google.com>
Date: Thu, 18 Oct 2012 15:56:36 -0700
Message-ID: <CAJK2wqW_z9jCLaLS4-e_qs6GDL1kTdiTv7H2YKb2fxrN1xB9nA@mail.gmail.com>
To: Thierry MICHEL <tmichel@w3.org>
Cc: olivier Thereaux <olivier.thereaux@bbc.co.uk>, "public-audio@w3.org Group" <public-audio@w3.org>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Looks great.  I'd prefer the "webmidi" shortname, to be symmetric with
webaudio.


On Thu, Oct 18, 2012 at 3:02 PM, Thierry MICHEL <tmichel@w3.org> wrote:

>
> Olivier,
>
> I had published the MIDI spec in the temporary URL to check it before
> moving it to TR.
>
> http://www.w3.org/2011/audio/**drafts/midi/1WD/Overview.html<http://www.w3.org/2011/audio/drafts/midi/1WD/Overview.html>
>
> I had used the short name
> http://www.w3.org/TR/midi-api/
>
> but if that does not fit you, I can change it to
> http://www.w3.org/TR/webmidi/
>
> Let me know ASAP and I will request it.
>
> For the document,
>
> I have updated the following:
>
> - SOTD section
> - Date and Title
> - previous, latest, editor's versions URIs,
>
> Also I have commented the following CSS selector
>  /*  tbody { height: 300px; overflow: auto; } */
>
> which produces ugly tables, which large height cells
>
> The document is now ready.
>
> If I don't have objections by monday afternoon (French time), let's say
> *noon Boston time*, I will then request Transition and then Publication.
>
> Thierry
>
>
>
>
>
>
>
> On 18/10/2012 22:01, olivier Thereaux wrote:
>
>> Dear all,
>>
>> At the teleconference yesterday, we discussed the Web MIDI API spec, and
>> agreed we'd like to publish as First Public Working Draft next week if
>> Chris found the time to make a few edits - which, as you can see in his
>> e-mail he did.
>>
>> Publishing at this point will allow us to publicise the work at TPAC, and
>> get more feedback from the public on a spec which is already quite mature.
>> Kudos to the editors.
>>
>> If there is no objection by Tuesday morning (Boston time) we will assume
>> consensus and will move forward with publication.
>>
>> Thierry will lead the process for publication, as usual.
>> Thierry, since this is a FPWD, can you get the green light for the
>> "webmidi" shortname?
>>
>> Thank you.
>> Olivier
>>
>> On 18 Oct 2012, at 00:42, Chris Wilson <cwilso@google.com> wrote:
>>
>>  I have updated the Web MIDI API specification, as per the discussion in
>>> today's teleconference, with one addition.
>>>
>>> The changeset is here: https://dvcs.w3.org/hg/audio/**rev/f4727ce84474<https://dvcs.w3.org/hg/audio/rev/f4727ce84474>
>>> .
>>>
>>> The updated spec is here: https://dvcs.w3.org/hg/audio/**
>>> raw-file/tip/midi/**specification.html<https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html>
>>> .
>>>
>>> I made the following edits:
>>>          I expanded the overview section, making it clear that this API
>>> is not intended to cover semantic controls through MIDI (i.e. a solution to
>>> the web of things problem), and also that this API is not concerned with
>>> Standard MIDI Files or General MIDI - that is, that it is concerned with
>>> input and output, not "playback" per se.
>>>          I greatly expanded the introduction section to provide a more
>>> table-of-contents style overview of the API, and also to describe in more
>>> detail how the API is intended to function.
>>>          I essentially rewrote the Security and Privacy considerations
>>> section to describe the fingerprinting and access concerns in more detail,
>>> and also (per conversation in telecon) to explicitly leave the model open.
>>>  These three edits should resolve bug 19187.
>>>          I changed the sendMessage() method back to my suggested
>>> three-parameter form, and explicitly excluded sysex from sendMessage().  I
>>> expect further discussion on this point, but for our FPWD, I wanted to have
>>> it this way as I was brainstorming the security and privacy constraints,
>>> and I think it may be possible to use sysex as the "needs user permission"
>>> switch - that is, to require user permission ONLY in order to send/receive
>>> sysex.  I'm not positive this will be enough, but it will be easier to
>>> change it back than it would be to break variadic usage later.  ref: Bug
>>> 18764.
>>>          I explicitly made timestamps in MIDIMessage allowed to be set
>>> to zero, with the semantic of "send now", as per Bug 18760.
>>>          I added IDs to several elements in order to provide forward
>>> links, and I expanded some of the IDL constructs to better show the
>>> descriptions of individual method parameters or members.  (no substantive
>>> changes.)
>>> -Chris
>>>
>>
>>
Received on Thursday, 18 October 2012 22:57:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:03 UTC