JSON-LD WG

Minutes for 2025-01-29

Present

Gregg Kellogg, Anatoly Scherbakov, Niklas Lindström, Ted Thibodeau Jr., Ivan Herman, Benjamin Young, Pierre-Antoine Champin

Chair(s)

Gregg Kellogg

Scribe(s)

Anatoly Scherbakov, Gregg Kellogg

Agenda

https://www.w3.org/events/meetings/635aef15-a607-499c-b32a-926d3cb3a580/20250129T120000/

Topics

Announcements and Introductions
JSON-LD Issue Discussion

Topic: Announcements and Introductions ✪

Anatoly Scherbakov is scribing.

Gregg Kellogg: TPAC will be in Japan. RDF-Star WG will be there, some of us will be there.

Topic: JSON-LD Issue Discussion ✪

Gregg Kellogg: https://github.com/orgs/w3c/projects/84

Benjamin Young: Let's keep Charter issues on the radar

Benjamin Young: They're now in the project

Gregg Kellogg: There are items without a status, some of them are closed PRs and can be removed

Gregg Kellogg: Let's look at #446 at json-ld-syntax repo

Pierre-Antoine Champin: [Arrives]

Subtopic: w3c/json-ld-syntax#446 ✪

Gregg Kellogg: Dave commented on it. Can we reclassify it Dave?

David I. Lehn: I do not remember exactly as it was back in November

Benjamin Young: This is related to safe mode and we haven't got an issue about safe mode yet. Need to make an issue on json-ld-api about describing JSON-LD Safe Mode

Benjamin Young: VC and other implementations depend on that and we need to make an issue to add it to the charter at least

Subtopic: w3c/json-ld-api#625 ✪

Gregg Kellogg: We can finish this soon but Pierre-Antoine came up with approval and change requests

Pierre-Antoine Champin: Spec text is ok but the test has an issue. It tests something against xsd:decimal which mismatches the text

Pierre-Antoine Champin: Exponential notation is not allowed in the lexical representation

Anatoly Scherbakov: Will check these out

Gregg Kellogg: Once it is resolved we can go ahead and merge it

Benjamin Young: https://github.com/w3c/json-ld-api/issues/536

Benjamin Young: That was the one I referred to earlier

Benjamin Young: Safe mode has to be surfaced as an issue

Gregg Kellogg: This should be a more explicit thing in the charter as it is a substantial change to the spec

Benjamin Young: I can post it as a charter issue but it is also a change to the API although it is likely just a new option

Gregg Kellogg: We need a champion for this

Gregg Kellogg: This would be a Class 4 issue

Gregg Kellogg: Which means it will be addressed after smaller changes

Benjamin Young: Our initial charter draft was too vague, the second was too specific, now we likely need some middle ground

Benjamin Young: We could classify issues into groups and then characterize them in the charter

Anatoly Scherbakov: Can this be a separate value for the Profile option?

Gregg Kellogg is scribing.

Anatoly Scherbakov: I wonder if "safe mode" can be addressed by a "profile"?

Benjamin Young: Safe mode is a processing mode

Benjamin Young: https://github.com/digitalbazaar/jsonld.js?tab=readme-ov-file#safe-mode

Benjamin Young: `Const expanded = await jsonld.expand(data, {safe: true});` as currently implemented.

Gregg Kellogg: Safe mode is an option applying to all API entry points, used in the algorithms to handle certain not-allowed behavior

David I. Lehn: Maybe safe mode is not directly related to other issues

David I. Lehn: Safe mode means flagging certain errors which would cause problems in certain circumstances

David I. Lehn: That's what jsonld.js does and there are a bunch of tests for it

Gregg Kellogg: Changes like this need people to sponsor and track them

Benjamin Young: We will do this but what is the process? PR to the API spec perhaps, or write it up in some giant issue?

David I. Lehn: Maybe it doesn't need to be in the spec initially

David I. Lehn: But we can describe what this mode does and put it somewhere else to see whether that's what people want

Benjamin Young: Maybe this could be a separate document or a separate issue

David I. Lehn: Might be hard to write this as an issue. If we did a PR this would change the spec text. Maybe it would be easier to keep it as a separate document

Gregg Kellogg: Maybe a wiki article which can then be edited then

Gregg Kellogg: Champions in the group would drive this discussion, communication with VC and other groups, and ultimately PRs

David I. Lehn: I wrote the code, just need time to drive this

Benjamin Young: We do not have an issue to track this and keep it on the radar

Gregg Kellogg: Let's create a tracking issue in the syntax repo if it influences multiple specs

Gregg Kellogg: But the ideas might be developed in a wiki entry rather than in issue comments

Benjamin Young: It works to reference wiki page from the issue

David I. Lehn: Haven't seen projects using GitHub wiki functionality

Benjamin Young: It is git based, you can do PRs

David I. Lehn: Was thinking about doing something as a document at json-ld.org

Benjamin Young: We can document this as if we were writing a spec and reference from the issue

Benjamin Young: I'll create an issue

Gregg Kellogg: We just need to track the work and integrate it into the spec later

David I. Lehn: An alternative to Safe mode ls Well Formed mode where you do not check anything as you know data is correct

