Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of null value with JSON literals #258

Closed
azaroth42 opened this issue Sep 19, 2019 · 8 comments · Fixed by #275
Closed

Use of null value with JSON literals #258

azaroth42 opened this issue Sep 19, 2019 · 8 comments · Fixed by #275

Comments

@azaroth42
Copy link
Contributor

azaroth42 commented Sep 19, 2019

Typically the null value removes the property or resets a context. However JSON literals capture any legal JSON value, which includes null.

Thus there is ambiguity currently as to the expected result of a property with a JSON literal typed value where the @value is null. Current implementations are inconsistent between compact and expanded form, and thus there is missing text in the algorithm to preserve null when the type is @json.

{
  "@context": {
    "@version": 1.1,
    "property": {"@id": "rdfs:label", "@type": "@json"}
  },
  "property": null
}
@azaroth42
Copy link
Contributor Author

RESOLUTION: WG believes that it is least surprising to process null as a JSON literal in this case, and not to remove the property in the internal representation, and thus the null should be preserved.

@iherman
Copy link
Member

iherman commented Sep 19, 2019

This issue was discussed in a meeting.

  • RESOLVED: WG believes that it is least surprising to process null as a JSON literal in this case, and not to remove the property in the internal representation, and thus the null should be preserved.
View the transcript Use of null value with JSON literals
Rob Sanderson: See Syntax Issue #258
Gregg Kellogg: in most statements we do not include the nulls. one exception is JSON literals
… but null is a valid JSON value, so there are reasons to keep them
… pchampin pointed out a similar situation with strings, but that was an implementation issue
… but it did help us find this
… you can keep the null value currently by using the @type: @json
… but in other cases we take it out
… so we’re at least inconsistent
… it implies that there’s some missing algorithm text
… for preserving a key/value with a value of null
… there are various options for preserving them
… we could also decide not to
… but I do think we can
… if you expand it, and then re-expand it the null goes away…even when using the @json value type
… it’s an editorial issue once we figure out how we want to handle it
… because it’s a lack of clarity
… should be the work of an hour or two
Rob Sanderson: the question then is should the null be treated as a JSON literal null or should we remove the property
Benjamin Young: Apache CouchDB and MongoDB (iirc) will remove keys set to null
Rob Sanderson: that’s what this does in every other case…except the new @json type
… I think it’s more surprising for the null to go away if the type is @json than for it to stay around
… but…do we want to still provide a way to remove the key/value?
Ivan Herman: why would we want to remove key/values?
Benjamin Young: databases do it
Rob Sanderson: but this would be full statements
Gregg Kellogg: so most of the testing I’ve done was with numeric values and objects
Benjamin Young: is null on it’s own a valid JSON value/document?
… what would JSON.parse do?
Gregg Kellogg: it would keep it
Pierre-Antoine Champin: I’m playing around with the code right now, and gkellogg mentioned that re-expansion would get rid of it
… I added the @version: 1.1
… otherwise it doesn’t work at all
… and when I do it, it looks like we get an invalid value
Gregg Kellogg: part of the use of null is to eliminate contexts
… you can certainly handle these by setting a 1.1 at the processor level–if the document itself doesn’t set it
Rob Sanderson: azaroth tests JSON.parse("null") in chrome, and the result is a real null
Gregg Kellogg: but you’re right it could be restricted to 1.0-based processing
… so we may need to update tests to use 1.1 mode
… and test with expanded values
… so setting the processing mode is probably the way to do it
Proposed resolution: WG believes that it is least surprising to process null as a JSON literal in this case, and not to remove the property in the internal representation, and thus the null should be preserved. (Rob Sanderson)
Rob Sanderson: +1
Ivan Herman: +1
Benjamin Young: +1
Gregg Kellogg: +1
Pierre-Antoine Champin: +1
Resolution #1: WG believes that it is least surprising to process null as a JSON literal in this case, and not to remove the property in the internal representation, and thus the null should be preserved.
David I. Lehn: +1

@gkellogg
Copy link
Member

Actually, I don't think there's anything more to say in the syntax document. It's handled in w3c/json-ld-api#155. Happy to add some extra wording to the syntax document if people think it necessary.

@azaroth42
Copy link
Contributor Author

I think there should be a non-normative note in syntax, in 4.2.2, as there is a potential expectation that nulls will not be processed, as with other cases.

@iddan
Copy link

iddan commented Sep 26, 2019

Why is null not converted to rdf:nil?

@rubensworks
Copy link
Member

Why is null not converted to rdf:nil?

rdf:nil is not equivalent to null. rdf:nil is used to indicate the end of an RDF list.
The spec says the following:

The resource rdf:nil is an instance of rdf:List that can be used to represent an empty list or other list-like structure.

@iddan
Copy link

iddan commented Sep 26, 2019

Oh, my bad. Thank you.

@azaroth42
Copy link
Contributor Author

Also, this is specifically about JSON literals, where the JSON values are intentionally left as JSON rather than mapped into RDF.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants