See also: IRC log
issue-17?
<trackbot> ISSUE-17 -- Use Case: Home Network Enabled User-Agent -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/17
kaz: let's close this
everyone: ok
close issue-17
<trackbot> ISSUE-17 Use Case: Home Network Enabled User-Agent closed
issue-24?
<trackbot> ISSUE-24 -- Local Link of web applications -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/24
-> http://lists.w3.org/Archives/Public/public-web-and-tv/2011Jul/0046.html Igarashi's update
igarashi: added description on
API types
... issue-24 itself is a generic API
-> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/LocalLink#Use_Case:_Local_Link_of_Web_Applications Wiki description of ISSUE-24
kaz: is the wiki description also updated?
igarashi: yes
kaz: do you want to include the information on ISSUE-9 and Opera's API proposal in the wiki description as well?
igarashi: no, it's just additional explanation on what "generic API" means
kaz: any opinion?
... if no objection, let's accept this proposal ISSUE-24
RESOLUTION: accept ISSUE-24
matt: would like to start with 20
issue-20?
<trackbot> ISSUE-20 -- TV Querying and Control -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/20
-> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/TVControl Wiki description of ISSUE-20
matt: restructured the
issue
... possible interaction scenario is included
... JavaScript level API proposal for discussion as well
matt: (describes the detail of the proposal)
jerry: trying to understand
... target of the application which execute the API
... how to know where to execute APIs?
... home network devices could have a gateway
... server needs to know where to get the content from
matt: the intention is
implementing APIs as JavaScript and use from Web browsers
... what content is available where is an issue
... suppose DLNA terminology, media rendering device?
jerry: I think what you're saying is a TV device
matt: could be a TV device
... or a desktop browser
jerry: target of the API is a
processing engine that has capability
... being discovered by the browser
... and capable of executing the APIs
... and that can describe what devices are/
igarashi: in this scenario,
application is rather a device
... but application is running on devices
matt: will update the text
igarashi: this service-specific API is supported by the TV as well?
matt: the API could be supported by TV if it can process JavaScript
clarke: your suggestion is higher
level API
... list of functions
... right?
matt: yes
igarashi: in scenario 1, there
are several options
... maybe you should not use sequence number, but should use
non-ordered list
... the first step "The application discovers..." should be
done first, though
matt: will change
bob: a question
... level of APIs
... high-level APIs is useful
... but what level of APIs should be used?
matt: there is ability for application
bob: we started a high-level APIs
within AT&T, and would like to know how to cover the other
implementations
... need more sophisticated kind of APIs?
matt: if you have information to share with me, would be appreciated
bob: agree the trade-off
... but how much task is expected for a User Agent?
... clarke's paper will be soon available
clarke: if we do something Bob
suggested, i.e., lower-level APIs implementable
... any preference from W3C viewpoint?
kaz: both levels would be welcome
and useful
... our proposals should go to the other WGs, e.g., DeviceAPIs
and WebApps
... if they don't work very well for our proposals, we should
create yet another WG :)
<scribe> ACTION: matt to update issue-20 [recorded in http://www.w3.org/2011/07/26-webtv-minutes.html#action02]
<trackbot> Created ACTION-56 - Update issue-20 [on Matt Hammond - due 2011-08-02].
igarashi: comment on scenario
2
... specific program?
matt: question on step 2?
igarashi: yes
matt: list of content available
could be provided
... and we could ask the TV which program is available now
igarashi: ok
kaz: igarashi, do you want clarification in scenario 2?
igarashi: "application query" would be easier to understand?
matt: will use the term
issue-19?
<trackbot> ISSUE-19 -- Media Identification -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/19
-> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/MediaIdentification Wiki description of ISSUE-19
matt: content identifier
... hopefully more clear
... related to part of issue-20
kaz: do you think a specific URI could be used?
matt: a URI is a
possibility
... BBC would like to include URI style identifier
... some provider might use different kind of identifier on
some platform
kaz: can we accept this proposal?
everybody: no objections
RESOLUTION: ISSUE-19 is accepted
issue-21?
<trackbot> ISSUE-21 -- Time synchronisation -- raised
<trackbot> http://www.w3.org/2011/webtv/track/issues/21
<MattH> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/TimeSynchronisation Wiki description of ISSUE-21
matt: have no time to update
this...
... (explains the proposal)
... similar to issue-19, any high-level APIs could be supported
rather than application-specific APIs
kaz: you'll update the description, and we should talk about this next week?
matt: yes
kaz: no more proposals for today?
matt: no
kaz: any other topics?
everybody: no
kaz: ok. let's adjourn this call
and talk with you all next week
... Giuseppe will be also available next week
[ adjourned ]