[HOME_NETWORK_TF] Minutes - 5 July 2011, 14:00Z

available at:

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:




       [1] http://www.w3.org/

                                - DRAFT -

        Home Networking Task Force Teleconference -- 05 Jul 2011

05 Jul 2011


       [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


           Kazuyuki, Clarke_Stevens, Nilo_Mitra, Vicki, aizu,
           DongHyun_Kang, Tatsuya_Igarashi, Russell, Richard_Bardini





      * [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
    ... 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

    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

    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

    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
    ... 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
    ... 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