- From: Francois Daoust <fd@w3.org>
- Date: Tue, 03 Jun 2014 12:28:31 +0200
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- CC: Mark Scott <markdavidscott@google.com>, "mark a. foltz" <mfoltz@google.com>, "Rottsches, Dominik" <dominik.rottsches@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Mark Watson <watsonm@netflix.com>, "Bassbouss, Louay" <louay.bassbouss@fokus.fraunhofer.de>, Philipp Hoschka <ph@w3.org>, Daniel Davis <ddavis@w3.org>
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.
Received on Tuesday, 3 June 2014 10:29:29 UTC