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
This is a tracking issue to make sure a particular concern is clearly recorded. Duplicates will be closed.
@nadalin has raised a concern with JSON-LD as a supported syntax in the specification [1][2][3] and has asserted that non-JSON-LD users will be forced in some way to do JSON-LD processing. The specification makes clear that there is no expectation that all implementers of the specification must implement all of the syntactic representations. Additionally, the Working Group has clearly identified an intent to ensure that only users of JSON-LD are required to do any JSON-LD processing, while all other formats have only syntax constraints that may appear to be JSON-LD but in fact require absolutely no JSON-LD processing. We believe the specification reflects this intent.
RESOLVED: The Working Group has addressed all concerns outlined in issues #633 and #634 to the best of their ability, these are architectural decisions made by the group, and asserts that the specification reflects the consensus position of the Working Group and thus the issues should be closed.
This is a tracking issue to make sure a particular concern is clearly recorded. Duplicates will be closed.
@nadalin has raised a concern with JSON-LD as a supported syntax in the specification [1][2][3] and has asserted that non-JSON-LD users will be forced in some way to do JSON-LD processing. The specification makes clear that there is no expectation that all implementers of the specification must implement all of the syntactic representations. Additionally, the Working Group has clearly identified an intent to ensure that only users of JSON-LD are required to do any JSON-LD processing, while all other formats have only syntax constraints that may appear to be JSON-LD but in fact require absolutely no JSON-LD processing. We believe the specification reflects this intent.
[1] #525
[2] #557
[3] #489
The text was updated successfully, but these errors were encountered: