JSON-LD Working Group Telco — Minutes

Date: 2020-03-13

See also the Agenda and the IRC Log

Attendees

Present: Gregg Kellogg, Rob Sanderson, Ruben Taelman, Benjamin Young, Pierre-Antoine Champin, Ivan Herman, David I. Lehn

Regrets: Dave Longley

Guests:

Chair: Benjamin Young

Scribe(s): Rob Sanderson, Benjamin Young

Content:

1. Announcements / Reminders

1.1. Daylight savings and call times – March 29th next big change

Benjamin Young: https://www.timeanddate.com/time/dst/events.html

Benjamin Young: Daylight savings are back. Only timezone / dates affected is March 20, 27 in Europe. THen back to “normal”

1.2. IANA Registration

Ivan Herman: Small announcement - have the green light from IANA on the registration
… have to put two minor things into the document.
… should be N/A and not None.

Gregg Kellogg: For required parameters and usage
… doing that right now

Ivan Herman: That was the cause of the delay. Our document is the authoritative version, so it’s fair enough
… other news, the two level hierarchical x+ld+json … forwarded a note that says it will be on a future agenda for discussion there. We’ve hopefully started the snowball.

Benjamin Young: Can we track it?

Ivan Herman: Didn’t get anywhere to monitor. I guess they’ll come back with questions.

Gregg Kellogg: Just pushed the change to the draft for the IANA changes and publish date
… the only thing it takes to publish is a fast forward merge and travis does everything else
… there’s a mailing list that a log gets sent to
… when you push to publish, it doesn’t publish what’s on publish, but what’s on master
… but updating that branch kicks off the process

1.3. Summary of recent changes from Gregg

Gregg Kellogg: Couple PRs to API after the CR2 was published for a couple editorial changes
… 12.8.1 was updated. Preview seems to be broken so hard to see actual changes.

Ivan Herman: The generator is broken :(

Benjamin Young: Who runs it?

Ivan Herman: The system team

Gregg Kellogg: Confusion in a variable name, no test changes
… dlehn pushed some typo fixes
… markus updated his affiliation
… I added an expansion test for a scoped remote context
… looking at the python implementation that might not have been caught properly
… someone noted a framing problem, which relates to an issue in the merged node maps algorithm
… had the effect of overwriting values for keywords, but merged for other keys
… framing test added to verify the right behavior
… Issue in compaction where a key that was to be used for property maps was using the wrong element
… still no test changes
… 2 from dlehn. Reordering error code descriptions, and another for context overflow scenarios and adds more tests
… More tests being added at this stage. Need to get final updated reports from implementations to move to PR.

Ivan Herman: That’s what I wanted to ask – where are we with the reports now?

Gregg Kellogg: Need to update mine, but ruby processor is 100% of course

David I. Lehn: i do have a question about syncing expand and toRdf tests. how much should that be done? new ones are usually duplicated, but older tests are not synced at all. should they be? (where appropriate)

Gregg Kellogg: there’s a couple PRs to jsonld.js that cover most tests
… same with python. moving along with pyld for expansion, to and from rdf. And work to do on framing. Expect to wrap up in the next couple of weeks
… will need a little help from the Digital Bazaar folks for those issues
… there is the possibility that there’ll be tests that we only have 1 passing implementation

Ivan Herman: c and c++ implementations?

Gregg Kellogg: Haven’t heard anything yet.
… based on issues people are encountering, in the details of framing and compaction, they’re probably fairly close to conformance

Benjamin Young: Do we know if they’re running tests?

Gregg Kellogg: I think so. There’s an issue that I need to respond to, so they’re testing and finding areas of confusion
… but we don’t know any more than that
… in the past, not sure if groups have solicited input. In this case there’s not many implementers that are part of the group.
… not sure how hard april 3rd date is for getting those reports

Ivan Herman: Will need to check, but charter is until end of june… meaning to be perfect, PR should be early - mid may,

Gregg Kellogg: So April to gather implementation reports
… will need to get in touch

Benjamin Young: Can we use the Community Group for this?

Gregg Kellogg: Seems like a good idea to me
… another issue … some editorial work complete issues where we’re waiting on response
… at some point we need to say no response received

Rob Sanderson: Probably Greg won’t have a chance to sign off by validating the implementation
… can resolve them, with a week to review

Gregg Kellogg: Propose to close API 265, 371 and 357 as commenter no response, unless response by March 20

Ivan Herman: +1

Proposed resolution: planning to close api/265, api/371, api/357 with “no response” unless response by March 20 (Benjamin Young)

Benjamin Young: +1

Rob Sanderson: +1

Ivan Herman: +1

Ruben Taelman: +1

Pierre-Antoine Champin: +1

David I. Lehn: +1

Gregg Kellogg: +1

Resolution #1: planning to close api/265, api/371, api/357 with “no response” unless response by March 20

David I. Lehn: Theres some tests that aren’t synched up with expand and toRDF. Don’t know if we should go back through to sync them up.
… just by running one section you can miss some things

Gregg Kellogg: Ruben is the only one doing toRDF direct without expansion
… degree to which we need to do this could go to Ruben?

David I. Lehn: For manifest to RDF it would be really hard as the names are the same across sections
… duplicates a lot of stuff. might be better to merge common ones?

Gregg Kellogg: Rather not make changes other than add obvious missing tests
… eg issue that Harold came up with

David I. Lehn: The recursive context one isn’t tested anywhere ….

Gregg Kellogg: That’s what we should add.
… adding for completeness sake doesn’t seem like the right time to do that

David I. Lehn: maybe not worth the effort

Gregg Kellogg: Defer to future release?
… so it doesn’t get lost.

Ruben Taelman: I have a small list of features that I didn’t see any tests for when implementing toRDF
… plan to add tests in the coming week or so
… they might already be in expansion, will have a look at that

Benjamin Young: thank you!

Gregg Kellogg: Nothing more on that. There’s 2 issues, the inverses / contexts things, and the ordered errors.

2. Issues

Gregg Kellogg: to talk about api 415 briefly … there’s a response …

2.1. [api] inverse context creation always creates a language map

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

Gregg Kellogg: possible issue on ordering things for inverse context creation
… will need to investigate before we can validate it
… some going back and forth on it
… asked for an example, and he cited compaction test 6 that exercises what he was getting at
… might need to reorder steps
… but could be a misunderstanding

2.2. [api] Order JsonLdErrorCode descriptions

Benjamin Young: https://github.com/w3c/json-ld-api/pull/409

Gregg Kellogg: other is reordering error code. Normally we use <dl> with data-sort attribute that orders them, but this maybe doesn’t use data-sort
… so need to get the text in the HTML to align with the sort order

David I. Lehn: ordering thing is not very exciting :)
… if we use data-sort it will put it in a particular order. And the IDL should be the same order as the -sort
… everything should be ordered the same. Wasn’t sure what to do, and ran out of time on it

