- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Fri, 30 May 2014 14:22:11 +0000
- To: Francois Daoust <fd@w3.org>
- 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>
Hi Francois, On 29 May 2014, at 04:01, mark a. foltz <mfoltz@google.com> wrote: > Anssi, can you clarify what interoperability means in the context of this charter (and is there a W3C standard for it)? Francois - I think you’d be in the best position to clarify W3C’s criteria and expectations for interoperability for Rec Track deliverables to Mark? If the proposed charter needs to be updated on this aspect, I’d be happy to merge another pull request from you :-) > I believe this would benefit from some clarification in the charter. Here are some possible interpretations for two theoretical browsers UA1 and UA2 that I came up with. > > 1. UA1 and UA2 are able to render and control a reference set of presentations on some screen using any technology of its choice. Only the behavior of the API matters (as long as it sends the right events/messages it conforms). > 2. UA1 is able to render a presentation on UA2 and control it, and vice versa. > 3. If UA1 and UA2 implement the same technology (e.g., Airplay) , they must conform to the spec for that mechanism and interoperate with screens that support that technology. > 4. UA1 and UA2 must be tested to interoperate via Presentation API with a reference set of non-browser-based devices independent of the underlying technology (e.g., API-level conformance). > > None of the senses of "interoperability" listed above seems to exclude the use case described in this thread, especially if we incorporate a test suite for DIAL (under #3/#4). Thanks, -Anssi
Received on Friday, 30 May 2014 14:22:50 UTC