abstract and introduction

[jpiesing]

Proposal for the abstract:

This specification addresses a number of topics relating to the integration of an HTML5 UA with a media device. These are mainly ones which providers of media web apps and others have found it necessary to specify due to not being done appropriately or correctly. The primary audience for this specification is those integrating an HTML5 UA onto a media device who did not develop the HTML5 UA themselves. Many of the requirements in this specification will be obvious to HTML5 UA developers.

[jpiesing]

Proposal for the introduction:

Integrating an HTML5 UA onto a media device is a lot more than just porting the code. Media devices may have different user input devices than those assumed by some UAs (e.g. a remote control rather than a keyboard or touchscreen). The video and audio output devices may have different characteristics (e.g. latency, event generation) than those assumed by a particular UA. Video and graphics composition may be very different from that what is assumed by a particular UA. The browser UI may behave differently or there may not be one at all. On some media devices it may not be appropriate to ask the user to make choices that would be appropriate to ask on a PC, tablet or phone. Historically media devices have had limited hardware resources than other devices. Features implemented in the code base of the HTML5 UA that require underlying hardware support may not be provided with enough resources. Expectations that seem obvious to those active in the web may not be met if they are not explicitly documented or are simply missed in the many web specifications. It is hoped that by gathering these topics into one place will bring more involvement from the web ecosystem and provide something which can help these integration issues to be addressed earlier rather than later and hence save time and money for media device integrators / manufacturers and for media web app developers. Some providers of media web apps have found it necessary to develop and maintain their own specifications and test / certification regimes addressing topics like these. Some other standards organisations using web standards in media devices have found it necessary to include topics like these in their own specifications and test / certification regimes. This specification should be something which media web app developers and standards organisations related to media devices can reference from their own specifications. Additionally this specification has been written in a way that will enable test cases to be developed which providers of media web apps and media device centric standards organisations can reference from their test / certification regimes. This specification is being developed in close cooperation with the CTA WAVE Project.

[jpiesing]

@mavgit What do you think of these?

[andyburras]

Looks good to me. Is it worth saying something about the term media device? e.g. "In this context, media devices include (but are not limited to) televisions, set top boxes, gaming consoles, personal computers, tablets, mobile phones, ..."

[jpiesing]

Looks good to me. Is it worth saying something about the term media device? e.g. "In this context, media devices include (but are not limited to) televisions, set top boxes, gaming consoles, personal computers, tablets, mobile phones, ..."

@andyburras I was using media device as shorthand for everything that isn't PC, phone or tablet. How about this for the abstract.

This specification addresses a number of topics relating to the integration of an HTML5 UA with media-related features in PCs, tablets, phones and media devices. A number of topics specific to media devices are also addressed. These topic are mainly ones that providers of media web apps and others have found it necessary to specify due to not being done appropriately or correctly. The primary audience for this specification is those integrating an HTML5 UA onto a device who did not develop the HTML5 UA themselves. Many of the requirements in this specification will be obvious to HTML5 UA developers.

[mavgit]

My main concern is that I don't want to see this spec or any WAVE spec branching away from the evolving Web platform, represented by the four browser code bases we've previously identified.

In this regard, I can classify possible requirements into three categories:

1. De Jure: Gathering existing spec requirements relevant to integrators:

Existing W3C & IETF specifications that need to be implemented as-is by the web client integrator that are fine as specified, but are strewn across dozens of specifications over hundreds of pages that no integrator can reasonably be expected to find.

Example: the existing W3C requirements for key code usage are fine, but hard to find.

In this category, the work would be finding these requirements in existing specs and summarizing them in the porting spec.

I see no danger of these requirements branching away fro the Web platform. In fact, gathering these requirements in one place will likely bring third party browsers more in line with the web platform.

Note: Since these likely all relate to specs that are included in the Web Media API Snapshot spec, this work could also just be part of the testing effort for the API Snapshot spec and not part of the Integration spec.

2. De Facto: New requirements based on current browser practice:

New requirements that don't exist in current W3C & IETF specifications, but that match existing practice.

Example: the IETF HTTP spec has no mandated minimal cookie support, but existing Web browser practice is to support a minimal number of cookies.

In this category, we'd write strengthened specs based on current browser practice, such as current browser minimal cookie support.

Note: In addition to publishing these in the CG Integration spec, these could also each be submitted as issues against the original specs as suggestions to change the specs to match current deployment reality.

It would seem that these requirements would bring third party browsers more in line with the web platform as deployed. I'd like to hear from browser companies on this.

3. De novo: Anything that doesn't fit in the above two categories:

I'm most concerned that requirements that aren't included in either current Web specifications or in current Web practice could branch third party browsers away from the evolving web platform. Again, I'd like to hear from browser companies on this.

[andyburras]

Since these likely all relate to specs that are included in the Web Media API Snapshot spec, this work could also just be part of the testing effort for the API Snapshot spec

I think there may be an issue here for conformance testing. Currently the Web Media API Snapshot spec is mainly a reference to a large number of W3C specifications in their entirety (aside from a few "Exceptions" clauses). However, my understanding is that none of the four major browsers would pass 100% support (?). If this is the case then we cannot build/specify a conformance test suite based solely on this specification. We need some subset of functionality that all WAVE compliant devices are guaranteeing to support.

[mavgit]

@andyburras Your comment https://github.com/w3c/webmediaporting/issues/26#issuecomment-337550975 brings up an important issue we should discuss, but it's really about the Web Media API Snapshot Spec. Could you please re-enter this comment as a new issue in the API spec repo: https://github.com/w3c/webmediaapi/issues

Thanks!

[andyburras]

Done. Raised as https://github.com/w3c/webmediaapi/issues/116