search

w3c / strategy

team-strat, on GitHub, working in public. Current state: DRAFT
156 stars 45 forks source link

Web-based Signage #67

Closed wseltzer closed 3 years ago

wseltzer commented 7 years ago

BG https://www.w3.org/community/websignage/** is drafting http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html Device Information API and is in early stages of thinking on a WG https://w3c.github.io/charter-drafts/web-based-signage-2016.html

We need to see more community review of use cases https://www.w3.org/2016/websigns/ucr/

jaykishigami commented 7 years ago

To accelerate the discussion, I hope more contribution will come.

kiyoshitanaka commented 7 years ago

Web-based Signage needs APIs that enable a web application to get the device information and to control the device via a user agent in a digital signage terminal device. BG has drafted the WG charter (http://w3c.github.io/charter-drafts/web-based-signage-2016.html).

Unfortunately, the use case document (https://www.w3.org/2016/websigns/ucr/) does not cover the use case described in Scope of the proposed charter. The use case document was based on the discussion at the very early stage of Web-based Signage BG. It was good for knowing the digital signage services but it does not cover all of the signage functions.

Needs to create new APIs are raised as the additional requirements of operational aspects posted in BG-ML (https://lists.w3.org/Archives/Public/public-websignage/2015Oct/0000.html), and BG had discussed to establish the new WG for these APIs. This background was described briefly in the advance notice (https://lists.w3.org/Archives/Member/w3c-ac-members/2016AprJun/0043.html). And, BG has discussed carefully the new APIs over one year. BG has been clarifying the gap with the existing WG's effort. Please refer the BG wiki (https://www.w3.org/community/websignage/wiki/Gap_analysis_for_chartering_the_WG).

The Web-based Signage player (JavaScript working on UA) works as a terminal device function of digital signage on the UA. There is a figure which explains Web-based Signage Player in our draft architecture document (https://www.w3.org/community/websignage/wiki/Architecture_of_Web-based_Signage). Since this player script is key of signage services, the requirements for creating it are provided as profiles in BG reports (https://www.w3.org/2016/websigns/core/ , https://www.w3.org/2016/websigns/basic-media/ , https://www.w3.org/2016/websigns/storage/). In BG discussion, the basic function of the player can be written with existing APIs and JavaScript programming, and it should be created by programmers freely with its service requirement. So, the standardization of the player itself is considered as out of scope.

Regarding the gap between the proposed APIs and WebDriver, BG has already discussed.

As for the security of API usages, the initial idea has been already described in one of the proposed API drafts (http://rawgit.com/futomi/W3C_Web-based_Signage_BG/master/device_infomation_api.html). Please see the section 5 in detail. Basically, the UA of Web-based Signage terminal device is managed by a device operator (described as a signage service operator in the API draft). So, it is needed only for the operator to use the APIs. The idea includes the two step limitation for accessing the APIs.

koalie commented 7 years ago

@shigeya reported in team-only 22-jun site meeting:

... seems like they've [BG] changed strategy ... not to create WG but join other groups such and Device and Sensors

dontcallmedom commented 6 years ago

Discussion in the DAS WG has started

wseltzer commented 3 years ago

BG suspended operations in 2019: https://lists.w3.org/Archives/Public/public-websignage/2019Sep/0001.html