RE: Categolize what APIs should be stardized

Hi Francois,

My comments are interleaved below;

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: Friday, July 01, 2011 9:27 PM
> To: Igarashi, Tatsuya
> Cc: public-web-and-tv@w3.org
> Subject: Re: Categolize what APIs should be stardized
> 
> Hi Tatsuya,
> 
> Thanks for clarifying your points. See comments inline as well as
> comments/questions/proposal on ISSUE-24.
> 
> 
> On 06/28/2011 05:55 PM, Igarashi, Tatsuya wrote:
> > Hi Home Network TF participants,
> > I would summarize my point which I tried to comment in the today's
> teleconference.
> > I believe that the most proposed user scenarios are meaningful and valid
> from user perspective. In the sense, I do not have any objection to accept
> all proposed user scenarios at this time. But, at the next step, if we have
> to prioritize the user scenarios, we should be care of what type of APIs
> should be standardized to realize the proposed user scenario.
> 
> Right, I guess that what I'd like to see is a representative list of use
> cases, so that discussions on priorities can start (best done once use cases
> are listed in one place). If use cases sound valid, we should accept it.
> Stepping into discussions about what the APIs should look like to implement
> a particular use case sounds out of scope of the IG.
> 
> 
> > If the APIs are application(service) agnostic, e.g. generic discovery
> APIs and generic message exchange API, then the proposed user scenarios
> would be outstanding examples and we do not need to argue priority of each
> user scenarios so much. Hopefully, more attractive user scenarios will be
> realized based on the W3C standard.
> > If the APIs are application(service) specific, e.g, Remote TV channel
> change APIs, then the prioritization of user scenarios is very crucial and
> we have to argue if it is important for the stakeholders to standardize
> such application specific APIs in W3C.
> > To avoid a confusion on the priority discussion, I suggest that the
> submitters of the user scenarios will add the description about what type
> of API's should be scandalized. e.g. generic local network discovery and
> message exchange APIs.
> 
> I'm not sure what it means to add what type of API should be standardized.
> It is very possible that a little bit of both will be required and most
> use cases can be implemented in one of two ways:
>   - through service agnostic APIs
>   - through application specific APIs for specific common purpose
> functionality such as the remote TV channel change APIs you mention (I'm
> not saying it "should", I'm saying it "could").

I thinks of the two points.

(1) Input about what's type of API should be standardized is useful for us as justification.
The use case template describes the suggestion, too.

http://www.w3.org/2011/webtv/wiki/HNTF/Use_Cases_Template


Need/justification: 

Explanation of benefit to ecosystem 
Why were you not able to use only existing standards to accomplish this? 
What might you suggest could be standardized?

(2) I agree that the most proposed user scenario can be important in one of two ways.
So, the input what what's type of API should be standardized is important to understand the intent of submitters. Without this discussion, we cannot decide that W3C standardize it, who are the stakeholder, and which WG should handle it, I think.
> 
> Said differently, the person who submits a use case may precise what level
> he has in mind, but that may not be the solution that will be standardized
> in the end.

In my understanding, the discussions about what type of APIs or what type of network protocol are required are the requirements for the solution. The IG should discuss such requirements.
> 
> A use case that demonstrates that many more scenarios can be constructed
> on the same model with all sorts of messages being exchanged is certainly
> a valid way to make service agnostic APIs a requirement. I believe that's
> what approved ISSUE-14 conveys:
> 
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Dis

> coveringAService
> 

The difference from the ISSUE-14 is that the ISSUE-24 is intended to enable communications between applications running on the user-agents and the communication is bi-directional (not client-server-mode). Any requirements for the existing service specific protocols, e.g. UPnP Media Renderer device and the services, are not derived from the ISSUE-24. If the ISSUE-14 are the same idea as the ISSUE-24, the two use cases should be merged. Anyway, we need furthermore clarifications on both ISSUE-14 and ISSUE-24. This applies to the others proposals. It is the reason why I suggest to input what type of APIs are necessary. If the only ISSUE-14 and ISSUE24 are intended to standardize the service agnostic APIs, it is very good for us to speed-up the requirements on the use cases.


> Speaking of which, I'm looking again at the actual use case (System
> Interactions) described by ISSUE-24:
> [[
> - An User-Agent discover other Users agent on the same IP-sub network
> - Via API, the User-Agent provides the discovered application list which
> contains the applications which are running on other user-agent, e.g.
> application id, the URL for message exchange, physical device name(for user
> selection) (Comment: In this use case, only the application specified by
> application id should be discovered via the API because of the privacy
> concern --Tatsuya Igarashi 11:55, 14 June 2011 (UTC)
> - The application establishes the bi-directional communication for message
> exchanges with the application on the other user-agent via API
> ]]
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Loc

> alLink
> 
> It seems covered almost word by word by ISSUE-14 "Application Discovering
> a Service":
> [[
> An application discovers a service. Discovery means that after discovery,
> the application has:
> - an identification of a device (maybe) and a service;
> - a means to know the messages that can be exchanged, possibly with their
> parameters;
> - a means to send messages to the service, if the service may receive
> messages;
> - a means to receive messages from the service, if the service may send
> messages.
> ]]
> 
> Your comment on privacy is one of the points highlighted in the security
> issues document (ISSUE-3):
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Sec

> urity#Device_Information_only_visible_to_the_user
> 
> Could you clarify what the use case in ISSUE-24 covers that ISSUE-14 does
> not?

I have described the differences above. Among the use cases related to the service-agnostic, more clarifications on the system interactions would help us to derive the requirements on APIs. As the result, if we agree on enabling the communication between applications running on the user-agent, we may derive the requirements on the underlying protocol, e.g. user-agent preferable network protocols.   If we agree on the requirements on the necessity of bi-directional communication, i.e. both applications can initiate requests, which is not different from the SOAP, the requirements of the API should be as like to support bi-directional communications.

> 
> About user scenarios, I suggested that they get split up in separate use
> cases during last call. Thinking more carefully about it, I think it's a
> mistake, actually ;) You're right that they illustrate the same use case
> and would not need to be discussed separately when setting priorities.

OK, I will split up into the separate user scenarios.
> 
> If you agree that ISSUE-24 is covered by ISSUE-14, I would suggest that:
>   - the use case it describes gets dropped as a distinct use case (same
> use case as ISSUE-14)
>   - user scenarios listed there get used as "user stories" for ISSUE-14
> in the use cases and requirements document. I believe such scenarios are
> pretty useful to convey the intent and benefits of the use case. ISSUE-14
> is a bit dry for the time being.
> 
> What do you think?

I explained my idea about the ISSUE-24 and ISSUE-14. I am very happy to discuss to merge not only ISSUE-14 and ISSUE15, but also the other ISSUES which are intended to standardize the service-agnostic APIs. To proceed this, would you lead the use case categorization by on what types of APIs should be standardized, i.e. service agnostic API v.s. application specific APIs?

Thank you.

-***---***---***---***---***---***---***---***---***--***---***---***-
Tatsuya Igarashi (Tatsuya.Igarashi@jp.sony.com)
NS Development Dept. Technology Development Group 
Sony Corporation
(Voice) +81-3-5435-3252 (Fax) +81-3-5435-3274


> 
> 
> Thanks,
> Francois - for ACTION-42.

Received on Tuesday, 5 July 2011 02:25:59 UTC