Test updates for duplicates and differences with extendedYAML interpretation

[gkellogg]

• Set extendedYAML: false option on cir-scalar-i18n-1 and cir-scalar-other-1 tests as results differ.
• Mark tests requiring extended YAML-LD as "may" (cir-scalar-other-* and cir-scalar-i18n).
• Remove duplicate test entries.

Note that if extendedYAML is used, the first two tests yield different results. cir-scalar-other-2 has test results consistent with extendedYAML, so "reg" is changed to "may" and the extendedYAML option is added back.

[gkellogg]

If we keep cir-scalar-other-2 with the extendedYAML flag, we should probably add back versions of -1 and i18n-1 with that flag set and appropriate results. And add a version of -2 with results consistent with not using the flag.

[anatoly-scherbakov]

How do we treat this in the spec? The normative section of the spec doesn't define extendedYAML flag as far as I can recall; that flag is only described in the supplementary section.

[gkellogg]

It’s defined in the test readme. The spec has an informative section on extended YAML- LD; this was why it was previously split out into a separate manifest. Easiest might just be to remove the test and not use the option anywhere.

[gkellogg]

Or, as I suggested elsewhere, fix the expected result to be consistent with normal evaluation. The problem, IIRC, was with the output for decimal, which would be processed as a double normally.

[anatoly-scherbakov]

In my implementation, I had to force my YAML library (which is pyyaml) to NOT interpret floats as floats. I have to read them as strings. Otherwise, they get corrupted in str → float & float → str conversions. I do the same with dates and other types. I am not certain whether this is a good way to do this; but I see no other. JSON-LD spec doesn't specify how JSON-LD processor should work on a data structure that includes Python datetime or float objects, I believe.

[gkellogg]

JSON-LD has no native support for datetime, but numbers will be interpreted either as int or double. In this case, 123.455 would be interpreted as a double once going to RDF. In the Internal Representation, it’s like a JavaScript number, but in python, probably either an integer or a float.

[anatoly-scherbakov]

That's the problem: float numbers in scientific notation in tests get corrupted during parsing and subsequent serialization. I haven't found a better way other than interpret them as strings :/

[gkellogg]

That's the problem: float numbers in scientific notation in tests get corrupted during parsing and subsequent serialization. I haven't found a better way other than interpret them as strings :/

I'm not sure how they are "corrupted" for you. A native YAML parser would parse them into a numeric value, probably float. This should be the same as if a JSON number were parsed, which how PyLd handles numbers. Certainly, the Internal Representation expects a numeric value.