IRC log of webtv on 2011-07-05
Timestamps are in UTC.
- 13:58:57 [RRSAgent]
- RRSAgent has joined #webtv
- 13:58:57 [RRSAgent]
- logging to http://www.w3.org/2011/07/05-webtv-irc
- 13:58:59 [trackbot]
- RRSAgent, make logs world
- 13:58:59 [Zakim]
- Zakim has joined #webtv
- 13:59:01 [trackbot]
- Zakim, this will be
- 13:59:02 [trackbot]
- Meeting: Web and TV Interest Group Teleconference
- 13:59:02 [trackbot]
- Date: 05 July 2011
- 13:59:02 [Zakim]
- I don't understand 'this will be', trackbot
- 13:59:12 [r]
- r has joined #webtv
- 13:59:27 [kaz]
- zakim, list
- 13:59:27 [Zakim]
- I see SW_(SPARQL)10:00AM active
- 13:59:28 [Zakim]
- also scheduled at this time are WAI_PFWG(HTML TF)9:00AM, MWI_BPWG()9:30AM, XML_(TAG TF)10:00AM, T&S_XMLSEC()10:00AM, TAG_(AWWSW)9:00AM, Team_(wf)13:19Z, UW_WebTVIG(Home
- 13:59:31 [Zakim]
- ... Net)10:00AM, VB_VBWG()10:00AM, Team_(MEET)10:00AM, Team_(RevCadence)9:00AM, IA_Team()10:00AM
- 13:59:57 [kaz]
- zakim, this will be UW_WebTVIG(HomeNet)
- 13:59:57 [Zakim]
- I do not see a conference matching that name scheduled within the next hour, kaz
- 14:00:02 [kaz]
- zakim, this will be UW_WebTV
- 14:00:02 [Zakim]
- ok, kaz; I see UW_WebTVIG(Home Net)10:00AM scheduled to start now
- 14:00:14 [kaz]
- zakim, call kazuyuki-617
- 14:00:14 [Zakim]
- ok, kaz; the call is being made
- 14:00:15 [Zakim]
- UW_WebTVIG(Home Net)10:00AM has now started
- 14:00:17 [Zakim]
- +Kazuyuki
- 14:00:28 [Zakim]
- +??P0
- 14:00:30 [kaz]
- zakim, who is here?
- 14:00:30 [Zakim]
- On the phone I see Kazuyuki, ??P0
- 14:00:33 [Zakim]
- On IRC I see r, Zakim, RRSAgent, kaz, aizu, igarashi, davidmays, trackbot
- 14:00:51 [Clarke]
- Clarke has joined #webtv
- 14:00:52 [kaz]
- zakim, ??P0 is Clarke_Stevens
- 14:00:55 [Zakim]
- +Nilo_Mitra
- 14:00:58 [Zakim]
- +Clarke_Stevens; got it
- 14:01:04 [kaz]
- zakim, who is here?
- 14:01:09 [Zakim]
- On the phone I see Kazuyuki, Clarke_Stevens, Nilo_Mitra
- 14:01:13 [NiloMitra]
- NiloMitra has joined #webtv
- 14:01:15 [Zakim]
- On IRC I see Clarke, r, Zakim, RRSAgent, kaz, aizu, igarashi, davidmays, trackbot
- 14:01:53 [Zakim]
- +Vicki
- 14:02:02 [kaz]
- agenda: http://lists.w3.org/Archives/Public/public-web-and-tv/2011Jul/0005.html
- 14:02:15 [Zakim]
- +??P14
- 14:02:19 [Zakim]
- +DongHyun_Kang
- 14:02:23 [donghyun_kang]
- donghyun_kang has joined #webtv
- 14:02:37 [aizu]
- Zakim, ??P14 is me
- 14:02:37 [Zakim]
- +aizu; got it
- 14:06:37 [Zakim]
- +Tatsuya_Igarashi
- 14:07:51 [kaz]
- Present: Kazuyuki, Clarke_Stevens, Nilo_Mitra, Vicki, aizu, DongHyun_Kang, Tatsuya_Igarashi
- 14:07:58 [kaz]
- Present+ Russell
- 14:09:06 [kaz]
- topic: Use case granularity
- 14:09:56 [Zakim]
- +Richard_Bardini
- 14:10:23 [kaz]
- Present+ Richard_Bardini
- 14:12:13 [rbardini]
- rbardini has joined #webtv
- 14:12:35 [kaz]
- kaz: there are two types: generic use cases and application specific ones
- 14:12:51 [kaz]
- ... Igarashi-san, could you please talk about your idea?
- 14:13:17 [kaz]
- igarashi: right
- 14:13:45 [kaz]
- ... as I responded to Francois, for example, I can split my issues (ISSUE-24) into three use cases
- 14:14:19 [kaz]
- ... but I'd like to talk about how to handle user scenario first
- 14:15:49 [kaz]
- ... use case should be defined based on user scenario
- 14:17:44 [kaz]
- ... the point is use cases should be described per (1) user scenario or (2) system interaction?
- 14:17:57 [kaz]
- ... and Francois proposed the former
- 14:18:11 [kaz]
- ... so if it's ok by the other participants as well, it's ok
- 14:18:43 [kaz]
- kaz: do you have any preference?
- 14:18:53 [kaz]
- igarashi: don't have any strong opinion
- 14:19:39 [kaz]
- ... btw, my second point is what kind/type of APIs should be defined
- 14:20:30 [r]
- q+ russell
- 14:20:44 [kaz]
- zakim, who is noisy?
- 14:20:53 [kaz]
- q+
- 14:20:55 [Zakim]
- kaz, listening for 10 seconds I heard sound from the following: Clarke_Stevens (9%), Vicki (29%), Kazuyuki (15%)
- 14:20:55 [kaz]
- q?
- 14:20:59 [kaz]
- ack r
- 14:21:24 [kaz]
- russell: I'm trying to describe user scenario too
- 14:22:14 [kaz]
- kaz: so you agree we discuss use case per user scenario
- 14:22:18 [kaz]
- russell: right
- 14:22:37 [igarashi]
- q+
- 14:22:46 [kaz]
- ... but if there is issue on interoperability, we need to address that concern
- 14:22:51 [kaz]
- ack iga
- 14:22:56 [kaz]
- q-
- 14:23:08 [kaz]
- igarashi: yes, that's very important
- 14:24:47 [kaz]
- ... I suggest the following: first we do based on user scenario, then categorize use cases, and if we have some category list (e.g., service specific vs. service agnostic) we can talk about them
- 14:25:47 [kaz]
- russell: I'm not sure how to handle implementation concerns
- 14:26:07 [kaz]
- igarashi: from user scenario, we can't argue system interaction
- 14:26:25 [kaz]
- ... what is the benefit to ecosystem, etc.
- 14:27:07 [kaz]
- ... we should clarify user scenario first, and then we could clarify system interaction details
- 14:27:26 [kaz]
- russell: I think the description in your use case is good
- 14:28:02 [kaz]
- ... I'm a bit concerned/wondering what would happen with actual Web pages
- 14:29:52 [kaz]
- kaz: we can add a note about implementation concern to use case description, can't we?
- 14:30:49 [kaz]
- igarashi: do you need some system interaction description to use case description?
- 14:31:00 [kaz]
- russell: yeah
- 14:31:50 [kaz]
- igarashi: we need to discuss what kind of description is needed
- 14:33:01 [kaz]
- ... it would be good for us to discuss concrete system interaction as well
- 14:33:28 [kaz]
- ... and this is related to what kind of type/level of APIs should be discussed
- 14:35:36 [kaz]
- kaz: so low level use cases need some description about concrete system interaction. right?
- 14:36:25 [kaz]
- russell: I'd describe concerns about user scenarios
- 14:38:37 [kaz]
- ... my question is application is already available when we try to discovery a device, etc.
- 14:38:48 [kaz]
- igarashi: that is next step
- 14:39:06 [kaz]
- ... we should be able talk about that kind of details later
- 14:39:36 [kaz]
- russell: sure
- 14:40:42 [kaz]
- ... what I would like to see is what the "discovery step" includes
- 14:40:53 [kaz]
- ... what the mechanism is
- 14:41:46 [kaz]
- igarashi: maybe some kind of content URI will be used...
- 14:42:27 [kaz]
- ... but such kind of discussion (system interaction requirements) should be done later
- 14:42:41 [kaz]
- ... first of all we should clarify user scenarios
- 14:42:53 [kaz]
- ... then clarify types of features
- 14:43:02 [kaz]
- ... third step is system interaction
- 14:43:13 [kaz]
- ... fourth step is @@@
- 14:43:49 [kaz]
- russell: not sure if we really want prioritization...
- 14:44:16 [kaz]
- igarashi: this IG should define prioritization
- 14:45:01 [kaz]
- russell: not quite sure about the whole IG's strategy...
- 14:45:05 [kaz]
- q?
- 14:48:04 [kaz]
- kaz: I don't think what both Igarashi and Russell are saying are 100% different
- 14:48:43 [kaz]
- ... maybe it's just that we should mention some concern about implementation or system interaction in the use case document, isn't it?
- 14:49:28 [kaz]
- russell: would like to know, e.g., what the fourth bullet expects
- 14:49:53 [kaz]
- ... I'd like to understand what is the concrete system interaction
- 14:50:01 [kaz]
- igarashi: fine by me
- 14:50:46 [kaz]
- ... before beginning system interaction discussion, I'd suggest we think about API type
- 14:52:24 [kaz]
- kaz: how about asking Russell to provide some initial description about system interaction for ISSUE-24?
- 14:52:42 [kaz]
- russell: I've already provided some description for my ISSUE-17
- 14:53:38 [kaz]
- igarashi: I think what we should do is actually quite simple
- 14:54:40 [kaz]
- ... 1. to standardize service-agnostic APIs
- 14:55:02 [kaz]
- ... 2. service specific APIS
- 14:55:07 [kaz]
- s/APIS/APIs/
- 14:55:46 [kaz]
- russell: need clarification about the terms...
- 14:56:18 [kaz]
- igarashi: "rendering application" could be a service
- 14:56:47 [kaz]
- ... and service-specific APIs relies on the rendering application
- 14:57:48 [kaz]
- ... then 3. standardized document
- 14:58:36 [kaz]
- russell: in terms of "rendering", I'm not quite sure about service-specific API means...
- 14:58:57 [kaz]
- igarashi: for example, play-printer()
- 15:00:28 [kaz]
- ... on the other hand, HTTPXMLRequest is not application/service specific
- 15:01:42 [Zakim]
- -Richard_Bardini
- 15:01:44 [kaz]
- ... if there is no more comment, I'd go ahead and think about types of APIs
- 15:04:42 [kaz]
- igarashi: 1. service-agnostic, 2. service-specific and 3. document format via the API
- 15:07:20 [Zakim]
- -Vicki
- 15:08:08 [kaz]
- s/document format via the API/service-agnostic API and service-specific document via the API/
- 15:08:51 [kaz]
- ... and my suggestion is that all the use case submitter should mention those options
- 15:09:07 [kaz]
- ... in their use case proposal
- 15:09:49 [kaz]
- [ adjouned ]
- 15:10:00 [kaz]
- s/adjouned/adjourend/
- 15:10:27 [kaz]
- rrsagent, make log public
- 15:10:35 [kaz]
- rrsagent, draft minutes
- 15:10:35 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/07/05-webtv-minutes.html kaz
- 15:11:02 [Zakim]
- -Nilo_Mitra
- 15:11:06 [Zakim]
- -DongHyun_Kang
- 15:12:16 [Zakim]
- -Clarke_Stevens
- 15:30:35 [kaz]
- Chair: Kaz
- 15:30:40 [kaz]
- Regrets: Matt
- 15:30:44 [kaz]
- rrsagent, draft minutes
- 15:30:44 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/07/05-webtv-minutes.html kaz
- 15:46:33 [Zakim]
- -aizu
- 15:46:35 [Zakim]
- -Tatsuya_Igarashi
- 15:46:37 [Zakim]
- -Kazuyuki
- 15:46:38 [Zakim]
- UW_WebTVIG(Home Net)10:00AM has ended
- 15:46:40 [Zakim]
- Attendees were Kazuyuki, Nilo_Mitra, Clarke_Stevens, Vicki, DongHyun_Kang, aizu, Tatsuya_Igarashi, Richard_Bardini
- 15:57:40 [igarashi]
- igarashi has joined #webtv