Re: Questions about value expansion

> In general, you should have a look at our test suite [1-2] which 
> expresses all of this in a language-indented manner.. if you submit an 
> implementation report, we'll include your conformance level in the 
> official conformance report [3].

I plan to submit the report as soon as I finish the JSON-LD Processor 
conformance, before moving on to RDF.

>>     "native boolean" => ["foo", true,
…snip...
>> DateTime.parse("2011-12-27T10:11:12Z"), {"@value" =>
>> "2011-12-27T10:11:12Z", "@type" => RDF::XSD.dateTime.to_s}],
>>
>> Why does a native date, time and dateTime get expanded to include an
>> @type, but a native integer does not?
>
> Honestly, I have no clue... and it's difficult to figure out what's 
> going on here since you cite this without any context.

Fair enough. It would have presumably been the right amount of context 
for Gregg, but I can see how it would be a lot less meaningful to 
everyone else.

> When converting from or to RDF, types sometimes get added. See
>
> http://www.w3.org/TR/json-ld-api/#data-round-tripping

OK… good to know. I do suspect some of what I'm seeing is code that's 
doing double duty for RDF which I haven't really looked at in the spec 
yet.

> Value expansion is not one of those though :-)

OK. Great to hear as that was at the heart of my confusion. I seem to 
see types getting adding during value expansion in the Ruby 
implementation just based on their being a native type, rather than 
based on the context, and just wanted to make sure I didn't somehow miss 
that in the spec.

>> Similarly, I don't understand this value expansion behavior:
…snip…

> Again, I don't know what's going on here and I don't have the time to 
> dig into that. I would suggest to not try to reverse-engineer one of 
> the existing implementations (that might do more than what's required) 
> but really implement the algorithms as specified and run the official 
> test suite.

>> Thanks for the help! I'm just trying to ensure I do the right thing 
>> with
>> value expansion and I'm confused by these differences in the spec and
>> the Ruby implementation.
>
> Then simply ignore the Ruby implementation :-) The spec is hopefully 
> clear enough.. if not, let us know. Many more people will be able to 
> help you with that than figuring out what a snippet of a specific 
> implementation is doing (especially without context or links to the 
> code).

Fair enough. I'll take that advice.

The approach I'd been taking is to implement to the spec, then compare 
my implementation to the Ruby one, not reverse engineering in any sense, 
but using it to confirm my understanding of the spec. It's been very 
helpful for the "sub algorithms" that need to be implemented before any 
of the official test suite will run (context processing, value 
expansion, iri expansion, etc.). But where I seem to see differences in 
how I understand the spec, my code, and the Ruby code, I'll just hold my 
questions until I get to the point of running the official test suite on 
my code.

Cheers,
Sean