Gregg Kellogg: Seems similar to compaction

David I. Lehn: This is mostly to skip checks, like check for URLs for example, to improve performance

Gregg Kellogg: Looking forward to issues to track

Subtopic: https://github.com/w3c/json-ld-api/issues/627 ✪

Gregg Kellogg: We specify interfaces with WebIDL. If you call spec to spec it is not very useful, it was designed to describe web browser interfaces

Gregg Kellogg: We hijacked that in 1.1 to describe JSON-LD interfaces

Gregg Kellogg: A champion for this issue?

Gregg Kellogg: If none then we can close it, or we need someone who really wants to drive this work forward

David I. Lehn: Do others use this interface in implementations?

David I. Lehn: We have WebIDL tests in jsonld.js but not sure about their status

Benjamin Young: TAG proposed WebIDL

Benjamin Young: There is a bit of confusion about usage of WebIDL

Ivan Herman: We might look into using IDL instead of WebIDL because json-ld is not necessarily implemented in a browser

Gregg Kellogg: WebIDL describes method signatures, how to create Promises, and ultimately returning the data structures

Gregg Kellogg: If not WebIDL then we'd invent something that does what WebIDL does

Gregg Kellogg: WebIDL does what we want but strict conformance to WebIDL is confusing especially because its tools are JS specific

Gregg Kellogg: We might to add some text to JSON-LD Processor Interface that explains why we use WebIDL

Gregg Kellogg: Removal of WebIDL will mean a substantial change worth JSON-LD 2.0

Anatoly Scherbakov: I recall a conversation that not every implementation may strictly conform to WebIDL, for instance BISON>

... Does that mean the implementation is not conformant? We might add something to the spec saying that WebIDL interface does not need to be followed to the letter, but if you conform to the norms of your language, you would be conformant.

... Secondly, could a theoretical replacement be an RDF Ontology? That would be a big undertaking.

Pierre-Antoine Champin: We could respond to the issue that we were required to use WebIDL in the past

Pierre-Antoine Champin: Removal of WebIDL would create a lot of work and break backwards compatibility

Pierre-Antoine Champin: We could clarify that the use of WebIDL should be a requirement for browsers to implement it, it is just a language customary for use in W3C

Pierre-Antoine Champin: Will look into documenting that in our issues

Pierre-Antoine Champin: If we acknowledge it has some issues we might not need to do huge work on this subject

Subtopic: https://github.com/w3c/json-ld-syntax/issues/436 ✪

Gregg Kellogg: CPRS and media types keep coming up

Gregg Kellogg: Ld+json media type sends JSON-LD but we changed JSON-LD between 1.0 and 1.1 without changing the media type

Gregg Kellogg: We introduced profiles and version announcement in the context

Gregg Kellogg: In Turtle, we introduced things like triple terms and there's an argument we should use a new media type because of that

Gregg Kellogg: I wonder whether it applies here as well

Gregg Kellogg: In 1.2, are we comfortable with application/ld+json?

Gregg Kellogg: Or maybe we should think further about it

Anatoly Scherbakov: Is there at all a practice to include versions in media types?

Ted Thibodeau Jr.: We can either include version into the type or into the document

Ted Thibodeau Jr.: All of this is pretty inconsistent

Pierre-Antoine Champin: Text/html ?

Ted Thibodeau Jr.: Within .doc documents, there were multiple versions but at some point .docx was introduced

Pierre-Antoine Champin: Also, the move from .doc to .docx was a move from a closed proprietary format to an open-ish format

Ted Thibodeau Jr.: There is original JPEG and JPEG2000 but applications can distinguish

Niklas Lindström: Indeed. HTML, javascript, XML, CSS; the web is full of formats whose syntax evolves in sometimes non-backwards-compatible ways, yet keep the same media type? Some may be better designed than others to cater for it though.

Anatoly Scherbakov: .Doc and .docx are fundamentally different formats, one proprietary, the other open-ish.

... I don't think the same can be said about JSON-LD.

Niklas Lindström: Also: https://w3ctag.github.io/the-web-is-not-versioned/

Ted Thibodeau Jr.: What happens when a tool for JSON-LD 1.1 encounters a document in 1.2? Does it choke, or a part of 1.2 document gets ignored or does it just work?

Ted Thibodeau Jr.: 1.2 Changes are a bit deeper than what happened between 1.0 and 1.1

Ted Thibodeau Jr.: They might be important enough to go to 2.0 which might even warrant a new media type

Benjamin Young: There's a huge risk about changing the media type for JSON-LD, most of these are embedded in html pages

Benjamin Young: These tools are very unlikely to change and people are unlikely to opt into 2.0 unless there is a really good reason

Benjamin Young: With 1.1 we tried to gradually improve the standard

Benjamin Young: We might end up creating two things: 1.2 with backward compatibility and 2.0 that breaks it

Gregg Kellogg: In many instances media type hasn't changed because consequences would be too drastic

Pierre-Antoine Champin: Agree with everything that had been said|

Gregg Kellogg: I will not be here on next meeting in two weeks

The W3C JSON-LD Community Group

Go Back