`extendedYAML` flag clashes with `processingMode` option

[anatoly-scherbakov]

Why

JSON-LD 1.1 API spec states the following about processingMode parameter:

If set to json-ld-1.0 or json-ld-1.1, the implementation must produce exactly the same results as the algorithms defined in this specification. If set to another value, the JSON-LD processor is allowed to extend or modify the algorithms defined in this specification to enable application-specific optimizations. The definition of such optimizations is beyond the scope of this specification and thus not defined. Consequently, different implementations may implement different optimizations. Developers must not define modes beginning with json-ld as they are reserved for future versions of this specification.

YAML-LD spec in its non-normative part defines the extendedYAML flag:

... If set, allows the use of node tags when serializing RDF literal values having datatypes other than xsd:string or language-tagged strings as scalar values. Otherwise, it serializes RDF literal values to the closest scalar representation from the YAML Core Schema.

I feel we might have a duplication.

Proposal

What if we write

{
  "processingMode": "yaml-ld-extended"
}

instead?

Consequences

• :heavy_plus_sign: We reduce the complexity and reuse the existing functionality with conformance to existing specifications;
• :heavy_plus_sign: We do not have to delete the processingMode option as per https://github.com/json-ld/yaml-ld/issues/139 - instead,
  • We will keep it for the future,
  • But specify that json-ld-1.0 value MUST cause the processor to throw an error :boom: .

[gkellogg]

This seems like a good way to go, particularly if we either remove this property when calling the JSON-LD algorithms, or set it explicitly to json-ld-1.1. This would repurpose processingMode to have a behavior in YAML-LD processing independent from its behavior in JSON-LD processing.