Re: Proposal for structure of Caps, Hints, and Stats

As a structure this matches exactly what I had in mind as well.  We may not need a Capabilities registry, of course, for the reasons described in my proposal and the emails I just sent, but we will definitely need such registries for Hints and Statistics.

-- dan

On Jan 23, 2012, at 11:30 AM, Cullen Jennings wrote:

> 
> Ignoring the actually semantic content of these APIs, I'd like to make a proposal for how to structure sending the information. It really a simple proposal. The idea would be each of the API took a returned a dictionary. The keys for the dictionary would be well known strings such as "supportsVideo". Some specification would need to define each key, it's type, and what it means. There would be an IANA registry for each of Caps, Hints, and Stats that had a table with each of the and a pointer to the document that defined the key. There would be an IANA registry separately and the registration process would be "specification required" meaning that W3C, IETF, or even an organization like Mozilla could add an entry as long as there was a web page somewhere that explained what the new key meant. 
> 
> So for example, if the API specification this WG is producing defines "supportsVideo", the IANA registry would list this key in the Caps table and beside it would be a pointer to the specification with WG produced. The specification would indicate that the type would be a boolean and explain if it meant you send video, or receive it, or whatever it means. If Google invented a holographic projections systems and described it in a document posted somewhere on the web, then the IANA registry would add the new tag of "supportsHolographicProjection" with a pointer to the Google web page. The point of the registry is to avoid conflicting names and provide a pointer where an implementer can find out what a given tag means. It won't limit innovation. Given it is a dictionary, it can return arbitrarily complex object for the key so it seems like it should have enough future flexibility. 
> 
>

Received on Tuesday, 24 January 2012 14:07:19 UTC