JSON-LD Working Group Telco — Minutes

Date: 2020-03-06

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Ruben Taelman, Ivan Herman, Harold Solbrig, David I. Lehn, Tim Cole

Regrets: Pierre-Antoine Champin, Dave Longley, Benjamin Young

Guests:

Chair: Rob Sanderson

Scribe(s): Gregg Kellogg, Rob Sanderson

Content:


1. Announcements / Reminders

Ivan Herman: The new CRs were published yesterday.

Rob Sanderson: CR2 was published yesterday, thanks to pchampin, gkellogg and ivan for making it happen. There was some manual work involved.

1.1. Daylight Savings

Rob Sanderson: The US goes on to Daylight Savings Time on Sunday, but not in other parts of the world. So, if you’re not in the US, plan to come on an hour earlier.
… We’ll highlight that in agendas.

2. Issues

2.1. Test Changes

Rob Sanderson: There have been a few new issues in API and framing.

Gregg Kellogg: There can be bugs in tests and we shouldn’t consider those as normative changes, but instead typos
… if the exception raised should be different based on what is the spec, and there’s a bug in the test based on implementations, then that’s just fixing a bug
… there are two outstanding PRs

Rob Sanderson: https://github.com/w3c/json-ld-api/issues

Gregg Kellogg: Tests are from HTML – should be load document failed rather than an invalid element
… so nothing changed from success to fail or vice versa, just a different exception was thrown
… and in compact pr02, the test looks to verify that we raise an error when a protected term is changed
… and the test wasn’t sufficiently different to have a change that was picked up, so it makes more changes

David I. Lehn: It caught things before, but we changed the spec elsewhere and didn’t change the test

Gregg Kellogg: Right
… the other PR is 405, related to issue 403. A change to the algorithm where we had a typo of result for nest result. Clear from the surrounding text, but a minor change to the algorithm

Rob Sanderson: Do we know who @roptat is and what they’re doing? :)

Gregg Kellogg: Nope :)

David I. Lehn: Doing a guile implementation

Rob Sanderson: https://www.gnu.org/software/guile/

David I. Lehn: Guile is a free Scheme implementation that’s been around for a while.

Gregg Kellogg: Commenter agreed, so that’s probably good enough to merge

2.2. Prefixes

Rob Sanderson: https://github.com/w3c/json-ld-syntax/issues/329

Harold Solbrig: I put in a -1 as there is quite a bit of work the community will need to do to get around the issue, and they’re not anxioius to do it.
… Its not that it won’t be fixed, but that we may need to wait a while.
… One of the members went over previous 1.0 releases to find out where they were bit.
… I hate being obnoxious about this, but I find myself representing this group, and discovering that we can’t use what’s there today. It was flaws in our own codebase which hid this.

Gregg Kellogg: Need to stop adding things in order to have a release, but shouldn’t stop all work and the new process should let us move more swiftly
… Of all the proposed changes, the prefix wrapper or the prefix: true would solve the issue.
… Or, if we could just add “_” to the list of gendelims that would go a long way towards helping.
… I’ll need to go back to see how strongly the group feels.

Rob Sanderson: I don’t believe we can just add “_” to gendelim, as it would mean changing the algorithm and tests, which is what we determined to be the criteria for normative changes.

Harold Solbrig: That’s unfortunate. The only other thing I can think about is if we can get the library authors to put in a non-standard workaround.
… Otherwise, we’re putting out a spec that has so much promise but could be unusable by this community.

Ivan Herman: I think it’s another CR; it may change implementations that have already passed all the tests. It’s a changing feature, even if it is minor, but formally it is changing an existing feature.
… The previous changes were addressing bugs.

Rob Sanderson: This is an intended consequence that the community is asking us to walk back, or to give them more control in managing prefixes.
… One concern I have about adding “_”, is that while a lot of systems use camel-case, a number also use snake_case.
… This would lead to exactly the same problem we were trying to fix.

Harold Solbrig: Unfortunately, the fix in 1.1 is to have the ability to say I intend to be a prefix, and the syntax requires major structural edits.
… I understand the issue, but I need to consider further and discuss with the community.
… That might be a way to convince them.

Ivan Herman: To discuss the possibilities, we have to realize that if we go back to a WD, we run some risk, as there is no guarantee that the AC will agree to an extension of the charter. It may not be high, but it’s non-zero.

Harold Solbrig: I’m split on the issue myself.
… I’ll see if the number of libraries they use is limited enough that they can maintain forks.
… How far out might it be before it can be addressed formally?

Ivan Herman: I would be hopeful that the process changes can be done relatively quickly; not 2 years.
… The processes update is ongoing, and we’d need to have a discussion on turning the group into a maintenance group which could do such a change in 1-2 months.
… Such a change would be backwards-compatible, so it would make it easier to do.
… It means that JSON-LD becomes a kind of continuously evolving standard, similar to HTML5.
… They added an element to HTML5 fairly smoothly.

