- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 06 Jul 2011 03:17:18 +0900
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
available at:
http://www.w3.org/2011/07/05-webtv-minutes.html
also as text below.
--------------------------
Kaz's note and suggestion
--------------------------
When we started the call today, I thought the point was "what level of
granularity is expected for use case description". However, it seems
there are two specific (and a bit different from "granularity") points
proposed by Igarashi and Russell.
I think both Igarashi's proposal and Russell's proposal are not only
related to their own issues but related to all the use case
descriptions. On the other hand, I'm not 100% sure whether all the
other use cases also have to explicitly define their proposed features
or not.
So I'd suggest we create a "Product", e.g., "Use Case Description" in
the Tracker and continue the discussion on their proposals separately
from use case discussion itself. Maybe we can clarify their points a
bit more on the mailing list by the next call on July 12th.
What do you think?
FYI, I think the summary of the points of Igarashi and Russell are as
follows. I talked with Igarashi after the TF call and got
clarification. However, unfortunately Russell had to leave right
after the call, so maybe I couldn't capture Russell's point
completely. Russell, please add modification if needed.
Igarashi's point: API category
-------------------------------
As recorded in the minutes, Igarashi proposes all the use case
descriptions should clarify what type of use case that discusses,
e.g., one of the following for further discussion in the next step:
- Type1: service-agnostic
- Type2: service-specific
- Type3: service-agnostic API and service-specific document via the API
Russell's point: concrete system interaction description
---------------------------------------------------------
Even though we're concentrating on use cases and user scenarios,
Russell is a bit concerned about actual system interaction for each
user scenario. So (I think) he suggests we should add system
interaction description to use case description. Some example
description is available in ISSUE-17 at:
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/UPnPHomeNetworkUA
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Home Networking Task Force Teleconference -- 05 Jul 2011
05 Jul 2011
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-web-and-tv/2011Jul/0005.html
See also: [3]IRC log
[3] http://www.w3.org/2011/07/05-webtv-irc
Attendees
Present
Kazuyuki, Clarke_Stevens, Nilo_Mitra, Vicki, aizu,
DongHyun_Kang, Tatsuya_Igarashi, Russell, Richard_Bardini
Regrets
Matt
Chair
Kaz
Scribe
kaz
Contents
* [4]Topics
1. [5]Use case granularity
* [6]Summary of Action Items
_________________________________________________________
<trackbot> Date: 05 July 2011
Use case granularity
kaz: there are two types: generic use cases and application specific
ones
... Igarashi-san, could you please talk about your idea?
igarashi: right
... as I responded to Francois, for example, I can split my issues
(ISSUE-24) into three use cases
... but I'd like to talk about how to handle user scenario first
... use case should be defined based on user scenario
... the point is use cases should be described per (1) user scenario
or (2) system interaction?
... and Francois proposed the former
... so if it's ok by the other participants as well, it's ok
kaz: do you have any preference?
igarashi: don't have any strong opinion
... btw, my second point is what kind/type of APIs should be defined
russell: I'm trying to describe user scenario too
kaz: so you agree we discuss use case per user scenario
russell: right
... but if there is issue on interoperability, we need to address
that concern
igarashi: yes, that's very important
... 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
russell: I'm not sure how to handle implementation concerns
igarashi: from user scenario, we can't argue system interaction
... what is the benefit to ecosystem, etc.
... we should clarify user scenario first, and then we could clarify
system interaction details
russell: I think the description in your use case is good
... I'm a bit concerned/wondering what would happen with actual Web
pages
kaz: we can add a note about implementation concern to use case
description, can't we?
igarashi: do you need some system interaction description to use
case description?
russell: yeah
igarashi: we need to discuss what kind of description is needed
... it would be good for us to discuss concrete system interaction
as well
... and this is related to what kind of type/level of APIs should be
discussed
kaz: so low level use cases need some description about concrete
system interaction. right?
russell: I'd describe concerns about user scenarios
... my question is whether application is already available or not
when we try to discovery a device, etc.
igarashi: that is next step
... we should be able talk about that kind of details later
russell: sure
... what I would like to see is what the "discovery step" includes
... what the mechanism is like
igarashi: maybe some kind of content URI will be used...
... but such kind of discussion (system interaction requirements)
should be done later
... first of all we should clarify user scenarios
... then clarify types of features
... third step is system interaction
... fourth step is @@@
russell: not sure if we really want prioritization...
igarashi: this IG should define prioritization
russell: not quite sure about the whole IG's strategy...
kaz: I don't think what both Igarashi and Russell are saying are
100% different
... maybe it's just that we should mention some concern about
implementation or system interaction in the use case document, isn't
it?
russell: would like to know, e.g., what the fourth bullet expects
... I'd like to understand what is the concrete system interaction
igarashi: fine by me
... before beginning system interaction discussion, I'd suggest we
think about API type
kaz: how about asking Russell to provide some initial description
about system interaction for ISSUE-24?
russell: I've already provided some description for my ISSUE-17
igarashi: I think what we should do is actually quite simple
... 1. to standardize service-agnostic APIs
... 2. service specific APIs
russell: need clarification about the terms...
igarashi: "rendering application" could be a service
... and service-specific APIs relies on the rendering application
... then 3. service-agnostic API and service-specific document via
the API
russell: in terms of "rendering", I'm not quite sure about
service-specific API means...
igarashi: for example, play-printer()
... on the other hand, XMLHttpRequest is not application/service
specific
... if there is no more comment, I'd go ahead and think about the
following types of APIs
... 1. service-agnostic
... 2. service-specific
... 3. service-agnostic API and service-specific document via the
API
... and my suggestion is that all the use case submitters should
mention those options in their use case proposals
[ adjourend ]
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [7]scribe.perl version 1.136
([8]CVS log)
$Date: 2011/07/05 17:32:05 $
[7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[8] http://dev.w3.org/cvsweb/2002/scribe/
--
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Received on Tuesday, 5 July 2011 18:16:40 UTC