gkellogg
commented
2 months ago We do have the following in the Conformance section:
A YAML-LD document complies with the YAML-LD Basic profile of this specification if it follows the normative statements from this specification and can be transformed into a JSON-LD representation, then back to a conforming YAML-LD document, without loss of semantic information.
The JSON-LD description should probably be a normative reference to JSON-LD 1.1.
The processingMode was intended as a way to transition from JSON-LD 1.0 to JSON-LD 1.1; I think it's fair to say that YAML-LD documents are JSON-LD 1.1 (or later) only. The keyword space was sufficiently locked down in JSON-LD 1.1, so that new features can be introduced that will distinguish it from JSON-LD 1.1; It's probably sufficient to just remove the processingMode parameters too that JSON-LD algorithms will use the default of json-ld-1.1
A JSON-LD 1.2 processor (or 2.0) could add new features using different keyword combinations that would be detected by a JSON-LD 1.1 processor as an error, so future explicit use of this will probably not be necessary, although I would think that would would allow for a json-ld-1.2 mode, and possibly even make it the default.
anatoly-scherbakov
Context
The YAML-LD spec doesn't state it normatively, but we generally assume that the documents we're processing will conform to JSON-LD 1.1.
expand()and other JSON-LD API functions acceptprocessingModeargument.What if it is set to JSON-LD 1.0? The spec doesn't detail that.
Alternatives
If we are bold enough
We might even remove the
processingModeoption altogether (but what if we want to maintain 1.1 backwards compatibility when 1.2 is released? Shall we add this option again? Sounds crazy, so I don't think we should do it.)