- 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