Error code for invalid JSON literal?

[davidlehn]

How should errors be handled when fromRdf tries to parse an invalid JSON literal? I'm not sure if one of the current error codes [1] is appropriate or if an "invalid JSON literal" or similar code should be added. I added that and a test in the jsonld.js JSON literal patch [2], but it's an ad-hoc code and the API spec and tests should probably specify what to do.

[1] https://w3c.github.io/json-ld-api/#jsonlderrorcode
[2] digitalbazaar/jsonld.js#325

[gkellogg]

Yes, we should have a test case with an invalid literal (or several test cases) and define an error code for when this is encountered; the existing tests do not contain invalid data.

[davidlehn]

Perhaps the algorithm needs updating too to say to use that specific error code. A simple fromRdf error test is easy:

_:b0 <ex:p> "bogus"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON> .

That was put in the jsonld.js patch:
https://github.com/digitalbazaar/jsonld.js/pull/325/files#diff-99b6e3470d0086bf7b17c11d2da2d74c

I wasn't sure how to write other tests since invalid JSON inside JSON-LD will just cause a general parsing error.

What should error code be? "invalid JSON literal"? "invalid JSON literal value"?

[gkellogg]

I think "invalid JSON literal" is fine, and expressive.

Note that we're putting an invalid JSON literal in N-Quads, so the fact that it's not valid JSON, shouldn't present a testing issue.

Without looking at what you've done, something like "bogus", but also "{", "[{]", etc. would all be reasonable values to check for. Really, anything that a standard JSON parser would complain about.

Values such as "string", null, true, false, and 1e1 are all reasonable JSON values.

[gkellogg]

WG resolved to close the issue as complete.