RE: Categolize what APIs should be stardized

Hi all,

According to the mail discussion below, maybe some actual implementation discussion is already begun.
To discuss that level is really very good progress, however, I would like to suggest to focus on use case at TF stage.
After we decide which use case will be standardized first, the detail design will follow with the balance of other use cases.

I just commented generally to trigger the discussion on the detail level we should have until July deadline for HN-TF.

Best regards,
HJ

-----Original Message-----
From: 
Sent: 없음
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").

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.

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/DiscoveringAService


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/LocalLink

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/Security#Device_Information_only_visible_to_the_user

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


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.

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?


Thanks,
Francois - for ACTION-42.

Received on Monday, 4 July 2011 10:37:42 UTC