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