Gregg Kellogg: up to the editors for what to do. Doesn’t affect the rendered document at all. Do things exist in the source where you expect them … so a good idea to have in the same order. data-sort corrects for past errors
… if someone wants to do it, that’s great

David I. Lehn: I sorted the values by piping through sort locally
… which put IRI at the top

Gregg Kellogg: Good to just do what the algorithm does

David I. Lehn: Will just make it look right :)

Gregg Kellogg: don’t sort method param lists
… as they’re in the order they’re used in the method definition
… but error codes, enum values don’t order by default
… and need to be done manually, but keeping the enum in the order below makes the most sense
… IRI comes first due to caps
… whereas in data-sort it’s after invalid

David I. Lehn: Which things to not sort?

Gregg Kellogg: in jsonld processor interface, the definitions of the methods, there’s definitions of the three params … those should not be ordered alphabeitcally but in the order they appear in the method definition

David I. Lehn: Right, okay. I’ll work on an update

Gregg Kellogg: Great, need to sign off
… will push syntax today

Benjamin Young: Great, thanks, bye!
… revisit 415?

Rob Sanderson: [crickets]

3. [streaming] Add Streaming RDF Form

Benjamin Young: move on to Streaming

Benjamin Young: https://github.com/w3c/json-ld-streaming/pull/3

Benjamin Young: Streaming PR from Ruben. Could you give us a summary of what’s needed?

Ruben Taelman: This fills in the final todos for the streaming doc. Adds some recommendations for how to sort the triples so they serialize to json-ld efficiently for streaming

Benjamin Young: preview link https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fpr-preview.s3.amazonaws.com%2Fw3c%2Fjson-ld-streaming%2Fpull%2F3%2F7d5a646.html&doc2=https%3A%2F%2Fpr-preview.s3.amazonaws.com%2Frubensworks%2Fjson-ld-streaming%2Fpull%2F3.html

