Re: Finalizing Second Screen Presentation WG draft charter

Hi Wayne,

Thanks for the review. I have a few counter-proposals on some of the 
proposed changes. See below. Changes not copied below look good to me.


On 2014-06-12 20:57, Wayne Carr wrote:
[...]
> 2.
> "Presentation API
> An API to enable displaying web content on a second screen and
> communicating between authorized pages and the content that is to be
> displayed on the second screen."
>
>
> That sentence is hard to parse - the "ands" can be parsed as 3 separate
> things.  "communication between authorized pages"  is intended to mean
> pages in some set of authorized pages and something else.  It could be
> misread as a separate item meaning between one authorized page and
> another authorized page.  the description assumes the reader carefully
> read and understood the scope section so knows what authorized pages
> means.  the deliverables list need to be easy to understand on its own..
>
> Suggested change:
>
> An API to enable a page to display web content on a second screen with a
> communication channel between one or more authorized pages on the
> initiating device and the content that is to be displayed on the second
> screen."

My understanding is that the notion of "authorized pages" is not bound 
to the initiating device. This enables many-to-one scenarios where 
different user agents can communicate with the same second screen 
(typically possible if the second screen runs its own user agent). I 
rather suggest to use the exact wording of the Scope section here:

[[
An API that allows a web application to request display of web content 
on a connected display, with a means to communicate with and control the 
web content from the initiating page and other authorized pages.
]]


> 3.
>
> More on the Presentation API deliverable section.
>
> "The initial version of this document will be copied from
> thePresentation API W3C Community Group Draft Report
> <http://webscreens.github.io/presentation-api/>which was produced by the
> W3C Second Screen Presentation Community Group."
>
> That appears to link to an old version (the initial input to the CG?)
> that doesn't reflect what the CG has done in changing the way this is
> done.  i.e. by using a message channel instead of returning a
> presentation browsing context. e.g. "Fulfil/promise/with
> the|WindowProxy|of the newpresentation browsing context
> <http://webscreens.github.io/presentation-api/#presentation-browsing-context>as
> its value" is wrong now.
>
> This CG should update the final report to use the current WebIDL.
> https://www.w3.org/community/webscreens/wiki/API_Discussion#WebIDL - or
> you're going to confuse AP reps with a report that doesn't reflect what
> you have in the charter and what you want the WG to use.
>
> If you want to get the AC charter review under way before you change the
> report, then link now to a "Final Draft Report" that currently says the
> final report isn't completed and point there to the current WebIDL
> https://www.w3.org/community/webscreens/wiki/API_Discussion#WebIDL - say
> the final report will be complete by the time the WG starts.

Right. The CG has a few weeks ahead to prepare the final draft report 
before the charter gets sent to the AC for review.

Note that this is the kind of last minute changes that I will make to 
the charter before sending it to the AC for review depending on the 
status of the spec at that time, but it's a good idea to flag it as 
"TBD" right away.


[...]
> 6.
> "Some of the use cases that this Working Group aims to address, in
> particular the discovery and control of a display service connected on
> the local network, are also in scope of the Network Service Discovery
> API worked upon by the Device APIs Working Group. This Working Group
> will liaise with the Device APIs Working Group to avoid duplication of
> efforts and of solutions in this space."
>
> I think AC reps will see this as a red flag.  It appears to say the
> proposed WG will be defining specs that overlap with or may conflict
> with another WG.  I don't think that's what is meant.  Discovery and
> control of a display device is NOT in scope for this proposed WG. That's
> up to the implementation.  The charter scope section is pretty explicit
> at saying that is out of scope.
> http://webscreens.github.io/charter/#out-of-scope
> <http://webscreens.github.io/charter/#out-of-scope>
>
> Suggested change:
> "While not a dependency for the specifications from this WG, the Network
> Service Discovery API from the Device APIs Working Group could prove
> useful in implementations of specifications produced by this WG. This
> Working Group will liaise with the Device APIs Working Group."

I agree that the initial wording is too strong (it's not about avoiding 
duplication of solutions since the APIs also have very specific and 
disjoint use cases, and the part on discovery and control should be 
removed) but also think that the overlap exists and needs to appear in 
the charter.

The overlap exists for use cases such as "A Web application projects a 
video to a second screen that exposes itself as a DIAL service on the 
local network" that could be achieved with both APIs. That is not the 
case with other APIs mentioned in the Liaisons section, AFAICT.

One thing that the Working Group might want to get out of implementors 
is consistency: if a user agent supports DIAL in the NSD API, it should 
also support DIAL screens in the Presentation API. This would avoid the 
need for Web applications to use the NSD API as a fallback of the 
Presentation API to support additional screens.

I suggest to smoothen the wording accordingly:

[[
Even though the scopes of the APIs are different, some of the use cases 
that the Presentation API aims to address, in particular projection of 
web content on second screens connected to the local area network, are 
also in scope of the Network Service Discovery API worked upon by the 
Device APIs Working Group. This Working Group will liaise with the 
Device APIs Working Group, in particular to ensure consistency of 
supported service discovery mechanisms when a user agent implements both 
APIs.
]]

Any better suggestion?

Thanks,
Francois.

PS: Anssi, happy to prepare a PR with these changes (including the other 
changes that Wayne suggested) once the group is ok with them.

Received on Friday, 13 June 2014 09:57:48 UTC