Re: data interchange format

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