W3C home > Mailing lists > Public > public-rdf-ruby@w3.org > February 2008

Re: APIdeas

From: Keith Alexander <k.j.w.alexander@gmail.com>
Date: Thu, 21 Feb 2008 14:52:17 -0000
To: cdr <_@whats-your.name>, public-rdf-ruby@w3.org
Message-ID: <op.t6vp9fxwzdej1c@polar-bear>

On Thu, 21 Feb 2008 00:05:01 -0000, cdr <_@whats-your.name> wrote:

> {"type": "literal", "value": "3", "datatype": "integer"} is
> 3
> the main poin is always use JSON for intrinsic values like 5, even if  
> youre describing '5 yards',
> most parsers are written in Parsec, Ragel, Yacc, theyre benefit from  
> fast value (string, integer, float) in generated C or ASM while yours  
> requires manual casting later on inside slowscriptspace. a typical form  
> index could end up calling Integer() 300 times in Javascript on the  
> client, and to_string 300 times in the server for no reason other than  
> your format ignores this native feature of JSON..
> i got about a 25x speedup by getting rid of any sort of manual casting,  
> and using the ragel generated json parser in ruby. and im not even  
> selling a 'platform' i just got sick of the unnecesssary latency..


I do find your structure interesting Carmen, but so far, I still find the  
predicatability of the rdf/json structure to be more advantageous - in  
that I know that the value of a predicate key will always be an array of  
object hashes, and I can always get the value and the type under the value  
and type keys, rather than testing if something is an object or a string  
or an integer or is an object with a certain property. The speed thing  
seems to depend on use-case though? - ie, whether you are doing stuff with  
numbers, or simply printing them out.

It might be worth considering mandating in the rdf/json spec that xsd  
datatypes are output as native json datatypes rather than quoted strings -  
I'm not sure though. A potential problem with doing the same thing for  
xsd:integers and xsd:float into json numbers is that you might suffer loss  
of precision - different languages implement these concepts differently,  
so you might not be able to roundtrip your data. eg: if the json says  
3.000 rather than "3.000", upon 'evaling', it will become 3.0 in ruby (and  
just 3 in js).  So maybe it is better and more consistent not to try to  
port the semantics of XSD to the semantics of JSON and/or ruby.

Anyway, sorry if I came across as trying to 'sell a platform', I really  
didn't mean to; I just (personally) see a lot of value in converging on a  
common data structure where possible.


Received on Thursday, 21 February 2008 14:52:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:13 UTC