Harold Solbrig: I’m going to say that I don’t want to stop things, so I’m willing to revise my vote.

Ivan Herman: -1 is not a-priori a formal objection.
… At some point in time the new process will go to the AC for a vote, and there may be people that won’t do that. So any AC members here might want to speak up about that.

Gregg Kellogg: The CG might make a parallel extension to the spec
… prior to this group there was interest in updating towards a 1.1
… maybe something could be done there to hang your hat on that describes extensions to the spec
… might be obsolete if the process changes

Harold Solbrig: There’s enough new stuff in 1.1 that it’s sparking new ideas, and the CG might be a good way to incubate these types of changes.

David I. Lehn: I’m pretty sure that people implementing it are happy to put in new features, even if it’s not in 1.1. I’m worried about people starting to use proposed features that don’t survive.

Harold Solbrig: The workaround right now is very minimal. We just added a “prefix” option defaulting to false, but if it’s true allows any term to be used as a prefix.
… The huge cost would be to change the resources themselves.

David I. Lehn: Adding flags might hurt interoperability.
… Even if we don’t do this in 1.1, it would be good to agree on a direction.

Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues

Rob Sanderson: It would be valuable if there were more people than just hsolbrig; if more people could join the CG and we can have a discussion in public.

Harold Solbrig: There are several people raving on email that might join.

Rob Sanderson: One of the easiest ways to justify the new process is to be able to point to a discussion that shows why its important to be able to move quickly to support the community.
… This would be good to convince the AC that we should move to such a process.

Harold Solbrig: These people are interested in learning more about the process. Getting them engaged can help.

Rob Sanderson: I think one of your proponents is at Lawrence Berkeley labs, who are W3C members.

3. Best Practices

Rob Sanderson: https://github.com/w3c/json-ld-bp/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc

Gregg Kellogg: Is there a document for changes in 1.1?

Rob Sanderson: I don’t think there’s a document for what’s new in 1.1, but it would be valuable.

Harold Solbrig: A cheat-sheet would be really useful too. A one page synopsis of things that you can do, and how to do it.

3.1. Streaming

Rob Sanderson: https://github.com/w3c/json-ld-streaming/pull/1

Rob Sanderson: rubensworks has done some work on the Streaming document recently. Where is that?

Rob Sanderson: https://pr-preview.s3.amazonaws.com/rubensworks/json-ld-streaming/pull/1.html

Ruben Taelman: At the moment, the document changes a new “streaming document form” where the order is important.

Gregg Kellogg: .. In 2.3, a new profile is introduced, similar to other profiles for expanded and compacted.

Ruben Taelman: Section 3 describes the best order for receiving triples for a serializer to effectively create a document.

Gregg Kellogg: Section 4 discusses some tactics for processors.

Rob Sanderson: There’s a lot of good stuff in there.

Gregg Kellogg: One comment … should an object always have an @id … what if you don’t see one first?
… if you don’t see one first, then infer it’s a blank node
… my question is if it should always be present, so you’re less subjected to out of order keys
… if it appears in the wrong place, then you would have already emitted the triples
… is it okay if something is wrong to emit the bad data
… don’t think there’s any other key that really has that effect

Ruben Taelman: https://pr-preview.s3.amazonaws.com/rubensworks/json-ld-streaming/pull/1.html#streaming-deserialization

Ruben Taelman: The motivation was to allow streaming processors to buffer, in that case I mention that if a processor detects an out of order key it may through an error.

Rob Sanderson: You note that @type should come before @id where the value indicates a type-scoped context. That seems relevant, but you will already of encountered property-scoped contexts.
… It seems like a valuable observation that we might want to make more obvious.
… I usually see the order @context, @id, @type, but this would be different.
… Is the @type coming before @id important?

Ruben Taelman: I would say it’s important, as it can influence what @id is treated.

David I. Lehn: If you do see @id later, you could output a triple to say that the emitted blank node was equivalent to the @id.

Ruben Taelman: I want to note that the processing is not entirely the same way my implementation works. In my case, if I don’t see @id, it will buffer. But that makes things a bit more complicated.
… If you can do it without buffering the implementation will be simpler.

Harold Solbrig: We make statements about things not being ordered, even though they’re not.

Gregg Kellogg: there’s two effects of ordering – json objects aren’t ordered, but in a serialization they are. So if some processes are to work, such as streaming, then they would need to be
… and secondly lists aren’t ordered (unless @list)
… if the backing store doesn’t preserve order of unordered arrays, then the tests need to be for unordered sets
… reasonable for keeping object properties ordered for this to work
… should decide what to do in this case

Ruben Taelman: Perhaps section 4.1 we can add something about buffering rather than throwing an error.

Action #1: raise issue on exception/buffer in streaming. (Gregg Kellogg)

Rob Sanderson: I’ll be traveling next week, but I think bigbluehat is available, so there should be a meeting next week.


4. Action Items