[twitter-dev] Re: Annotations with data types
+1 I think you make a good point. It's no extra effort to append the data type to the name. If annotations is to become a wild west then assuming everything is a string unless proven otherwise is a little rediculas. It might be better to take it one step further since above you usefloat when really you mean latitude expressed as float. Likewise 0xff is an int but realy I mean color so a heiracrchy of types would make more sense? i.e. seconds since 2000 - long - 318391231231 Ian http://www.twiper.com
Re: [twitter-dev] Re: Annotations with data types
On Sun, Jun 6, 2010 at 12:36 AM, Mark Plotnick mark.plotn...@gmail.comwrote: I'm not sure we ought to devote bytes in the rather limited length annotations for data type names. Maybe have an optional (URL to a) schema that describes what the restrictions are. If the schema specified in the annotation is enforced by Twitter, yeah, that would be a great idea too. Though, for Twitter, there's the added complexity/bandwidth of fetching a schema for every tweet, since I think the number of schemas would be so huge that you can't just cache them all easily. But I am more concerned that nobody's seeing/acknowledging the magnitude of the problem. Even if the currently mentioned solutions are not ideal, including mine, I think something needs to be done to search for a solution. Or perhaps I am just over-reacting. -- Harshad RJ http://hrj.wikidot.com
Re: [twitter-dev] Re: Annotations with data types
Never mind, I misinterpreted what the problem being solved was I'm not sure we ought to devote bytes in the rather limited length annotations for data type names. Maybe have an optional (URL to a) schema that describes what the restrictions are.
Re: [twitter-dev] Re: Annotations with data types
On Sun, Jun 6, 2010 at 12:23 AM, Mark Plotnick mark.plotn...@gmail.comwrote: If you use JSON, the types should be visible after you unmarshall the data. Visible, yes. Checked, no. Every client would have to check the type before using the value. -- Harshad RJ http://hrj.wikidot.com
Re: [twitter-dev] Re: Annotations with data types
-1
Since the underscore is an acceptable char to variable/attribute
names, you would surely end up with unwanted type coercions... if a
developer chose _int for the last part of the attribute, it would
force coercion to integer... which you cannot be sure it's what he/she
wanted in the first place.
If this is really an issue (I'm still unconvinced it is), you need to
find another way of *explicitly* doing this.
For example:
location : {
latitude: { type: 'xsd:float', value: '45.4' },
longitude: 45
}
in this case it would specify:
lat: 45.4 (float)
long: 45 (int)
(since longitude opts for an implicit type specification)
--
André Luís
http://id.andr3.net/
On 4 June 2010 05:27, Harshad RJ harshad...@gmail.com wrote:
On Fri, Jun 4, 2010 at 9:41 AM, Harshad RJ harshad...@gmail.com wrote:
Suggestions for data-types:
int : Integer
float : Floating point number
url : A well formed URL
To add to this list of data-types:
str: To force to a string
Say, you have an attribute whose label ends with _int. So to force it to a
string you could append _str.
For example:
xyz_int_str : Some string
--
Harshad RJ
http://hrj.wikidot.com
Re: [twitter-dev] Re: Annotations with data types
Hi Andre,
I understand your concern. I was trying to propose one possible way of doing
things. I welcome other suggestions as well, but each will have its own
merits / demerits.
We first need to see if the concept of a data-type is really a concern. I
think it is a nice-to-have feature, as it will save repetitive checks across
the tens of thousands of twitter clients and their millions of instances.
To draw an analogy, imagine if the status_id in a tweet was not guaranteed
to be an integer. Every client would have to do a lot of boring /
inefficient checks for such a simple thing.
Now take that problem and blow it up a thousand fold with all sorts of
annotations being made across possibly co-operating but definitely
un-coordinated clients.
I personally don't prefer the suffixed label approach all that much. A
three-tuple or a hierarchial-tuple system like you suggested would be
better. But the suffixed label approach is the least disruptive to what has
already been defined.
cheers,
Harshad
2010/6/4 André Luís andreluis...@gmail.com
-1
Since the underscore is an acceptable char to variable/attribute
names, you would surely end up with unwanted type coercions... if a
developer chose _int for the last part of the attribute, it would
force coercion to integer... which you cannot be sure it's what he/she
wanted in the first place.
If this is really an issue (I'm still unconvinced it is), you need to
find another way of *explicitly* doing this.
For example:
location : {
latitude: { type: 'xsd:float', value: '45.4' },
longitude: 45
}
in this case it would specify:
lat: 45.4 (float)
long: 45 (int)
(since longitude opts for an implicit type specification)
[twitter-dev] Re: Annotations with data types
On Fri, Jun 4, 2010 at 9:41 AM, Harshad RJ harshad...@gmail.com wrote: Suggestions for data-types: int : Integer float : Floating point number url : A well formed URL To add to this list of data-types: str: To force to a string Say, you have an attribute whose label ends with _int. So to force it to a string you could append _str. For example: xyz_int_str : Some string -- Harshad RJ http://hrj.wikidot.com
