See also: IRC log
<trackbot> Date: 05 July 2011
kaz: there are two types: generic
use cases and application specific ones
... Igarashi-san, could you please talk about your idea?
... 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
... 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
... but if there is issue on interoperability, we need to address that concern
igarashi: yes, that's very
... 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?
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
... 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,
... 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 ]