Interoperability and protocols in draft WG charter (was: Re: Draft of Second Screen Presentation Working Group Charter available)

Hi Anssi, Mark and others,

On 2014-05-30 16:22, Kostiainen, Anssi wrote:
> 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?

Ah well, that's a very simple question for which I do not have a good 
answer, I'm afraid.

 From a process perspective, the W3C Process document defines 
interoperability as a goal and points out that "the Working Group SHOULD 
be able to demonstrate two interoperable implementations of each 
feature" when it requests publication of a spec as a Proposed 
Recommendation:
   http://www.w3.org/2005/10/Process-20051014/process.html#cfr

The Process document does not define "interoperability" though, more or 
less on purpose because its precise definition also depends on the 
context. In short, there is no W3C standard for "interoperability"... 
but there are still expectations that it will be addressed.

The charter is thus a good place to detail what the Working Group has in 
mind (exit criteria at the Candidate Recommendation phase are another 
such good place, but it comes much later in the life of a WG, so charter 
should definitely be preferred). For instance, the charter of the WebRTC 
WG specifies the expected result in the success criteria section:
[[
To advance to Proposed Recommendation, interoperability between the 
independent implementations (that is, bidirectional audio and video 
communication between the implementations) should be demonstrated.
]]
http://www.w3.org/2011/04/webrtc-charter.html

That definition addresses one possible scenario for the Presentation API 
but other scenarios that the Presentation API aims to enable do not even 
involve a second browser, e.g. when the screen is connected through HDMI 
or some wireless equivalent.

I think Mark captures possible interpretations quite well. Looking at 
the list given two browsers UA1 and UA2:

>> 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).

The quoted sentence of the WebRTC charter would match point 2 above. As 
said, I do not think that is a good way to define interoperability in 
the context of the Presentation API because it only addresses one 
possible scenario.

Point 3 depends on whether protocols are in scope for the group. I see 
that you have discussed protocols at length in the past and that the 
draft charter contains a tentative section on protocols. I would leave 
protocols out of scope for the group. As far as I can tell, browsers may 
not even implement the protocols themselves to support a given type of 
screens and may not even know how the screen is attached. In other 
words, I would not be surprised to hear that e.g. a browser can support 
remote Miracast displays if the OS supports Miracast with the same piece 
of code as for the HDMI case (or is that unrealistic?).

Point 4 is interesting for testing purpose but I am no sure how this 
will be achieved in practice so would stay silent in the draft charter 
other than to emphasize the importance of the "test suite" mentioned in 
the Other Deliverables section.

Not much remains, unfortunately... I would extend point 1. to include 
some notion of "content rendering" (*). In other words, a browser 
conforms when it sends the right events/messages and actually renders 
the content on the controlled screen using usual rules.

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?


>
> 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.

Thanks,
Francois.


(*) I should note that specs that involve "screen" and "rendering 
content" remain a bit fuzzy, actually. For instance, in the rendering 
section of HTML5:
[[
The suggestions in this section generally assume a visual output medium 
with a resolution of 96dpi or greater, but HTML is intended to apply to 
multiple media (it is a media-independent language). User agent 
implementors are encouraged to adapt the suggestions in this section to 
their target media.
]]
and
[[
An element is being rendered if it has any associated CSS layout boxes, 
SVG layout boxes, or some equivalent in other styling languages.
]]
http://www.w3.org/html/wg/drafts/html/master/single-page.html#rendering

Same thing for the conformance section in CSS, e.g.:
[[
The inability of a user agent to implement part of this specification 
due to the limitations of a particular device (e.g., a user agent cannot 
render colors on a monochrome monitor or page) does not imply 
non-conformance
]]
http://www.w3.org/TR/CSS21/conform.html#conformance

Received on Monday, 2 June 2014 11:29:24 UTC