Closed davidlehn closed 11 months ago
@gkellogg,
I suppose this depends on what it means to be the "same as the previous", which is what is in step 27.1.
Yes, though surely the "same as the previous" was not intended to trigger errors on meaningless differences due to syntactic sugar. It seems we have an oversight here where we need to clarify that processors must de-sugar things to properly compare for "sameness".
"foo": {"@id": "ex:foo"}
"foo": "ex:foo"
This currently fails in jsonld.js and with the distiller. Should implementations be considering these forms equivalent as far as protected redefinition checks are concerned?