- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 13 May 2013 17:00:03 -0300
- To: "'Sandro Hawke'" <sandro@w3.org>
- Cc: "'W3C RDF WG'" <public-rdf-wg@w3.org>
On Monday, May 13, 2013 4:49 PM, Sandro Hawke wrote: > Sorry, the flag doesn't really help in the scenario I provided above, > where someone is serving JSON-LD to an unknown client. I would argue > this is the expected, majority use case. (I guess the other one that I see, you are concerned about systems exchanging JSON-LD. Then the situation is exactly the same as with exchanging JSON. Not sure we should/can change that. > might be common is reading RDF and converting it to JSON-LD for > internal > use as a kind API to the data?) And in this use case, if the server > sets useNativeTypes=true, it's going to be providing data that for some > data values the client will get either the wrong RDF data value and/or > the wrong RDF data type. > > In other words with useNativeTypes turned on, JSON-LD is not a faithful > RDF syntax. JSON-LD the data format is.. the problem are the (JSON) parsers. > Given that -- which you all seem invested in -- maybe we should go all > the way and convert all RDF numeric literals to native JSON numbers. > It > makes the lossy-but-convenient conversion even more convenient and > lossy > in a less-surprising way. Rather than weirdly having *some* doubles > turned into integers in the rdf->json->rdf round trip, we'd just have > (I > propose) EVERY numeric literal turned into an xs:double. Certainly > that's what pretty much every JavaScript coder would want/expect with > useNativeTypes=true. > > I'd also suggest we say the people SHOULD NOT publish JSON-LD with > json-native numbers in it, unless they're fine with them being > understood in a platform-dependent way. I would be fine with doing that. As you say, in most cases that's what people want anyway. I hope we can still get this changes in before publishing LC2. -- Markus Lanthaler @markuslanthaler
Received on Monday, 13 May 2013 20:00:35 UTC