- From: Pierre-Antoine Champin <pchampin@liris.cnrs.fr>
- Date: Thu, 15 Jan 2009 12:03:32 +0000
- To: Felix Sasaki <fsasaki@w3.org>
- CC: public-media-annotation@w3.org
Felix Sasaki a écrit : >> Just a precision: JSON is a subset of javascript, to it is "naturally" >> understood by browsers, that is what makes it so popular. > > You are absolutly right, my bad. Sorry for writing without thinking. It happens even to the best ones :) >> Now, it seems to me that the discussion is becoming: should we have a >> fine grain API returning only simple types (e.g. getDateGeneral vs. >> getPubDate), or a coarser grain API returning more complex data (as >> proposed by Joachim). >> >> An alterenative method would be to have an optional flags in each method >> to explicitly require structure data / specific data. E.g. >> >> getDate() >> -> "2008-01-13" // creationDate by default >> getDate(QUALIFIERS) >> -> [ "2008-01-13", "creationDate" ] >> getDate(QUALIFIERS|MULTIPLE)t >> -> [["2008-01-13","creationDate"],["2008-01-14", "publishDate"] ] >> getDate("publishDate") >> -> "2008-01-14" >> >> This is just an example, the actual parameters / result could be >> different, of course. That being said, does that example make sense ? >> > > Makes all sense. To implement this I would replace > "property=dateGeneral" in > > inputURI=http%3A%2F%2Fgdata.youtube.com%2Ffeeds%2Fbase%2Fvideos%2F-%2FExperte%3Fclient%3Dytapi-youtube-browse%26v%3D2&property=dateGeneral > > > with one of the function calls you describe above. From an > implementation point of view the above and the function call are the > same effort. What is more convinient from a users point of view, or for > specific use cases? I was more thinking in a "programming language" style, than in a "HTTP" style... If I was to translate my ideas to "HTTP" style, I would say that I would replace property=dateGeneral / property=pubDate with property=date / property=date&subproperty=pubDate where * the legal values for "property" would be properties from our ontology * the legal values for "subproperty" would be open for extensibility, (while retaining the core semantics of the "property" used) (of course, the REC could define/recommand a set of core subproperties, especially for interoperability with existing standards) More systematically, I would propose the following equivalences getDate() <=> (some_url)...&property=date -> "2008-01-13" // creationDate by default getDate(QUALIFIERS) <=> (some_url)...&property=date&structured=yes -> [ "2008-01-13", "creationDate" ] getDate(QUALIFIERS|MULTIPLE) <=> (some_url)...&property=date&structured=yes&subproperty=ALL -> [["2008-01-13","creationDate"],["2008-01-14", "publishDate"] ] getDate("publishDate") <=> (some_url)...&property=date&subproperty=publishDate -> "2008-01-14" Open question: with such an API, should (some_url)...&property=publishDate be accepted as a shortcut to (some_url)...&property=date&subproperty=publishDate (this would require the service to recognize that publishDate is a subproperty of "date", so this would only be possible -- or at least practical -- for standard subproperties) pa
Received on Thursday, 15 January 2009 12:04:15 UTC