The W3C JSON-LD Community Group
Go Back
JSON-LD WG
Minutes for 2024-08-14
- Present
- Gregg Kellogg, Niklas Lindström, Benjamin Young, Ted Thibodeau Jr., Anatoly Scherbakov, David I. Lehn
- Chair(s)
- Benjamin Young
- Scribe(s)
- Gregg Kellogg, Benjamin Young
- Agenda
- https://www.w3.org/events/meetings/08563546-30fd-497a-ac16-77f96e96e8c0/20240821T120000/
- Topics
Topic: Announcements and Introductions
Gregg Kellogg is scribing.
Topic: TPAC 2024 Reminders/Planning
Benjamin Young: Schedule has not changed. We've cleared Friday, so meetings Monday-Thursday with main meetings on Thursday.
... We have joint meetings with WoT and RDF-star.
... Most of the meeting times are mornings in PDT, so should be relatively easy for people in other timezones
... I'll give a re-chartering update on Thursday. The hope is to get more interest in the group.
... CBOR-LD and YAML-LD will be key topics, and perhaps the multi-language discussion.
... If the breakout sessions are remote-able, I'll work to make that possible.
Topic: JSON-LD Issue Discussion
Benjamin Young is scribing.
Gregg Kellogg: There are 4 items on the Discuss-Call list
Subtopic: https://github.com/orgs/w3c/projects/84/views/1?pane=issue&itemId=68598311
> URI in Profile triggers CORS Unsafe Request Header Byte rule
Anyone look at this?
Gregg Kellogg: Anyone look at this?
... not sure how to move this along
... so if folks can look at it, that would be great
... or we can reach out to the TAG if that's what's necessary
Subtopic: https://github.com/orgs/w3c/projects/84/views/1?pane=issue&itemId=63002420
> Framing on nested graphs
Gregg Kellogg: Mostly questions on framing
... not much work on it since this was submitted
... so, again, please take a look at this and other open issues
... it can be helpful preamble to a call, or we can remove it from the discuss on call list
Subtopic: https://github.com/orgs/w3c/projects/84/views/1?pane=issue&itemId=73902562
> Changes to the algorithms that will need their own PRs
Benjamin Young: This was put together during a previous call based on things found in other issues.
Gregg Kellogg: This is based on issues dlehn1 raised around JSON literals
... which may require more work around sets when JSON literals are arrays
... the discussion needed could be around possible incompatiblity
... as a previous warning would change
... however that previous approach was broken
... so how do we feel about cleaning up some things around JSON Literals? even if it's technically a backwards compatibility break?
... though, this may not actually effect tests which don't seem to cover this case
Gregg Kellogg: TallTed any thoughts on backwards compatibility breaks here?
Ted Thibodeau Jr.: Not sure. what's the immediate question?
Gregg Kellogg: JSON literals that are only arrays
... dlehn1's shown that an array form JSON literal would be treated differently if it were in a list or set
... either it can be treated as multiple JSON literals in an array
... or the thing itself is a JSON literal
... it does represent a change
... but arguably...
Ted Thibodeau Jr.: Lack of language means it's undefined
... adding a definition could mean that existing implementations are noncompliant
... if there's a way to avoid making them noncompliant, that'd be great
Gregg Kellogg: If we make this change, then some of these original tests may fail
Ted Thibodeau Jr.: Right. is it conform to the spec? or to the test suite?
Gregg Kellogg: Typically, we've said it's passing the tests
... but that got us into trouble with extractAllScripts
... we only have pass/fail on tests
... my feeling is that tightening the language up is consistent with doing a minor version update
... but we're sort of in a hole because we've previously said passing the tests means being conformant
Ted Thibodeau Jr.: We could right a test where you could do either
Gregg Kellogg: The RDFa test suite used SPARQL which could have handled this scenario
... unless we come up with some new way of handling test suites with a variety of different results
... what I'm after is if we change the behavior, is that too big of a change in a 1.2 version?
... it's just a matter of judgement
... does anyone else thing it's worth a 2.0 release?
Ted Thibodeau Jr.: I don't think this is a breaking change in that sense
... it makes for more complicated tests
... if the result is you have to pass one to three of these tests
... it's more complicated test authoring, but better for implementers
Gregg Kellogg: I don't think that feels right
... maybe there's a way to label the tests for v1.1 and v1.2 so we can compare
Ted Thibodeau Jr.: The point is interop
... if someone has implemented v1.1, will that implementation work with others?
... since it wasn't defined, then we don't have interop currently
... what we're aiming at is interop
... if the new tests clarify what one should expect, then at least the implementations would know how they should handle each others output going forward
... there's no simple way to word this...
... but interop as a goal should guide what we do
... something underspecified means interop is up in the air already
... defining it should improve interop
... which then seems fine for a v1.2
Gregg Kellogg: Yeah, so most of this seems to be about updating the tests
... the rest will be about tightening down the spec--which seems undebated
Ted Thibodeau Jr.: If it's completely undefined, then tightening it down would be a breaking change
... and that would require a v2.0
Benjamin Young: Do we know how other implementations handle this now?
Ted Thibodeau Jr.: I think this needs to be broken down into multiple issues (one per bullit).
Gregg Kellogg: If we put these on a branch, then we could see how they keep (or don't) compatibility with the new suite
... if there's no impact, then adding these tests should not be considered to break backwards compatibility
... if it does show that, then we need to revisit this and possibly differ
Ted Thibodeau Jr.: The challenge is that implementation is not permissioned...anyone can implement this at anytime anywhere
... which makes me wonder about the A, B, and C could all be passed...even if mutually incompatible
Niklas Lindström: I just tested one specific (compact/js07) quickly against TRLD (which _should_ follow the spec), and it would fail on this updated test. (But the change does make sense IIUC.)
Gregg Kellogg: If we say do it this way in 1.2, but it's ok if you don't feels inconsistent with normative text in the first place
... v1.1 doesn't define a behavior
... so one could do anything
... if we then define it in v1.2, then it's a new minor feature
Ted Thibodeau Jr.: I think it's a 2.0
Gregg Kellogg: Any thing we add could cause that sort of distinction...which would then mean we always require a v2...which I don't think that's what's intended
... v2 should be more about truly breaking something we said in the past
... if v1.2 adds but does not change, then v1.2 seems fine
Ted Thibodeau Jr.: I'm not seeing how such a change would not break a v1.1 implementation
Gregg Kellogg: JSON-LD v1.1 uses language strings using a data type or a compound literal
... we should in v1.2 actually specify the behavior with language tagged strings
... that would break v1.1 implementations
... I'm not sure how to reconcile those types of tests
Benjamin Young: We signal 1.1 documents through the API and context setting. Do 1.1 documents remain vague if processed by a new processor?
... Do 1.1 documents become 1.2 documents when all processors upgrade without having to update behavior?
Ted Thibodeau Jr.: There was a lot of effort put into 1.1 to avoid the need to declare the version.
Gregg Kellogg: Now I wonder if any change to any spec means a major upgrade
... in turtle, the version string can signal new behavior
... it's intentionally done that way as an expansion mechanism
... so in JSON-LD, new behavior that reinterprets something that does not cause a syntax error, would require a major update
... the big question is do we need to ask for a major version publication option
Benjamin Young: Yeah...this will effect the charter
Benjamin Young: This has chartering implications.
Ted Thibodeau Jr.: These issues could be tagged as "for v2"
Niklas Lindström: SPARQL 1.1 queries can't be parsed by 1.0 parsers... Isn't a major bump "reserved" for _changing_ what something means? (Not that adding syntax should ever be taken lightly.)
Gregg Kellogg: JSON-LD is set apart from other RDF grammars because it's goal is to support as much JSON as possible
... which means supporting more of JSON could mean more often breaking changes in JSON-LD
... so, maybe we make a list of what we think will be incompatible, and then make the case for why we need a major update
... if we keep that fairly tight, then it may not be as wide open
Benjamin Young: I wonder about version identification in the JSON documents.
Gregg Kellogg: And we could clean up some cruft from past versions
Benjamin Young: In regards to VCWG, a "strict" mode is the required normal.
Gregg Kellogg: Any major version change still leans on the fact that we're permissive in how we parse JSON-LD
... It's not very permissive and restricts the shape strictly.
... When we salt the input with version numbers, we're in danger of confusing people.
... Unless a JSON-LD processor in the future can process everything from the past, it's not a version of JSON-LD.
... Future processors need to be able to process all existing data.
Anatoly Scherbakov: I agree with Benjamin. Backwards incompatibility breakage ⇒ death of JSON-LD.
Gregg Kellogg: Directional literals are a case of this
... if you wanted directionally language tagged literals, we're parsing the same document, but generating a more refined result
Benjamin Young: The key thing to keep stable is the document world.
... The processors may be have innate behavior due to underspecification.
... JSON-LD with or without a version number, we need to create things that remain stable.
... The important thing to me is that the expressed JSON remains interoperable.
... We need to guard against producing results that don't choak on that result.
... Knowing the affect of any changes on actual usage of JSON-LD is important before we go outside. If we have questions, we should come with evidence.
https://github.com/w3c/json-ld-api/issues/613 -> Issue 613 Changes to the algorithms that will need their own PRs (by BigBlueHat)
Benjamin Young: What would it mean to do a JSON-LD 2.0? Would documents need to announce this somehow?
David I. Lehn: We can document things that we do know. The JSON Literal changes likely don't affect any existing usage, or we would have heard about it.
Benjamin Young: If you break any JSON document into an RDMS, it's up to you to make sure that that data can come back out.
... If I ingest some JSON-LD into a processor that includes dirLangString and it doesn't come back out, that is a problem with the RDMS, not JSON-LD.
Benjamin Young: Next WG meeting on September 4th.
... We'll focus on JSON-LD discussions that relate to the charter.