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

Consider EXI #3

Open
vcharpenay opened this issue Jan 17, 2020 · 3 comments
Open

Consider EXI #3

vcharpenay opened this issue Jan 17, 2020 · 3 comments

Comments

@vcharpenay
Copy link
Collaborator

It is possible to represent JSON in the Efficient XML Interchange (EXI) format as well. See the EXI4JSON note: https://www.w3.org/XML/EXI/docs/json/exi-for-json.html.

The schema-awareness of EXI may be leveraged as well.

@pchampin
Copy link
Contributor

The schema-awareness of EXI may be leveraged as well.

Since JSON-LD has no fixed schema (beyond some constraints on contexts), I am not sure exactly what you are suggesting...

@vcharpenay
Copy link
Collaborator Author

A schema encoding the JSON-LD syntactic restrictions could be created and appended to the note. Examples of restrictions are available in the EXI4JSON spec.

Not all restrictions need to be encoded, though. A minima, JSON-LD keywords could be put in an enumerated type to then be encoded in a single byte, similarly to what you suggest in #5.

@pchampin
Copy link
Contributor

I still have two concerns with this proposal:

  • capturing the syntactic restrictions of the grammar in the form of a schema looks non-trivial to me, for a benefit that might not be so high (compared to the simpler solution of aliasing keywords, as discussed in Have a dedicated semantic tag for JSON documents #5);

  • the initial idea of this note was about CBOR itself; I see how it could be generalized to "binary representations for JSON-LD", but I'm affraid that it might "dilute" the aim the note...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Non TR Work
Development

No branches or pull requests

2 participants