RE: Use Cases & Underlying Technology



> -----Original Message-----
> From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-
> request@w3.org] On Behalf Of Giuseppe Pascale
> Sent: Wednesday, May 04, 2011 2:24 AM
> To: Russell Berkoff; public-web-and-tv@w3.org; Clarke Stevens
> Subject: Re: Use Cases & Underlying Technology
> 
> Clarke, Russell,
> separating (technology neutral) use cases and implementation is just a
> matter of good design in my opinion.

Agreed

> 
> Use cases are important/not important regardless if they can be
> implemented using existing technologies.
> Saying "this use case is not important because it cannot be implemented
> using UPnP" doesn't sound right to me.

I think it's more a question of focus than importance. The initial use cases and requirements centered on exposing existing HN protocols to Web content. A use case that requires some new HN protocol may be important but doesn't seem to be the focus of the initial problem statement.
 
> 
> This doesn't mean that the discussion on existing technology is not
> important, it only means that these needs to be separate discussions.

I think it is a good idea to not lose use cases that require new technology and I agree with partitioning the discussions. I think the TF should first address how we expose existing HN protocols.

> 
> I would also remind you that this TF deliverables are a requirement
> document and some (optional and informative) implementation notes.
> 
> The steps we should follow in my view are:
> 
> - define use cases
> - extract requirements
> - point out existing technologies that could cover these requirements
> (if
> any)
> - deliver these notes to one or more WGs

Again, I think the question to be addressed is how can existing HN protocols be exposed to Web content. This may require new technologies. It seems out of current scope to be concerned about defining new HN technologies.

Bob Lund
> 
> Ideally we should proceed in this order. Given the short deadline I
> would agree on having this discussions in parallel, but not on mixing
> everything.
> That's why I proposed to remove any implementation detail from use cases
> and focus on the use cases it self.
> (see how I applied the use cases to the requirement document [1])
> 
> 
> So in short, my opinion is that the current set of deliverables and
> their structure, that is:
> - requirement document
> -- use cases (technology neutral if not otherwise required by the use
> case)
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements#Use_

> cases
> -- design goals (Note that UPnP is mentioned here)
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements#Desi

> gn_Goals
> 
> -  Implementation notes (from Clarke)
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Discussions/Alter

> natives
> 
> 
> already address your concerns and I don't think we need to reopen the
> approved issues (ISSUE-5 and ISSUE-10) Of course, goes without saying
> that we can improve the text of each document.
> 
> 
> If you disagree on this proposed "solution" please point out specific
> changes you would like to see in each document.
> 
> Thanks,
> /g
> 
> [1]
> http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements#Use_

> cases
> 
> On Tue, 03 May 2011 19:07:07 +0200, Clarke Stevens
> <C.Stevens@cablelabs.com> wrote:
> 
> > I agree. I think one of the main objectives of this effort (and the
> > interest of the cable TV industry) is to leverage networked consumer
> > electronics devices that are already in the market.
> >
> > In my view, the implementation discussions are about what interface we
> > use to communicate with those technologies. So far, I've heard two
> > primary approaches: (1) provide a generic basic interface that has a
> > string parameter with a SOAP or REST type command or (2) develop an
> > interface with some higher-level abstraction (e.g. Select Content,
> > Play, Pause, etc.) that would map to existing implementations (like
> > UPnP or mDNS/DNS-SD). Both of these approaches would work with
> > existing standards in widely deployed products.
> >
> > We could consider "next new thing" ideas, but I think to the extent
> > that they don't leverage existing home networking architectures, their
> > interest should be secondary. This isn't particularly limiting as the
> > existing architectures have a very extensive feature set.
> >
> > Thanks,
> > -Clarke
> >
> > From: public-web-and-tv-request@w3.org
> > [mailto:public-web-and-tv-request@w3.org] On Behalf Of Russell Berkoff
> > Sent: Tuesday, May 03, 2011 10:23 AM
> > To: public-web-and-tv@w3.org
> > Subject: Use Cases & Underlying Technology
> >
> > Hello,
> >
> > On the last HNTF call I believe that it was mentioned that use-cases
> > and the corresponding  implementing technologies should be separate.
> > I'd have substantial reservations over submitted Use Cases which do
> > not appropriately utilize or require extensions to existing HN
> technologies.
> >
> > I would suggest than any approved use-cases on the last call be review
> > for the concern above.
> >
> > While I don't want preclude the "next-new-thing" I think it should be
> > incumbent on use-case submitters to either comply with existing
> > available technologies or fully describe any new (or extension of
> > existing) technologies within the submitted use-case.
> >
> > Regards,
> > Russell Berkoff
> > Samsung
> >
> 
> 
> --
> Giuseppe Pascale
> TV & Connected Devices
> Opera Software - Sweden

Received on Wednesday, 4 May 2011 14:47:08 UTC