See also: IRC log
<scribe> Scribe: shigeya
<scribe> Scribe: Shigeya Suzuki
<scribe> scribenick: shigeya
<futomi> The URL of the wiki page for this meeting is here. https://www.w3.org/community/websignage/wiki/Group_meeting_at_TPAC_2016
<futomi> s/URK/URL/
futomi: Time to start. thank you
for coming.
... we will discuss about charter and working group.
... but at beginiing we want to share experiences.
... tanaka-san of NTT and shigeya suzuki of Keio describe the
current topics.
... tanaka-san act as co-chair for today.
... first-part is self introduction
... Futomi Hatano of Newphoria.
kiyoshi: [self-introduciton continues]
sam: [Sam Sugimoto, of W3C speaks as Team contact]
futomi: meeting agenda: https://www.w3.org/community/websignage/wiki/Group_meeting_at_TPAC_2016
[self-introduction part resumes]
jay: I’m AB. I hope for fruitful discussion.
<jihye> Jihye Hong, LG Electronics
futomi: Agenda bashing.
... first part is information sharing.
... second part is implementation status sharing.
... in the afternoon, we like to review the charter
document.
... it’s already publisehd on net, and some of the members met
to discuss, but we’d like to discuss in detail here.
... if we don’t complete today, we will continue meeting in
tomorrow.
kiyoshi: there is discussion on
emergency profile. I’m wondering if Mr. Han is working on the
document.
... he doesn’t prepare the document, we’ll skip that part.
futomi: sharing of current
activities.
... we have published several documents.
... you can read these document on the BG web site
(showing use-case document)
(showing the three published profile documents )
kiyoshi: these documents inludes architecture discussion?
jay: is there necessity to update these documents?
futomi: there are new APIs
emerged for web-based signage. For example, currently we can
store data in computer using index database API or file sytem
API. Late file system API is obsoleted.
... for new file system API deploped,
... if new useful API implemtend for browsers then we will
update new documents.
sgkang: what is next step for the deliverable?
futomi: last of the meeting, we
decided to close this BG if WG is created.
... if the working group created, we cant update as BG.
... I think we can update as working grop
kiyoshi: really?
... we can create and use CG for updating and getting
feedbacks.
sgkang: how about core profiel document?
scribe: for this document, we
need to update.
... tilte is currently “architecture..” but this document does
not include architecutre discussion
futomi: is the title confusing
sgkang: yes.
futomi: Then, let’s change
title.
... actually, this document documents requirements
kiyohsi: I think sec.2 includes
architecture discussion, but just a observation on WBS
... in adition ITU-T is right place to discuss such kind of
architecture
... next topic, we have collaboration issue
sgkang: so all three profile docuemnst has same issue.
futomi: let’s move onto next
slot
... liaison with ITU
kiyoshi: at last TPAC. we got
liaison letter from ITU-T.
... finally we replied to ITU-T.
<futomi> https://www.w3.org/community/websignage/wiki/images/c/c8/RLS.pdf
(kiyoshi describing the letter)
kiyoshi: we didn’t get the reply
to this liaison letter, but ITU-T has intention to share.
... I want to ask @3@ to discuss
(Shin-Gak Kang describing )
sgkang: (Introduction to SG16
Q14)
... (Technical paper on “Digital signage: web-based digital
signage”, target date: 2017)
kiyoshi: I have one issue for
this slide. ITU-T discuss about some kind of web-runtime
... runtime on top of operation system.
jay: any crucial diffence between W3C and ITU-T? I think collaboration is great, but there are cruicial difference we need to understand
sgkang: this group focus on
web.
... we don’t want to develop same document. we can find cross
collaboraiton
kiyoshi: on 15th page. This is
one of the collaoboration item.
... hatano-san’s document is focusing on some of
components.
... the figure shows overall architecture.
... just map profile document to ITU-document
... if our group have comment to ITU-T document, it will be a
collaboration item.
sgkang: we have to update document accordingly.
futomi: How about liaison?
kiyoshi: currently with BG. how we can continue it?
sam: as long as BG continues
that’s okay.
... in terms of WG, we have to restate relationship.
... I have to double-check
futomi: CG and ITU-T can connect (collaborate?)
sam: i have to check.
kiyoshi: I mentioneed in the figure above.
futomi: in my opinion, DS client
is part of runtime. but (for me) DS client is just a HTML5
application.
... we will develop new API between HTML5/applicaitonlayer and
runtime layer
sgkang: we have to develop native applicaiton to support. If this group create API, we can use the API without developing native applicaiton.
kiyoshi: there is OS+runtime box (connectd at right)
triblondon: I’m from TAG. so have
preseonal interest.
... interest on crossing between this group and other W3C
activities
... especially on Web Driver
... interested in how WBS group extend it’s scope (like
controling sleep, such)
kiyoshi: havent’ decided yet.
it’s part of on-going discussion.
... we want to more effective/attractive with ??-browser. may
be some kind of management API useful for operator or some kind
of web signage provider.
triblondon: this diagram is
interesting for me too.
... it’s important to charter.
<sam> scribe: sam
shigeya: implimentation is
platform dependant
... we should have a figure we can share
... we want to make a generic figure with specific
wording.
... W3C and ITUT have different terminology
<shigeya> scribe: shigeya
kiyoshi: @5@ document is member only.
sgkang: we can update and provide if possible.
futomi: If it is difficult to open document to public, then we can use private mailng list?
kiyoshi: it’s ITU-T matter so not
so simple.
... this document is at same status as W3C document
osamu: it’s important check the
relationship status. How to make good relatinship with ITU-T
and W3C wrt web based signage.
... we got information of ITU-T (thanks!) then we should think
how to collaborate.
kiyoshi: ITU-T don’t send
document. we can request documents.
... one option is request document to send from me .
sgkang: it’s depends on meeting
in Dec. But for collaboration, and getting coments, it’s
useful.
... (without approval, we can’t send document )
futomi: next topic is charter.
<sam> scribe: sam
<shigeya> https://lists.w3.org/Archives/Public/public-websignage/2016Jul/0000.html
shigeya: please open the email on
the link
... we moved out document from google docs to github
... let me review what's happening
... first draft last October
... and continue to draft 5 at march 2016
... sent W3M for intention to send the charter for AC
Review
... updated with W3M's requests
... last fix#3 was made in June 1, 2016.
... 3 issues
... (explaining 3 issues described in the email)
... I think the document are done at this point.
kiyoshi: last year we talked
about which API we need
... finally we have draft charter
... current charger is here
<shigeya> http://w3c.github.io/charter-drafts/web-based-signage-2016.html
<shigeya> scribe: shigeya
kiyoshi: (kiyoshi describing the draft charter)
sgkang: you mentioned DSC. Is that an external organization?
kiyoshi: we included DSC as information source.
futomi: (break till 11am)
futomi:next topic is introductions of implementations.
... first presenattion is by kiyoshi
https://www.w3.org/community/websignage/wiki/images/1/18/160922Web-based_Signage-NTT.pdf
(kiyoshi presents his slides)
jay: one of the imporatant point
is, universal design
... audience can be anybody
... one of the content shown is no color universal design in
mind.
sangwhan: have you ever been to Japan? (joking)
kiyoshi: that’s very imporant
point. this is just a example. maybe some kind of methods
provoing foreingn people or desabled people must be
supported.
... we at NTT, some people working on universal design, so we
can make use of it.
sgkang: on “web based content”: there are several applications. last one. what is… use cases? what is the point?
kiyoshi: i want to comment on..
we can use other services already deployed on internet or
cloud. requirement of cthe content for such kind of language
translation is normal usecase for foreign people. but webbased
content is a also a web content, so that we can use such kind
of services
... if we can use such kind of services inexpensively.
futomi: next, my turn.
(futomi presenting his slides)
kiyoshi: Futomi shown some ideas
of APIs.
... we want to consider API as detailed proposal for
existing
kgkang: regarding display
setting, how about getting display information?
... resolution, physical information can be.
<sam> shigeya: I think our charter and Futomi's API is different
<sam> scribe sam
<sam> ... do you want to modify or add new one.
<sam> kiyoshi: we discuss this in the afternoon
<scribe> scribe: shigeya
@5: on slide 14, why you need such information?
futomi: it’s related universal
plug-and-play. For exapmle, model number is not known to users.
Our consumers know friendly name.
... For example, sony bravia 42 is a friendly name.
... but operator want to know both inforamtion.
... many TV sets have both friendly and model number.
(Jihye Hong, LG, presenting her slides)
“use cases in LG webOS Signage”
jihye: on multiple screen, using WebSocket, one of the display acts as master. using master-slave model.
jay: my understanding is, webOS is propriaetary OS. If so, why you need to standardize it.
jihye: we prefer to use standardized API.
jay: do you have any plan to publish part of the implementation?
<sangwhan> http://www.openwebosproject.org
jihye: webOS is open sourced.
osamu: This seems imporant for
multi-display setting.
... message passing with WebSocket. Do you have any desigin
thoughts on contents manager and display?
jihye: we’re using controller to handle multiple signage
igarashi: JavaScript using websocket to sync or not? or webOS?
jihye: webOS
igarashi: what’s the role of the API?
jihye: API assigned display IDs and position. webOS then controls it.
kiyoshi: do you consider to implement multi-screen std?
igarashi: do you have interest to integrate the spec to multiscreen?
Hyojin: yes (?)
sangwhan: on last two
presentations. two things are not in charter.
... display control. chater has power but not display
bits.
... hatano-san mentioned NTP, how about video-sync?
futomi: my implementation works at 100ms order
sangwhan: there was a CG talking
about synchronization
... using multicast. every screen tunes into…
(sangwhan drawing)
sangwhan: there is many ways to solve it.
igrashi: LG’s solution is syncing
by webOS
... possibly the sync technology itself should be
standardized...
... possibly making use of CSS
sangwhan: having two clocks are bizarre
igarashi: we want to talk just about clock or synchornization techonology?
sangwhan: there is techology called PTP.
osamu: we should undestand how to
handle multiple display.
... single OS manage display. there is several scheme to handle
multi screen.
sangwhan: LG has implmeentation. since standardization require implementation, thus it’s good.
osamu: SONY has another technology?
igarashi: we have, but whether we
can standardize or not unknown.
... how the display know the source of the video?
jihye: same video to each signage. each signage know its position and clip it.
igarashi: how that the JavaScript
should set HTML video?
... what kind of HTML source used?
(all videos configured to each of display)
igarashi: whether we can standardize is another discussion.
sangwhan: if worker swapped two displays, it will not work…
futomi: it’s lunch time.
(Toshihiko Yamakami, ACCESS presents slides)
https://www.w3.org/community/websignage/wiki/images/6/6a/ACCESS_web-based_signage_introduction.pdf
osamu: we’re disucssing standardization. Can ACCESS contribute to it?
yamakami: Yes.
sangwhan: is it based on Chromium?
yamakami: we have several implementaiton. I don’t know which one.
luch time. next slot starts at 13:15pm
(resuming at 13:20pm)
futomi: next presentation is by sgkang.
https://www.w3.org/community/websignage/wiki/images/8/8e/TTA.pdf
(sgkang presenting his slides)
“Standardization of Digital Signage Service Platform based on HTML5 in TTA”
TTA = Telecommunications Technology Association
igarashi: in case of Samsung Smart, do they use HTML5?
sgkang: their own solution (not
tizen)
... they provide SDK
igrashi: their own OS?
sgkang: based on Android
futomi: is digitalsignage.com a Korean compnay?
sgkang: no
<Zakim> jay, you wanted to comment on interoperability
jay: I have question on
interoperability.
... what kind of service require interoperability?
sgkang: They’re using proprietary solution, but if stndard exists, they’ll adopt them.
igarashi: If it is not secret, how many companies attending TTA?
sgkang: 10 SMEs.
(SME = Small and Medium Enterprises)
jay: is there any requirement by Korea government to show alert or emergency (notificiation) ? are there such?
sgkang: yes.
igarashi: Is current spec public?
sgkang: just open to TTA members.
igarashi: is there possibilty to have a liaison to make these documents avaiable for us?
sgkang: I will check.
futomi: In this slot, we will
discuss what kind of APIs we want to develop and who will edit
the spec.
... currently, charter draft describes three categories.
... today I propose four APIs in Other Contextual Information
category.
kiyoshi: to drafting API specs,
we need three things: 1) use case, 2) feature , 3) gap
analysis
... we want to start with use cases?
... in the morning, we have shown various APIs needed.
futomi:
1 Power Management
2
Remote Prompting
3 Other Contextual Information
3-1 Device
Information API
3-2 Network Information API
3-3 Display Setting
API
3-4 NTP Server Setting API
futomi: It is clear to include 1,
3-1, 3-2, 3-3, 3-4 in the charter
... for me, 3-1 and 3-2 has priority. If no one has interest
3-3 and 3-4, we may want to delete them.
... I think 3-4 and 3-4 are not essential according to my
experience.
kiyoshi: this group want to decide priority
sgkang: any relationship between 1 and 3-3?
futomi: (power) status of display and terminal is different.
sgkang: there different menanings of power management.
igarashi: Is there any explanation of the API?
futomi: All of panel includes OS and LCD and speaker or whatever.
igarashi: Have to describe in
detail.
... adding the short description ot each API might be
useful.
<sam> scribe: sam
shigeya: what is OS mean in this
context?
... maybe device.
<shigeya> scribe: shigeya
kiyoshi: power management might be not good word here…
(discussing on “Power Managent API” title and description)
jihye: display backlight control also.
igarashi: control the luminance
of display screen
... it’s a dimmer
... its not a level of brightness
jay: we should not discuss
details. we need to discuss concept for API requirement.
... scheduling or rebooting is kind of OS control. it is easy
to mix into powre management. We have to disucss at high-level
APIs.
igarashi: my suggestion is list up first, and decide whether it is suitable or not later.
jay: we’re not in brainstorming time.
sgkang: we need rebooting, power
(consolidating) something.
... rebooting is in power management. I’m not sure on display
(setting or control).
igarashi: list and discuss later
is a good strategy.
... targe is finishing this all APIs till tomorrow?
futomi: yes.
... my idea is we will gather everybody’s idea, tomorrow, we
will discuss again.
... could you give us idea on APIs?
igarashi: Not just about power management, any APIs?
futomi: I think 3 is good
enough.
... if you have any idea, I’d like to hear.
igarashi: current draft includes device info?
igarashi: only about query information, right?
(3-2 now includes items from Futomi’s presentation)
igarashi: Let’s discuss on device information API
kiyoshi: How do we use this APIs?
futomi: by administrators
igarashi: for what purpose?
futomi: what type of hardware adminstrator have to know.
igarashi: what they do once they know the info?
futomi: I want to know the location of the terminal, and name (type) of terminal.
kiyoshi: we give each terminal a number.
igarashi: pelase describe the situation, not how it is good or not
futomi: mainly, seriail number used for access control to cloud.
igarashi: another example is physical screen size. need it?
futomi: it’s useful
information.
... terminal specic information.
kiyoshi: once get it, after that,
we keep it in CMS?
... just get
<sam> scribe: sam
shigeya: maybe serial number is just good enough
<jay> there are two kinds of info: informative and normative
shigeya: we should know which information is crutial
futomi: some redundant info is useful for developer
shigeya: we shoud reduce down to reasonable information.
igarashi: info for human not for machine
futomi: same as network management. we need all info possible.
<shigeya> jay: informative information is useful. In the case of operation, maybe we only need the location of the device and resolution or height or power requirement, such a metadata is required by the operaiton.
<shigeya> … so in the sense of operation, API should limit to normative meta data
<shigeya> scribe: shigeya
futomi: we have to distinguish them.
igrashi: we’re talking about device information.
sgkang: we need info on remote management.
<sam> scribe: sam
shigeya: sensor info is different from device info.
<shigeya> scribe: shigeya
igarashi: how these sensor information is useful?
osamu: changing contents according to sensors
jihye: proximity sensor is useful
for...
... changing display according to the distance.
(adding sensing and ambient)
kiyoshi: on 3-1: original four items: serial number, manufacturer name, model number, friendly name
<sam> shigeya: maybe more info for diagnosing
<sam> ... we can adjust items here.
<scribe> scribe: shigeya
futomi: on 3-3
kiyoshi: we have discussed about dimmer.
igarashi: how about color space control?
<jay> is the same concept of network information API with http://wicg.github.io/netinfo/
kiyoshi: on remote prompting
Louay of Fraunhofer: I thikn it’s related for on signage. Use like alert show dialog. so, then, you can’t control it anymore.
scribe: I think for digital
signage, it is imporant to change behavior. As synchronized
operation.
... Now for mobile browser, browser shows dialog.
... may be you need to this alert or message alert box invoked
on this screen to your management function.
... but the question is, if the funciton does make sens.
... other way is documentaing practices.
... (asynchronous vs synchronous)
... at second secreen WG, there are two APIs presentation APIs
and (…)
<jihye> @9/louay
scribe: Goal of presentation API
is open in browser and launch on other screen.
... (like chromecast)
... goal of this API is standardization
... other implementaiton might use smartphone screen bound by
NFCs.
igarashi: in case of use of Presntation API…
louay: presentation API initiated
by (for example) smart phone, then connect to large
screen.
... presentation API requiers both devices on same network.
igarashi: Will we mention
relationship?
... we might need guidelines how to use this kind of APIs.
kiyoshi: we must consider relationship
We resume our meeting 9am tomorrow morning
<sam> rragent, make minutes
<sam> rrsagenet, make minutes