Web-Based Signage BG (2nd day)

<shigeya> Scribe: Shigeya Suzuki

<shigeya> scribenick shigeya

5. Review of the Web-based Signage WG Charter document (continued)

<shigeya> futomi: Let’s start. Thank you for coming.

<shigeya> … yesterday, we discussed about what API we should develop in the working group.

<shigeya> … and gathered the idea.

<shigeya> … yesterday evening, tanaka-san and I summarized idea.

<shigeya> … We summarized into few categories

<shigeya> … 1. Power Management

<shigeya> …Both power management and power scheduling

<shigeya> … 2. Remote Prompting

<shigeya> … 3. Other contextual information

<shigeya> …. (futomi describing the categories)

<shigeya> … today I’d like to decide what APIs we will develop in our WG. That is, delete unnecessary APIs in this candidates.

<shigeya> jay: I think the process is reasonable. Two suggestions

<shigeya> … We have to check possible (there is no need to build from scracth) we can refer to other specs.

<shigeya> … another one is, I think the rebooting or some ofther… that’s a not a power management. In the case of PC, you can turn of the power, or force to shutdown, but generally, if you just want to run a reboot/shutdown command. May be that is differnt from power management.

<shigeya> … rebooting shutdown or another operation can be excluded from power management, with other titles.

<sam> scribe: sam

shigeya: show me the summary...
... NTP Server Setting API should be categorized under different name
... maybe remove "Other" from the title
... just Contextual Information for #3.

futomi: are you saying NTP server setting API is not good under #3.

shigeya: maybe itemize the NTP API to #4.

<shigeya> scribe: shigeya

kiyoshi: “other” is strange. But NTP server setting related to clock management

futomi: currently two options: 1. create a new big category, 2. restore the clock management.

shigeya: use “setting” in the title of API is awkward.

futomi: third option is delete “the NTP Server Setting API”

rgkang: I think we may postpone the decision

futomi: If this item is high-priority item, we need to decide

s/futomi: if/kiyoshi: If

kiyoshi: we’re currently discussion on category, We can decide later.

futomi: then let’s decide this later.

sgkang: regarding to the device information API
... I think one of the imporatnt information is location.
... suggest to add this.

futomi: is this configurable by operator or not?

sgkang: operator or somebody, provider, configure it.

futomi: is this for operators?

sgkang: operator and possibly developers.

kiyoshi: it’s diferrent from device information, since it’s not determined by device itself.
... in addition to that, we can include owner information or environmenal information or such.
... that kind of information, we should creaae another function

jay: wrt location, what is the difference between device information and location
... tanaka-san proposed separate API

futomi: I don’t think so.
... many other proprietrary specificaiton or open specification, location information is categoraized as device information.

<sam> scribe: sam

shigeya: maybe management info in the device information.
... just information by "get"

futomi: location info should be in a device information

jay: we shoud consider Location later
... change the level same as Device Info API

sgkang: do we need "device status" information somewhere?

shigeya: network status should be in Network Information API
... we should discuss which one we really need later.

futomi: next step is prioritize

<shigeya> scribe: shigeya

sgkang: (talking about wish list managemnet use case)
... some information of smart devices possibly be captured by the (singage) devices

<jay> device API: https://www.w3.org/2011/07/DeviceAPICharter, network info API:http://wicg.github.io/netinfo/

kiyoshi: I cannot imagine how the API works.

sgkang: we can discuss this later

kiyoshi: how we call the API?

sgkang: “interaction with other devices"

jay: I put a some example API in IRC.
... same thing happen in network information API.
... my suggestion is gather already defined APIs within W3C. After that, we can discuss the API. maybe understading API name is different each by each
... so we don’t need to invent here. If already someone generated such a API.

kihoshi: we need gap analasys to priotrize and decide how use other specs.

osamu: do we have a common architecute model for digital signage?
... if we want a using some infomration — so many sensors — then we need APIs .
... yesterday, from ITU-T model, its IP-TV model.
... it’s recieving information via broadcast.
... that is a one of the model.
... we needed to create common architecture model for web-signage for future.
... if we have such a model, it is easier to discussi

