See also: IRC log
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
kaz: I think service-agnostic is "generic" and service-specific is "application-specific" we discussed before
... 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
kaz: does type3 include DeviceAPI and HTML5 script?
... 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
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
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!
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.
<trackbot> ISSUE-24 -- Local Link of web applications -- raised
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
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
... but there is no significant difference
... there is only one system interaction
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 ]