Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

W3C YAML-LD #125

Open
westurner opened this issue Jul 15, 2023 · 7 comments
Open

W3C YAML-LD #125

westurner opened this issue Jul 15, 2023 · 7 comments
Labels
help wanted Extra attention is needed

Comments

@westurner
Copy link

westurner commented Jul 15, 2023

STORY: Users can reformat YAML-LD with yamlfmt per the YAML-LD/JSON-LD guidelines.

@westurner
Copy link
Author

From https://json-ld.github.io/yaml-ld/spec/#example-convenience-context ::

EXAMPLE 7: Convenience Context
Code of the convenience context. Available as: https://github.com/json-ld/convenience-context.

{
  "@context": {
    "$base": "@base",
    "$container": "@container",
    "$direction": "@direction",
    "$graph": "@graph",
    "$id": "@id",
    "$import": "@import",
    "$included": "@included",
    "$index": "@index",
    "$json": "@json",
    "$language": "@language",
    "$list": "@list",
    "$nest": "@nest",
    "$none": "@none",
    "$prefix": "@prefix",
    "$propagate": "@propagate",
    "$protected": "@protected",
    "$reverse": "@reverse",
    "$set": "@set",
    "$type": "@type",
    "$value": "@value",
    "$version": "@version",
    "$vocab": "@vocab"
  }
}

The convenience context contains an alias to every JSON-LD keyword which the JSON-LD 1.1 specification permits aliasing — which means all the keywords except @context. The reserved @ character is replaced by $, which is not reserved and therefore does not require quoting.

@westurner
Copy link
Author

How should yamlfmt format YAML-LD YAML documents?

@braydonk
Copy link
Collaborator

Hi @westurner thanks for the feature request. This sounds like it deviates heavily enough from a normal yaml document that it should likely be implemented as a separate formatter that the user can choose to use instead of the current basic one.

I will not have time to implement this any time soon unfortunately, but if anyone in the community wanted to I am happy to help explain how to design it to satisfy the interface and hook into the rest of yamlfmt (I don't have any developer docs yet only user ones).

@braydonk braydonk added the help wanted Extra attention is needed label Jul 17, 2023
@westurner
Copy link
Author

westurner commented Jul 17, 2023 via email

@braydonk
Copy link
Collaborator

It depends what kind of help you'll need. If it's about actually implementing the formatter interface, I have not actually documented how it works but I don't think it's too tough. Development docs have always been low priority cause I haven't had anyone trying to use the libs a whole lot yet (at least that I've heard about). I am happy to help guide how to do that, and it'll help me actually write some docs along the way too.

Unfortunately I don't know much about YAML-LD; had never heard of it before you opened this issue here 😄
So I can't say for sure whether this will need an entirely new yaml parser or if it could be done using some fancy rearranging on the Node type used by the yaml library in the basic formatter. The basic formatter turns the whole document into an array of Nodes that recursively contain all the others, and the formatter supports applying basic transformations on it.

If it will require a new parser due to some difference in YAML-LD syntax, then it would be best implemented as a separate formatter that used its own parser. This ends up just getting down to how to write parsers in general. There are 2 solid yaml libraries in Go, yaml.v3 and go-yaml that could serve as reference or basis for a fork.

The way formatter options work in general is that they are completely independent of each other. So a hypothetical yaml-ld formatter would have its own set of configuration options, and these would be specified either in the .yamlfmt config file, or in the -formatter flag (see docs for info). There would need to be another flag that actually supports changing to the right formatter; currently there is only one, so a flag to choose a different formatter doesn't exist right now but I can easily add it if it becomes necessary.

Hopefully this helps a bit, I'm happy to connect directly if you or anyone else wanted to take this work on.

@westurner
Copy link
Author

There probably doesn't need to be a new parser just to normalize quoting, optionally replace @ with $, and sort attrs with @context and then $id $type etc at the top?

With standard ASCII (and thus also Unicode) collation, IIRC $ is before A but @ is not, so @context will not be at the top of a json/yaml doc after e.g. cpython's json.dumps(sort_keys=True).

(Also, FWIW, Gmail mobile and Gmail web have different collation orders for sorting labels; @ <=> $)

@braydonk
Copy link
Collaborator

If the YAML-LD can properly conforms to YAML 1.1 spec then it's possible to do this in the existing formatter and do the transformations on the yaml.Node structure from the parsed document. (I make no promises about the ergonomics of that structure, I've never worked with it in a way where I've tried to transform and it might be okay or it might be super asinine)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants