Leave YAML-LD Extended profile out of bounds of the Community Report

[anatoly-scherbakov]

The Extended YAML-LD profile #35 was conceived as a way to improve the user experience by utilizing expressive means that YAML 1.2 enjoys and which JSON does not possess, in particular:

• tags YAML-LD IRI tags #79,
• anchors and references Define anchor usage in yaml-ld #13 ,
• datatypes YAML-LD datatypes (and tags for datatypes) #17 .

Two alternative methods of tackling this have been proposed:

• Use tags to distinguish "plain" YAML-LD from "idiomatic" YAML-LD #6 Extend the JSON-LD Internal Representation and agument the inner workings of JSON-LD processor software,
  • which means implementation of language and library specific specialized processors;
• Downgrading from Extended Internal Representation should use value objects #84 or downgrade an Extended YAML-LD document to more standardized, JSON compatible form using JSON-LD native features like value objects and language maps,
  • which might be accomplished by a converter tool accepting an Extended Profile YAML-LD document and returning a JSON Profile YAML-LD document,
  • if implemented as a part of a library this tool would also be language specific.

Each of these approaches requires efforts, and it is unclear whether the participants of this community have sufficient time to put into the project. That said, we still want to drive the Community Group Draft document to a state where it can be accepted by the Working Group and thereafter be published as a Recommendation.

On the Feb 15, 2023 Community Group meeting, @gkellogg had proposed that we postpone the implementation of the Extended Profile.

• the spec should restrict YAML-LD to features that JSON natively supports;
• Extended Profile and related YAML features, as well as possible methods for using them, might be described in the non-normative part of the spec document.

Thus,

• we shall not lose the work already put into the Extended Profile discussions,
• and we will have much higher chances of getting the spec to a recommendation status.

This issue is to present this proposal for public discussion as a request for comments. I suggest we use reactions on this issue to vote: 👍 to support and 👎 to disapprove.

Thoughts?

[anatoly-scherbakov]

Roadmap

This diagram tries to illustrate what kind of steps we are going to take for each alternative of the ones listed above. Every arrow on the diagram means "blocks". For instance, "Document motivations …" blocks "Document alternatives …" because (IMHO) we should first explain WHY we're thinking about the Extended Profile and then we should explain the possible choices we had considered.

The ⊻ symbol is XOR: it means we choose exactly one option among the alternatives the box with this symbol provides.

During the discussion I expect to be updating this diagram in-place, editing this message, to reflect the feedback from everyone.

[gkellogg]

Very nice diagram and work plan!