Re: Interoperability and protocols in draft WG charter

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.

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