sgkang: ITU-T’s moddel can be reference to, also we can model the architecture.

<sam> scribe: sam

shigeya: we need common understanding of what digital signage
... and web-based signage
... for example needs for "location" is different from person to person.
... sometimes good things for developer is not good for operator.

<shigeya> scibe: shigeya

<shigeya> scribe: shigeya

kiyoshi: For the common understanding, create such kidn of document is important. I think it is good idea to create such a document.
... don’t you think about cerate a document?
... maybe a stake holder or signage system can be described as

osamu: it’s very helpful for reference as web-signage and web-application

kiyoshi: ITU-T has a document on architecture
... W3C is concentrated on web browser. Only we can define is reference in the context.
... we must define the worrd(or services) in detail.

<sam> scribe: sam

shigeya: what kind of group are we using? BG or WG?
... for the document.
... we need to have mutual understand of architecture of Web-Based Signage before making WG.

kiyoshi: BG and WG should be independent.
... architecture is informative document.

<shigeya> scribe: shigeya

break. let’s resume at 10:30

futomi: Let’s start last session

kiyoshi: we want to wrap-up today’s meeting.
... (we will skip emergency profile discussion)
... (Session #7 skipped)
... we had some kind of APIs to propose, but as our discussion, for priotrizing it, other existing APIs or related working groups.
... we discussed and we need time for that.
... we like to wrap-up this meeting, and want to consider next steps.
... we need some kind of consideration on architectuer. part of it is described in the profile document.
... in the discussion, lack of architecture model or architecture figure is observed.
... we decide to create an architecute model document in this BG.
... we will indicate what an API is realted to the function of the part of the model
... it is easy to understand for everyone when discussing APIs.
... now we create TODOs

(writing TODO list on screen)

<futomi> ToDo - Confirm the Architecture Model - Use cases - Identify the APIs in the model - Gap analysis - Identfy APIs which will be developed as standars in the WG

<jay> s/identfy/identify/

ToDo

- Confirm the Architecture Model

- Use cases

- Identify the APIs in the model

- Gap analysis

- Identfy APIs which will be developed as standards in the WG

(talking about how we run gap analysis and how to identify APIs to be developed)

kiyoshi: regarding architecture model, we want attendees to provide.
... Any contributions?
... No contributors at this moment, so we will call for contribution in the mailing list.

sgkang: Let me contribute
... we may want to prorpose something later, too.

<sam> shigeya: we need some basis not final-final.

<sam> scribe: sam

kiyoshi: ITUT doc is different.

shigeya: we need any input in any format.
... we don't need to discuss the details.

kiyoshi: we will just assign who is in charge.

<shigeya> scribe: shigeya

sgkang: do we create document(s)?

futomi: basially these documents will be official BG document.
... documentationis easy way to make consensus

(working on assigments on sceren)

<futomi> ToDo
1. Confirm the Architecture Model
  - Finally it will be an official BG document
  - Contributors - Shin-Gak Kang (ETRI)
2. Use cases
  - Kiyoshi Tanaka (NTT)
  - Futomi Hatano (Newphoria)
3. Identify the APIs in the model
4. Gap analysis
5. Identfy APIs which will be developed as standars in the WG

kiyoshi: next meeting of BG in this year. before end of the year, It’s esasy to gather since we’re (All attendees are Korean or Japanese) living near by.
... first meeting was in Japan. Thus, we want to have meeting in Korea.

sgkang: I have to check.

10-20 people.

(discussing on schedule for next meeting)

curernt candidate dates for meeting: Nov 22-23rd

(not confirmed yet)

<futomi> Next f2f meeting : 22,23 November (candidate) in Korea (TBC)

Second candidate is 29th-30th of November

<futomi> 29, 30 November (second candicate)

We possibly have teleconference before f2f.

shigeya will arrange, by chairs’ request.

<jay> bye

meeting finished!

see you in Korea.