You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recommend we rename @sealed to @protected because it seems to better match the intent of the feature and the notion that terms may be protected -- but this protection can be removed under circumstances that allow it to be safely removed.
The purpose of the @sealed/@protected feature is to protect JSON-only developers who want to read a spec and then write applications that safely consume JSON-LD data by applying validation rules only, without the need for JSON-LD processing. In order to give this sort of assurance, @protected terms can be used. These protections are not necessary for data that is nested under new terms that are not in the specification -- as these would be disallowed by validation or ignored (not traversed) by such applications. Therefore, the protections can only be removed by creating a new term definition with a scoped @context that clears the protected terms and is used as a property to extend the JSON tree.
I also recommend we include the above text (the second paragraph) in the spec itself to explain the purpose of the feature. We may want a small blurb like this for every feature presented so as to make the spec easier to consume, i.e. "The purpose of this feature is X... here's how it works... here's an example (or two, etc)."
@dlongley This is precisely what the first paragraph of section 4.1.8 is meant to convey.
The second part of your text ("These protections are not necessary...") is not yet reflected, though, and I'll happily steal it for introducing the "@context": null exception.
I recommend we rename
@sealed
to@protected
because it seems to better match the intent of the feature and the notion that terms may be protected -- but this protection can be removed under circumstances that allow it to be safely removed.The purpose of the
@sealed
/@protected
feature is to protect JSON-only developers who want to read a spec and then write applications that safely consume JSON-LD data by applying validation rules only, without the need for JSON-LD processing. In order to give this sort of assurance,@protected
terms can be used. These protections are not necessary for data that is nested under new terms that are not in the specification -- as these would be disallowed by validation or ignored (not traversed) by such applications. Therefore, the protections can only be removed by creating a new term definition with a scoped@context
that clears the protected terms and is used as a property to extend the JSON tree.Related to #136.
The text was updated successfully, but these errors were encountered: