Re: Interoperability and protocols in draft WG charter

On Tue, Jun 3, 2014 at 12:10 PM, mark a. foltz <mfoltz@google.com> wrote:

> Thanks.  Two items of feedback around clarification.
>
> Original text #1:
>
> +          To advance to Proposed Recommendation, interoperability between
> the
>
> +          independent implementations (that is, same content rendered and
> same
> +          experience regardless of the user agent and secondary display
> +          considered) should be demonstrated.
>
> This was a little ambiguous at first reading.  Is the "user agent" the one
> hosting the web application or the one rendering, or both?
>
> Also, the means of evaluating the "same experience" needs to consider the
> fact that wireless displays (single-UA) and flinging (two-UA) cases will
> always have qualitatively different experiences from the user point of view.
>
> Perhaps:
>
> +          To advance to Proposed Recommendation, interoperability between
> the
> +          independent implementations should be demonstrated.
>  Interoperable user agents hosting
> +          the same Presentation API web application should be able to
> render the same
> +          content with the same functionality on multiple types of
> secondary displays.
>

​I have one concern with this text which that the above is only possible if
both the UAs support the specific type of secondary display​ and if the
display supports the content in question.

For example, if one UA can render YouTube content using a YouTube app
discovered over DIAL but another cannot connect to that display does not
mean that the Presentation API is not interoperable (that's a DIAL
interoperability problem).

Equally, If two UAs can render some piece of UHD content through a HDMI
connection but it doesn't work over a MirraCast link with only HDCP1.x this
again is not a failure of the Presentation API.

...Mark




>
> Original text #2:
>
> +          Content mirroring, whereby a web application requests display of
> +          the content rendered by the primary user agent on a secondary
> display,
> +          is out of scope.
> +          In other words, the Presentation API will not allow web
> applications
> +          to render their browsing context on another display.
> +          If a web application requests display of itself (same URL) on a
> +          connected display, a new browsing context will be created and
> +          rendered on the connected display.
>
> If the web application renders content in a separate browsing context and
> streams it to the display, that content is still rendered by the primary
> user agent.  I might say:
>
> +          Content mirroring, whereby a web application requests display of
> +          the content shown in its own browsing context (i.e., page) on a
> secondary display,
> +          is out of scope.
> +          If a web application requests display of itself (same URL) on a
> +          connected display, a new browsing context will be created with
> that URL and
> +          rendered on the connected display.
>
> m.
>
>
>
> On Tue, Jun 3, 2014 at 3:28 AM, Francois Daoust <fd@w3.org> wrote:
>
>> On 2014-06-02 14:51, Kostiainen, Anssi wrote:
>>
>>> On 02 Jun 2014, at 14:28, Francois Daoust <fd@w3.org> wrote:
>>>
>>> [...]
>>>
>>>  In the end, from a charter perspective, I would simply define
>>>> interoperability as "same content rendered and same experience regardless
>>>> of the implementation and secondary display considered" with the following
>>>> draft proposal for the Success Criteria section:
>>>>
>>>> [[
>>>> To advance to Proposed Recommendation, each specification is expected
>>>> to have two independent implementations of each feature defined in the
>>>> specification.
>>>>
>>>> To advance to Proposed Recommendation, interoperability between the
>>>> independent implementations (that is, same content rendered and same
>>>> experience regardless of the implementation and secondary display
>>>> considered) should be demonstrated. The Test Suite prepared by the Working
>>>> Group is key to success.
>>>> ]]
>>>>
>>>> Now, I agree that this does not say much about interoperability. I
>>>> suspect we all want to go beyond that but I do not see how to amend the
>>>> draft charter in that effect. Perhaps we could also say that the spec will
>>>> contain informative guidance for implementers, meaning some sort of best
>>>> practices to add support for a particular type of screen or something like
>>>> that. Any better suggestion, anyone?
>>>>
>>>
>>> Or its own Best Practices document? Given this would be non-normative,
>>> it could be either in the spec or in its own standalone document to be
>>> published as a W3C Note. We should mentioned this in the Other Deliverables
>>> section, give the group some freedom to do it either way. Feel free to
>>> propose text.
>>>
>>
>> I did include some text along these lines in my pull request, see below.
>> That said, unless someone steps up to do the work, this may not be such a
>> good idea in the end. Experience tends to show that working groups have
>> already more than enough on their plates with normative portions of a spec.
>>
>>
>>  I think we can learn from the WebRTC group in this regard, as they also
>>> need to do realistic end-to-end testing.
>>>
>>>  If the proposed charter needs to be updated on this aspect, I’d be
>>>>> happy to merge another pull request from you :-)
>>>>>
>>>>
>>>> I'd be happy to turn the proposed text into a pull request that would
>>>> also move protocols out of scope for the group if that sounds good for
>>>> everyone.
>>>>
>>>
>>> Sounds good. I’d +1 on moving protocols out of scope. Please send a PR
>>> and ping the group for review.
>>>
>>
>> I just sent such a pull request that I invite you all to review:
>>
>>  https://github.com/webscreens/charter/pull/6
>>
>> To view the updated text, either download the file and open it in your
>> browser or use some HTML previewer such as:
>>
>>
>> http://htmlpreview.github.io/?https://github.com/tidoust/
>> charter/blob/scope/index.html
>>
>>
>> Description of the changes copied below:
>> -----
>> Main changes:
>> 1. protocols have been moved out of scope
>> 2. the success criteria section mentions interoperability and attempts to
>> define it somehow.
>> 3. the other deliverables section mentions the possibility to produce
>> implementation guidelines
>>
>> More detailed list of changes:
>> - New final sentence to the "Goals" section. It seemed weird to finish
>> the section on a sentence that used the negative form without describing
>> what the group would do to solve that issue.
>> - Dropped the protocol subsection from the Scope section and reordered
>> the text in that section accordingly
>> - Added protocols to the Out of Scope section, using former text. Also
>> added a note about referencing existing suites of protocols in informative
>> notes to promote interoperability.
>> - Updated the text on content mirroring as it seemed awkward to present
>> second screens differently in that section. Plus the Presentation API is
>> not really meant to display content on screens that are "off one edge of
>> the primary screen"
>> - Dropped the Phase 2 subsection in the Deliverables section.
>> - Added the possibility to work on informative guidelines, either
>> directly within the Presentation API or within a separate Note.
>> -----
>>
>> Francois.
>>
>
>
>
> --
> http://wiki/Main/OnlyCheckEmailTwiceADay
>