Re: data interchange format

Thanks for the proposals, Pierre-Antoine. I am not sure if the question 
from Joakim and also the discussion at this weeks call was about "how to 
design the API", or rather "what to do if we have similar values with 
different granularities?". Of course these are interrelated, but the 
answer to the second question has a value on itself I think and is maybe 
primary - but I may be wrong.

There is a discussion on distinction between different types of time 
values and its need for atom at
http://www.imc.org/atom-syntax/mail-archive/threads.html#20848

see e.g.
http://www.imc.org/atom-syntax/mail-archive/msg20870.html
"I bet if you asked, most users couldn't even tell you if they were 
ordering by published date or updated date. They just know that how 
they're doing it is correct; and vitally important. Right up until the 
time that it's inconvenient to have things sorted that way; and then 
it's the date that is wrong, not the ordering. "
By pointing to this mail I don't want to say that this difference is 
always unimportant, but in some cases it is.

Felix

Pierre-Antoine Champin さんは書きました:
> 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 13:16:36 UTC