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.


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)

Reply via email to