Re: CfC: Publication of two Presentation API Reports

fixed a couple of grammatical problems
s/may have a defined their own/may have defined their own/
s/the UA would not need to/the UA on the requesting device would not 
need to/

[repeating what was in the original post -- this is for the end of the 
introduction.  The spec as is doesn't explain how the messages between 
requesting page and presentation page could be transmitted. Many readers 
wouldn't be aware of how what's missing could be filled in by having the 
UA act as a proxy (e.g. for hdmi render the content for the remote page 
and just have the OS display it remotely).


"This specification depends on an exchange of messages between a 
requesting page and a presentation page shown in the secondary display.  
How those messages are transmitted is left to the UA in order to allow 
for use of display devices that can be attached in a wide variety of 
ways.  For example, when a display device is attached using HDMI or 
MiraCast, the UA on the requesting device can render the requested 
presentation page in that same UA, but instead of displaying in a Window 
on that same device, it can use whatever means the operating system 
provides for using those external displays.   In that case, both the 
requesting page and the presentation page run on the requesting device 
and the operating system is used to route the presentation display 
output to the other display device.  The second display device doesn't 
need to know anything about this spec or that the content involves 
html5.  Alternately, some types of external displays may be able to 
render html5 themselves and may have defined their own way to send 
messages to that content.  In that case, the UA on the requesting device 
would not need to render the presentation page at all.  Instead, the UA 
could act as a proxy translating the request to show a page and the 
messages into the form understood by the display device.  This way of 
attaching to displays could be enhanced in the future through definition 
of a standard protocol for delivering these types of messages that 
display devices could choose to implement.  The API defined here could 
be used with UAs that attached to display devices in any of those ways."

On 2014-07-07 12:01, Wayne Carr wrote:
>
> I think the new version needs some informative text on ways this could 
> be implemented.  Without it, it may not be clear to those unfamiliar 
> with this how it could be implemented.  That was in the initial input 
> document and just needs to be updated.  The following paragraph could 
> be added to the end of the introduction.
>
>
> This specification depends on an exchange of messages between a 
> requesting page and a presentation page shown in the secondary 
> display.  How those messages are transmitted is left to the UA in 
> order to allow for use of display devices that can be attached in a 
> wide variety of ways.  For example, when a display device is attached 
> using HDMI or MiraCast, the UA on the requesting device can render the 
> requested presentation page in that same UA, but instead of displaying 
> in a Window on that same device, it can use whatever means the 
> operating system provides for using those external displays.   In that 
> case, both the requesting page and the presentation page run on the 
> requesting device and the operating system is used to route the 
> presentation display output to the other display device.  The second 
> display device doesn't need to know anything about this spec or that 
> the content involves html5.  Alternately, some types of external 
> displays may be able to render html5 themselves and may have a defined 
> their own way to send messages to that content.  In that case, the UA 
> would not need to render the presentation page at all.  Instead, the 
> UA could act as a proxy translating the request to show a page and the 
> messages into the form understood by the display device.  This way of 
> attaching to displays could be enhanced in the future through 
> definition of a standard protocol for delivering these types of 
> messages that display devices could choose to implement.  The API 
> defined here could be used with UAs that attached to display devices 
> in any of those ways.
>
>
> On 2014-07-04 01:50, Rottsches, Dominik wrote:
>> Hi,
>>
>> You’ve probably followed the process of our group transitioning to a working group. We plan to continue our work on Presentation API and second screen presentation in the form of a WG.
>>
>> The process of forming a working group requires input to the AC which documents the work and progress of our group.
>>
>> As per the Decision Process [1] defined in the community group Charter, this is a Call for Consensus (CfC) to publish two Presentation API Reports that meet the requirements for CG Deliverables [2]:
>>
>> * Presentation API W3C Community Group Final Report [3]
>>
>> This report documents the use cases, requirements, examples and interfaces needed to enable web pages to display web content on secondary screens. It is an evolved version of the initial Presentation API that represents the result of discussions within the Second Screen Presentation Community Group so far. API semantics still need to be specified. The report may serve as starting point for a possible Working Group chartered to work on the same topic.
>>
>> * Presentation API W3C Community Group Draft Report [4]
>>
>> This is the initial version of the Presentation API that was provided as input to the Community Group. This snapshot is published to allow it to be referenced in future discussions more easily.
>>
>> Please send all comments regarding this CfC to thepublic-webscreens@w3.org  mailing list by next Friday. Silence will be considered as agreement with publishing.
>>
>> Thanks & regards,
>>
>> Dominik Röttsches
>> Second Screen Community Group Chair
>>
>>
>> [1]https://github.com/webscreens/presentation-api/wiki/Second-Screen-Community-Group-Charter#decision-process
>> [2]http://www.w3.org/community/about/agreements/#comm-deliverables
>> [3]http://webscreens.github.io/presentation-api/
>> [4]http://webscreens.github.io/presentation-api/20131112/
>>
>>
>>
>>
>