Home Networking TF Teleconference

12 Jul 2011


See also: IRC log


Kazuyuki, MattH, Aizu, Tatsuya_Igarashi, david_mays, Jerry_Ezrol, Jean-Claude, Jan


How to handle additional use case descriptions?

kaz: two proposals: 1. API category, 2. concrete system interaction description
... let's talk about "API category"
... could this an optional feature?

igarashi: it would be useful to have this feature when we identify use cases for requirement document

kaz: old use cases are already approved

igarashi: I'd suggest we ask old use case submitters as well to clarify the type

kaz: in that case, we need to clarify the definition of service-agnostic and service-specific

<jcdufourd> ack

kaz: I think service-agnostic is "generic" and service-specific is "application-specific" we discussed before

jc: agree
... but not sure about the third type

igarashi: type3 is combination of type1 and type2
... in addition to generic APIs and application-specific documents (like application-specific XML language)
... e.g., generic XMLHTTPRequest and additional application-specific XML language

<MattH> +q

<MattH> +q

kaz: does type3 include DeviceAPI and HTML5 script?

igarashi: no
... e.g., the URI of the "application-specific" document is one of the parameters of the generic API

MattH: quick question
... do any of existing use cases match this type 3?

igarashi: no idea
... it's that there are theoretically three options

MattH: ok

<MattH> -q

igarashi: however, I think this kind of "type of use cases" should be considered for the discussion in the possible WGs

RESOLUTION: we add Igarashi's proposed "type of use cases" to our use case description (and template)

kaz: next Russell's proposal

-> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Jul/0023.html agenda

kaz: how about discussing th concrete system interaction later?

<igarashi_> I will resume soon.

<rberkoff> what ever is decided should be applied uniformly to use cases or not at all

<rberkoff> then we shouldnt require it!

<rberkoff> no!

RESOLUTION: We should not require detaliked system interaction description for use cases description

MattH: is considering system interaction important in order to express desired attributes of solutions?

berkoff: no. It is desired in order to detect issues with proposed use cases.

Use cases


<trackbot> ISSUE-24 -- Local Link of web applications -- raised

<trackbot> http://www.w3.org/2011/webtv/track/issues/24

-> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/LocalLink#Use_Case:_Local_Link_of_Web_Applications Wiki description

igarashi: have some issue with separating user scenarios
... though Francois suggested I should have separated it
... also he pointed out to clarify the relationship with the other use cases
... issue-24 describes bi-directional communication

kaz: do you think it's impossible?

igarashi: no, but User Scenario is not the main body of the Use Case but just example

<MattH> +q

kaz: maybe we should clarify the definition of "User Scenario"

igarashi: if those User Scenarios are three application-specific examples, I'm happy to separate them
... but there is no significant difference
... there is only one system interaction

ack Matt?

MattH: think we've clarified "User Scenario" and "Use Case"

kaz: we should follow the definition

(kaz will check the definition to make sure.)

RESOLUTION: three examples could be included in ISSUE-24

kaz: next week we'll talk about:
- Russell Berkoff's use case: ISSUE-17 (split into ISSUE-23, ISSUE-26, ISSUE-27, ISSUE-28, ISSUE-29, ISSUE-30)
- Matt Hammond: ISSUE-19, ISSUE-20, ISSUE-21, ISSUE-22

kaz: sorry, but we need to finalize ISSUE-24 as well

kaz: Giuseppe will come back and moderate the call

[ adjourned ]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/07/12 15:05:44 $