W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2011

Re: DAP rechartering discussion

From: Robin Berjon <robin@berjon.com>
Date: Mon, 21 Mar 2011 15:02:48 +0100
Cc: Matt Hammond <matt.hammond@rd.bbc.co.uk>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>, Olivier Thereaux <olivier.thereaux@bbc.co.uk>
Message-Id: <ED4A9EED-3704-42AB-B5D0-B3F84FD7CB5F@berjon.com>
To: Mark Watson <watsonm@netflix.com>
On Mar 16, 2011, at 05:32 , Mark Watson wrote:
> My main comment is that I would not expect standardization to reach so high in the stack. Or at least we should decouple the discovery, connectivity and security aspects (which are generically useful) from aspects such as content search and metadata, which IMO are service-specific (or source-specific in your terminology).

One thing that I like a lot about the way in which UC is currently specified is that one can easily split various bits off. There could be a UC Core specification with everything that's absolutely required, and then the other parts could be independent components. Since they're already optional and have a discovery mechanism, it should be relatively easy.

In my experience from writing EPG apps though, I have to say that having some baseline search and metadata interoperability would be very, very nice. This doesn't have to be all-powerful (that's too hard a problem to solve) but at least some minimally common parts (navigating categories, simple full text search) helps a lot.

> For example, I would find it very difficult to see how a service such as Netflix's could fit into the model you've defined: we have our own metadata, including categories, and would expect to have our own User Interface on both the TV and the remote: they need to discover each other and communicate but after that their communication probably needs to be proprietary, since standards cannot anticipate the ways we will want to innovate with respect to the Remote<->TV interaction and their respective user interfaces (and nor can I).

Not standardising everything and boiling the ocean is definitely a feature. One question to you here though: there's a difference between proprietary and closed. With UC as currently specified, you could add your own extension service on the server, and clients could use it. It would be proprietary, but not closed (third party developers could address it). Would third parties enhancing your service (e.g. writing clients that they think is better than the stock one you could ship) be seen as a problem from your end?

-- 
Robin Berjon - http://berjon.com/
Received on Monday, 21 March 2011 14:04:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:18 GMT