On Wed, May 28, 2014 at 1:58 AM, Kostiainen, Anssi < anssi.kostiainen@intel.com> wrote: > On 21 May 2014, at 22:14, Mark Scott <markdavidscott@google.com> wrote: > > > An option proposed in MarkF's E-mail was to support an alternative URL > scheme (e.g. "dial://youtube/..."). This requires less mapping logic to be > built into the UA, and seems worth considering. I don't think we assumed > that the Presentation API would define or mandate support for any > particular scheme, just that it doesn't prevent UAs from implementing such > schemes. > > My worry is, if we allow arbitrary schemes, interop testing becomes > impossible. That’s a mandatory step in the standardization process (see > “Test suite”): > > http://webscreens.github.io/charter/#other-deliverables > > Examples of features that have bad interop record include <object>, > <embed>, <applet>, and friends. Try pages with such content on your mobile > device of choice, and generally you’ll feel sad. > Anssi, can you clarify what interoperability means in the context of this charter (and is there a W3C standard for it)? 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). m. > > Thanks, > > -Anssi > >
Received on Thursday, 29 May 2014 01:02:34 UTC