Re: Interoperability and protocols in draft WG charter

Hi Mark,

Thanks for the review and suggested texts. I agree with both 
clarifications and updated the pull request accordingly:
https://github.com/webscreens/charter/pull/6/commits

Francois.


On 2014-06-03 21:10, mark a. foltz 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.
>
> 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
> <mailto: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
>         <mailto: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
>     <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
>     <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

Received on Wednesday, 4 June 2014 09:56:30 UTC