W3C home > Mailing lists > Public > public-web-and-tv@w3.org > July 2011

Re: ISSUE-24 - Application IDs

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 05 Jul 2011 17:23:31 +0900
Message-ID: <4E12CA03.8050503@w3.org>
To: public-web-and-tv@w3.org
Hi Russell,

(sorry my jumping in...)

I think we should (and should be able to) talk about details on how
to implement our use cases at later stages.

However, I agree it is useful for us to consider example implementation
method from time to time and refine our use cases description based on
the feedback from that viewpoint.

So I'd like you to re-formalize your point as an issue on how to refine
use cases description based on actual implementation examples.  Maybe
we could add some note to ISSUE-24 (or whatever) mentioning, e.g.:
- who to register the IDs?  also how to handle the IDs?
- application specific APIs and interoerability?

What do you think?

Thanks,

kazuyuki


On 07/05/2011 03:24 PM, Russell Berkoff wrote:
> Hello Igarashi-san,
> I think I have an issue with application-ids and private application interfaces as implied in ISSUE-24 and your clarifications.
> 1. Who is the registrar for these applications IDs? Even if the ID is (automatically) derived from a MD-5 fingerprint of the interface description, the semantics may differ between device implementation even if the method and parameter types for the interface are identical.
> 2. How are application specific (private) interfaces helpful to general interoperability. Sure I can write proprietary Sony Device and have Sony specific applications to communicate with it? Is that approach generally helpful?
> UPnP has taken the approach of defining applications APIs that are expected to be supported across vendors with clearly stated semantics and syntax. It doesn't sound that ISSUE-24 is following that model and that design choice seems problematic.
> Regards,
> Russell Berkoff
> Samsung

-- 
Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Received on Tuesday, 5 July 2011 08:22:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:06 UTC