Ruben Taelman: 5 recommendations, and give examples of such ordering, and explain why they’re important
… at the end of the document I give high level suggestion for streaming serializers shouldbe implemented and what things need extra attention
… eg @list keyword is not feasible in a streaming manner as you don’t know beforehand when a list is a valid one
… things like that
… so I think after this PR, the note should be at a first working draft stage
… then will go through everything in more detail for small inconsistencies, but then should be done
… would be good if someone could go through in more detail to see if I made mistakes

Benjamin Young: on the PR?

Ruben Taelman: After the PR

Benjamin Young: Any objections to merging?
… it looks good to me!
… Should go ahead :)
… Will put that one on the agenda for next week too

Ruben Taelman: Sounds good

Pierre-Antoine Champin: Just a question about @list … wouldn’t it be more useful to be ?? about the lists and try to format them as @list and then reject badly formed ones?
… just an idea

Ruben Taelman: I think that’s possible to do. An implementation might decide to do that? I mention there’s difficulties, but don’t say that serializers shouldn’t handle them
… some suggestions, but they can handle any way they want

Benjamin Young: Any thoughts on that?
… …
… 20 minutes left, next is best practices and CBOR
… Lets look at CBOR first

4. CBOR issues https://github.com/w3c/json-ld-cbor/issues

Benjamin Young: viktor is not in the WG, but PA can describe?

Pierre-Antoine Champin: https://github.com/w3c/json-ld-cbor/issues/3

Pierre-Antoine Champin: Not much activity recently. Maybe something that deserves discussion is issue 3 about EXI
… A competitor to CBOR for binary representation of json-like data
… i have mixed feelings
… it would be interesting to have a document for binary json-ld, but this might be too general

Benjamin Young: if we add EXI, it could be an appendix or a separate note. I don’t think we should pick.

David I. Lehn: As far as these alternate formats go, there’s a bunch of them. Can go from JSON to something that look like JSON. Are they real algorithms or just a note that they exist?

Ivan Herman: Try to be realistic, looking at the time. Any chance it will end up as a good note?
… we should be honest with ourselves if it isn’t going to make it
… if the answer is yes we do some sort of extra optimization, that sounds like a lot more work?
… but even just documenting that you can put JSON-LD into YAML … sure, you can … but we need realistic plans.
… Only one that seems to advance is streaming, as Ruben is doing it

Benjamin Young: Agreed
… Maybe we put CBOR into the best practices note, if someone wants to go to the effort
… subsume the other notes into the BP note

Ivan Herman: If the BP note is properly happening and taken care of … which is also a question

Benjamin Young: We have some … could just publish what we have

David I. Lehn: people can always work on these side projects later and write up what they learn. can always put up a json-ld.org page if a note is too much

Benjamin Young: Thoughts on proposal about the CBOR note?

Benjamin Young: note deadlines - within 3 months time

Ivan Herman: Question is to PA, any feeling if Viktor can do it in the coming 3 months… no problem if not, but a pity
… no reason to keep it because it’s a good idea

Benjamin Young: can always go to the CG
… what sort of call do we need to make

Ivan Herman: Use of call time seems to be futile. docs are out there. won’t just close them. CG can take them over. To have it on calls if there’s someone actively defending and working on the document
… don’t see that for CBOR or best practices

Benjamin Young: As much as I’d like to, I can’t spend the time either. Adam is active on issues, but that’s all.
… leave in the category of good idea, and call out to the CG
… no formal action needed
… will leave them where they are

Rob Sanderson: if someone from the CG wants to work on it, can we invite them to the WG as IE?

Benjamin Young: Could do a CG call in this call time

Ivan Herman: If the CG is alive and plans to stay alive after hte WG, with 3 months to go, I could see the CG taking over these things as CG docs
… no reason to publish as WG docs
… so someone for the BPs for 1.1 in the CG would be to not rock the boat and just let them do it

Benjamin Young: Need to breathe new life into the CG over the next 3 months

Ivan Herman: We’re at the point where technically we’re done.
… don’t have time, energy or the right environment to do a good job on something new in 3 months
… so CG should take over, and as soon as we have the reports, and go to final phase

Benjamin Young: That seems like a good approach
… needs activity to route discussions into the CG
… maybe setting up a call

Rob Sanderson: +1

Rob Sanderson: CG chairs agree ;)

Benjamin Young: Rob and Gregg should write to the CG

David I. Lehn: Playground update
… updated the json-ld.js, so new features now work

Ivan Herman: the real one

David I. Lehn: Yep, the real one :)
… you can do some recursive things that cause it to explode … please don’t do that
… playground/dev still exists for playfromg with the new version from early 1.1 days

Benjamin Young: thank you for that work!

5. Resolutions