08:13:26 <RRSAgent> RRSAgent has joined #lws
08:13:30 <RRSAgent> logging to https://www.w3.org/2026/04/28-lws-irc
08:13:31 <Zakim> Zakim has joined #lws
08:13:36 <acoburn> zakim, start meeting
08:13:36 <Zakim> RRSAgent, make logs Public
08:13:38 <Zakim> please title this meeting ("meeting: ..."), acoburn
08:13:58 <acoburn> meeting: Linked Web Storage WG
08:14:07 <acoburn> rrsagent, make minutes
08:14:08 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html acoburn
08:14:56 <acoburn> meeting: LWS WG F2F Meeting 2026 (Day 2)
08:15:02 <acoburn> rrsagent, make minutes
08:15:03 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html acoburn
08:15:44 <acoburn> previous meeting: https://www.w3.org/2026/04/27-lws-minutes.html
08:16:03 <acoburn> next meeting: https://www.w3.org/2026/05/04-lws-minutes.html
08:16:16 <acoburn> present+
08:16:25 <acoburn> agenda?
08:18:30 <acoburn> agenda: https://www.w3.org/events/meetings/10c363c4-c825-4d24-b2cb-bf70af152298/#agenda
08:18:30 <agendabot> acoburn, sorry, I did not recognize any agenda in https://www.w3.org/events/meetings/10c363c4-c825-4d24-b2cb-bf70af152298/#agenda
08:18:42 <acoburn> topic: Notifications
08:18:47 <laurens> present+
08:18:51 <termontwouter> present+
08:18:55 <pchampin> present+
08:18:56 <eBremer> present+
08:19:02 <elf-pavlik> elf-pavlik has joined #lws
08:19:05 <jeremycaine> present+
08:19:07 <ryey> ryey has joined #lws
08:19:10 <elf-pavlik> present+
08:19:22 <eBremer> scribe+
08:19:40 <eBremer> laurens: we wanted to start with test suite, but given presence we will start with notifications
08:19:43 <ryey> present+
08:19:54 <acoburn> acoburn has joined #lws
08:20:04 <eBremer> ... i find the activity on the PR relatively low, i want to understand we we don't have much interaction
08:20:18 <termontwouter> q+ to ask reasons for making notifications part of the core spec
08:20:26 <eBremer> ... are there any concerns we need to address, or everyone feels happy with the state of PR
08:20:42 <laurens> ack termontwouter
08:20:42 <Zakim> termontwouter, you wanted to ask reasons for making notifications part of the core spec
08:20:44 <eBremer> ... which parts we want to elaborate on
08:21:06 <eBremer> termontwouter: why notifications are so imortant to be in this versiuon?
08:21:17 <eBremer> laurens: we have them mentioned in the charter
08:21:28 <eBremer> ... other specs like access requests and grants rely on notifications
08:21:43 <eBremer> ... it would be strange for those to define their own notifications system
08:21:58 <eBremer> ... there is incubate body of work on notifications in Solid, we should address that
08:22:02 <acoburn> q+ to talk about prioritized requirements https://w3c.github.io/lws-ucs/spec/
08:22:07 <elf-pavlik> q+
08:22:32 <eBremer> ... we could just have vote on that, but let's discuss it first
08:22:44 <termontwouter> q+ to clarify concerns
08:22:51 <acoburn> ack acoburn
08:22:51 <Zakim> acoburn, you wanted to talk about prioritized requirements https://w3c.github.io/lws-ucs/spec/
08:23:12 <eBremer> acoburn: we did prioritized list of requirements, notifications were nr 7
08:23:39 <eBremer> ... it was fairly high
08:23:41 <laurens> ack elf-pavlik
08:23:43 <laurens> scribe+
08:23:56 <laurens> elf-pavlik: I added a comment on SSE.
08:24:03 <laurens> ... I also implemented webhooks.
08:24:10 <laurens> ... Those are the two I've implemented
08:24:15 <laurens> ... SSE are a bit problematic.
08:24:27 <laurens> ... You can't take advantage of the regular authn/authz flow in SSE.
08:24:49 <laurens> ... Rahul has an interested approach with the QUERY method.
08:24:55 <laurens> ... Which could be very efficient.
08:25:04 <acoburn> q+ to talk about minimal scope for PR
08:25:07 <laurens> ... Instead of SSE we could consider just streaming HTTP.
08:25:18 <laurens> scribe-
08:25:23 <laurens> q+
08:25:37 <eBremer> acoburn: i would be a big fan for minimal scope for the PR, there are 3 channel types, two sync and one async
08:25:49 <eBremer> ... one option would be to define one sync and one async
08:26:09 <eBremer> laurens: i would say one client server, websockets, sse, streamin http
08:26:16 <eBremer> ... and one server server where webhooks make sense
08:26:40 <eBremer> acoburn: i'm more familiar with webhooks and server sent events
08:27:10 <eBremer> laurens: i like websockets and server sent events that api surface is pretty limited
08:27:21 <eBremer> ... we may need to define more auth flow and protocl
08:27:34 <termontwouter> termontwouter has joined #lws
08:27:43 <pchampin> scribe+
08:27:54 <pchampin> elf-pavlik: we can use the same auth workflow as with GET
08:28:01 <pchampin> scribe-
08:28:14 <eBremer> acoburn: let's say once you subscribe to container and anything contained, the way that model is defined can i get all events,
08:29:53 <pchampin> q+
08:30:43 <eBremer> laurens: i would propose to have couple of votes, i want to know if we keep requirements to resource changes as deliverable
08:31:01 <eBremer> ... we can split pr in two parts, for server to server is see very few alternatives
08:31:14 <eBremer> ... we can have separate vote for server to server webhooks
08:31:23 <eBremer> and revise client to server and have separate vote
08:31:24 <laurens> q?
08:31:30 <acoburn> q-
08:31:50 <laurens> ack termontwouter
08:31:50 <Zakim> termontwouter, you wanted to clarify concerns
08:32:01 <eBremer> elf-pavlik: there is prior work on LDN in Solid CG, I use webhooks for simplicity
08:32:29 <eBremer> termontwouter: ... up til now notifications were about changes on the resource server, yesterday we decided that we want to auth systems out of it
08:32:47 <laurens> ack laurens
08:32:55 <eBremer> ... why should we enforce those authn mechanisms to use the same notification system as resource updates
08:33:16 <eBremer> acoburn: the way i was thinking about, it, server uses some notification mechanism but server could choose what it uses
08:33:35 <eBremer> ... as long as user supplies the inbox the server sends something to the inbox
08:33:58 <eBremer> termontwouter: if we say we can plug in any system using profile and www-authenticate header
08:34:17 <eBremer> ... why would we couple it with notifications via some inbox?
08:34:44 <eBremer> ... server doing oauth and providing custom api, would still need to implement lws specific part
08:35:18 <eBremer> laurens: i need to change access request and grants spec to also profile notifications system, it only uses the inbox part
08:35:25 <eBremer> termontwouter: that would be a good approach
08:35:36 <eBremer> acoburn: some auth parts of the notifications spec may need some revision
08:35:51 <eBremer> ... we can't guarantee delivery, someone could provide wrong inbox
08:36:11 <eBremer> ... that inbox may not require authentication, it may support particilar kinds of authn
08:36:25 <eBremer> ... it may support authn methods that the originating server does support
08:36:43 <eBremer> ... the most we can say is to look at www-authenticate header and negotiate what is supported by both
08:36:50 <eBremer> termontwouter: makes sense
08:37:08 <jeremycaine> q+ to ask about guaranteed notification
08:37:32 <eBremer> acoburn: i wrote about webhook authn being overly specified, if we use http signatures we just need to follow accept-signature response
08:37:54 <eBremer> ... we probably just want to rely on www-authenticate in the end to negotiate
08:38:19 <eBremer> laurens: for me it's fine to just mention the negotiation aspect, should we at least specify something about public key material for the server
08:38:39 <eBremer> laurens: for now is up to implementation
08:38:47 <eBremer> q+ elf-pavlik
08:39:03 <laurens> q?
08:39:18 <eBremer> acoburn: we should also just use self-signed identity authn suite
08:39:31 <laurens> ack pchampin
08:40:24 <eBremer> pchampin: first one is reaction to pavlik, i may be missing something query method is defined as safe and idepodent, i'm not sure if really matters for subscribing to the stream of events, we may need to rely on POST
08:41:16 <laurens> q?
08:41:18 <eBremer> ... reaction to aaron, service description is not CID, i know that I argued against using CIDs, we should consider defining service descripition as extension of CID
08:42:03 <laurens> ack jeremycaine
08:42:03 <Zakim> jeremycaine, you wanted to ask about guaranteed notification
08:42:28 <eBremer> jeremycaine: we can't guarentee delivery of notifications, server will log everything, we can get endpoint on the other end
08:42:38 <laurens> q+
08:42:56 <eBremer> acoburn: it depends on how we define it, we can use outboxes from ActivityPub, you can think of it as container
08:43:16 <eBremer> ... instead of posting a message you can just ping and ask that something fetches it
08:43:41 <eBremer> .... authentication is just lws authentication
08:44:11 <eBremer> laurens: push based vs pull based is interesting, most solid was push based, limited material within solid in pull based
08:44:30 <eBremer> jeremycaine: open telementry is getting a lot of presentce
08:44:48 <eBremer> ... do we need to decide how to implement notifications?
08:45:18 <eBremer> acoburn: we need to define protocol, implementation is out of scope, if we define minimum set of options eg. webhook and streaming fetch, there can be others build on top of that
08:45:30 <acoburn> q?
08:45:38 <pchampin> scribe+
08:45:46 <laurens> ack elf-pavlik
08:46:00 <gibsonf1> gibsonf1 has joined #lws
08:46:06 <gibsonf1> present+
08:46:16 <pchampin> elf-pavlik: about finding keys, in Solid Notification the response to subscription can include "sender"
08:46:22 <pchampin> ... that's how you would discover the key
08:46:24 <laurens> q?
08:46:28 <pchampin> scribe-
08:46:41 <pchampin> s/idepodent/idempodent
08:46:49 <pchampin> s/idempodent/idempotent
08:46:55 <eBremer> laurens: i don't hear much objection to the idea of splitting PR #129 and first addressing server to server
08:46:56 <gb> https://github.com/w3c/lws-protocol/pull/129 -> Pull Request 129 feat(notifications): Introduce the LWS notifications specification as an optional service (by laurensdeb)
08:47:04 <eBremer> ... later introducing client to server PR
08:47:29 <eBremer> ... i hear discussion on push vs pull based, i would be hasitant on introducing a pull based model at this time
08:47:43 <eBremer> ... i don't think it is high priority
08:48:09 <eBremer> laurens: i would want to bind channel to something that is defined
08:48:24 <eBremer> termontwouter: defining general extension point
08:48:59 <eBremer> laurens: i think it is already possible, uri in response could be a pull based source
08:49:27 <laurens> q?
08:49:31 <laurens> ack laurens
08:49:36 <eBremer> elf-pavlik: with light vs fat ping webmention is an example of light one
08:50:13 <eBremer> acoburn: we described 3 defined mechanisms, we want to tweak the text that it is not a closed set
08:50:35 <eBremer> ... i would strike capability urls, if we don't use SSE and websockets even more
08:50:57 <eBremer> ... in discovery we have in PR subscription type and conformsTo, can we align those?
08:51:07 <eBremer> ... envelope we may remove phase
08:51:25 <eBremer> ... activity can be obj or array, we can require array to make parsing easier
08:51:39 <eBremer> ... for access request we use target for subscription topic
08:52:49 <eBremer> acoburn: AS target has a meaning, in subscriptions we used topic, terminology between ODRL and AS doesn't align
08:53:25 <eBremer> laurens: target is used in similar way as an audience in AS, i'm open to suggestions
08:53:29 <laurens> q?
08:53:33 <eBremer> elf-pavlik: we picked topic from WebSub
08:54:45 <acoburn> rrsagent, make minutes
08:54:47 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html acoburn
08:54:53 <laurens> PROPOSAL: To keep subscribing to resource changes (notifications) in scope as a deliverable for the LWS WG.
08:54:53 <pchampin> +1
08:54:53 <termontwouter> +1
08:54:53 <laurens> +1
08:54:53 <jeremycaine> +1
08:54:53 <acoburn> +1
08:54:56 <gibsonf1> +1
08:54:57 <eBremer> +1
08:55:19 <laurens> RESOLVED: To keep subscribing to resource changes (notifications) in scope as a deliverable for the LWS WG.
08:55:44 <acoburn> present+
08:55:50 <laurens> PROPOSAL: To split the PR #129, first defining a server-to-server notifications protocol and subsequently introducing a server-to-client notifications protocol as a separate PR.
08:55:51 <gb> https://github.com/w3c/lws-protocol/pull/129 -> Pull Request 129 feat(notifications): Introduce the LWS notifications specification as an optional service (by laurensdeb)
08:55:54 <laurens> +1
08:55:56 <gibsonf1> +1
08:55:56 <pchampin> +1
08:55:57 <termontwouter> +1
08:55:58 <eBremer> +1
08:56:00 <acoburn> +1
08:56:01 <jeremycaine> +1
08:56:09 <laurens> RESOLVED: To split the PR #129, first defining a server-to-server notifications protocol and subsequently introducing a server-to-client notifications protocol as a separate PR.
08:56:19 <laurens> q?
08:56:23 <eBremer> laurens: with that we can wrap up
08:56:32 <acoburn> acoburn has joined #lws
08:56:50 <eBremer> ACTION: eP to provide details on streaming http
08:56:57 <gb> Cannot create action. Validation failed. Maybe eP is not a valid user for w3c/lws-protocol?
08:57:25 <eBremer>  s/eP/elf-pavlik/
08:57:53 <eBremer> acoburn: i'm more comfortable with idea of resources that can be both container and data resource
08:58:15 <eBremer> gb: excelent, i wish i could be there with you
08:58:18 <acoburn> topic: Terminology
08:58:52 <eBremer> acoburn: last evening we discussed some of the definitions
08:59:21 <eBremer> ... if we define things as capabilities, we can treat resources as mixins rather that fixed identities that can't be anything else
08:59:48 <eBremer> ... if we describe container as resource that is capable of containing things, it doesn't prohibit if of having other capabilities
09:00:04 <termontwouter> q+ to ask about possible conflicts
09:00:18 <eBremer> ... if container has one capability and resource other capabilities, as long as they don't conflict it could have both
09:00:43 <termontwouter> q-
09:00:43 <eBremer> ... we can have a well defined way of doing it
09:01:07 <eBremer> elf-pavlik: in hypermidia there's also term affordances commonly used
09:01:07 <acoburn> topic: Test Suite
09:01:35 <eBremer> laurens: i noticed that you opened a PR with some scaffolding
09:01:41 <termontwouter> scribe+
09:01:42 <laurens> q?
09:01:43 <eBremer> scribe-
09:02:30 <ericP> ericP has joined #lws
09:02:34 <ericP> present+
09:03:38 <elf-pavlik> elf-pavlik has joined #lws
09:03:42 <termontwouter> ericP: I created a PR with a generated scaffolding of a strawman test suite (with underlying JSON-LD) following N3 and SPARQL ones
09:04:21 <termontwouter> ... I tried to capture all behaviors we'd need in these tests, and defined them into traits ('what we are testing')
09:04:47 <jeremycaine> jeremycaine has joined #lws
09:04:53 <jeremycaine> present+
09:05:04 <acoburn> Test suite strawman -> https://raw.githack.com/w3c/lws-protocol/268e3f/lws10-test-suite/manifest.html
09:05:32 <termontwouter> ... The HTML has a source link to the place in the spec, mailing list, minutes etc. where the test came from.
09:05:56 <elf-pavlik> q+ to ask about similarities and differences to Solid conformance-test-harness
09:06:30 <termontwouter> ... Each trait has a request and expected response.
09:08:39 <termontwouter> ... In the code, there is a directory with test resource, one with dummy certificates etc. to manage the needed surrounding data.
09:08:40 <laurens> ack elf-pavlik
09:08:40 <Zakim> elf-pavlik, you wanted to ask about similarities and differences to Solid conformance-test-harness
09:08:41 <acoburn> ack next
09:09:27 <termontwouter> elf-pavlik: Can you compare with the one of Solid?
09:09:36 <jeremycaine> scribe+
09:09:38 <termontwouter> ... Is this just data or also some tests?
09:09:46 <jeremycaine> discussion on test data vs tests
09:10:24 <termontwouter> ericP: There are also tests, based on this scaffolding.
09:10:55 <termontwouter> laurens: We'll need an implementation report listing the cases we want to cover.
09:11:17 <termontwouter> ... And then have a harness executing those.
09:11:37 <jeremycaine> scribe-
09:11:51 <pchampin> present+ samu
09:11:56 <pchampin> q+
09:12:55 <termontwouter> samu: I have no schedule, but here to listen. I can definitely build on this test data, in the context of an NLNet project.
09:13:05 <laurens> ack pchampin
09:13:20 <termontwouter> pchampin: Just clarifying W3C requirements.
09:13:37 <termontwouter> ... The Process requires a number of implementations, and a report documenting those.
09:14:00 <laurens> q+
09:14:03 <termontwouter> ... It does not require a test suite, or define it, but it is a very common approach.
09:14:49 <termontwouter> ... The RDF community has defined a vocabulary to describe tests and manifests, which was used for a number of related specs.
09:14:58 <ericP> q+ to talk about LDP tests
09:15:24 <termontwouter> ... Those specs did merely define the manifest (test data), but no harness, leaving that up to implementers.
09:15:39 <elf-pavlik> q+ to clarify if conformance-test-harness will be used and how it depends on data from specs
09:16:03 <termontwouter> ... Eric might know more about how the SPARQL WG did this.
09:16:48 <termontwouter> ericP: SPARQL and LDP both included protocol validation of servers, but I'm unsure if this was driven by a manifest.
09:17:05 <ericP> q-
09:17:10 <termontwouter> pchampin: There is a manifest for SPARQL protocol, but it looks quite different from the other manifests.
09:17:44 <termontwouter> ... It is okay to have some tests be manual; full automation is nice to have but not a requirement of the W3C.
09:18:20 <termontwouter> samu: I'm familiar with this in SHACL, which has a manifest but not a specific harness.
09:18:47 <termontwouter> ... My plan is to produce an implementation of the protocol as well as an implementation of the tests.
09:19:21 <termontwouter> ... I agree that a harness is not a necessary requirement, but since there is a widely used one we might as well adapt it.
09:19:26 <laurens> q?
09:20:05 <termontwouter> laurens: We mentioned client testing. Do we consider that out of scope, given the lack of strong requirements on that side?
09:20:35 <ericP> q+ to say that the harness becomes worth it when two folks implement their own server tests. that said, we can help them collaborate and not take it as a WG requirement
09:21:06 <termontwouter> ... I would like us to converge on the agreed upon test cases we have, and ideally also some reusable test harness.
09:21:20 <termontwouter> samu: Absolutely
09:22:01 <laurens> ack laurens
09:22:13 <laurens> ack elf-pavlik
09:22:13 <Zakim> elf-pavlik, you wanted to clarify if conformance-test-harness will be used and how it depends on data from specs
09:22:18 <termontwouter> ... I could also build a server that act as a test for clients, but best not drive clients using test-specific requirements.
09:22:38 <termontwouter> elf-pavlik: Is the plan to reuse the existing work on the test suite?
09:23:02 <termontwouter> samu: I'll aim to reuse as much as possible, given the effort that went into it.
09:23:11 <pchampin> q+
09:23:37 <termontwouter> ... I would not impose all requirements of the current harness on you.
09:24:09 <termontwouter> acoburn: The current harness relies a lot on RDFa, which I would avoid (re)using.
09:25:27 <termontwouter> elf-pavlik: Seva, from the User Graph Journey CG, passes RDFa through a script into JSON-LD.
09:25:45 <termontwouter> samu: Does not matter how I get the data, I will indeed transform it before working with it.
09:26:15 <termontwouter> acoburn: RDFa is so niche, and unsupported, I'd rather not rely on it.
09:26:59 <termontwouter> samu: I'd further argue against requiring an implementation of the tests, which is software and has a different life cycle than the spec.
09:27:12 <termontwouter> ... If we do it, think about the continuity of the software.
09:27:37 <termontwouter> acoburn: Case in point, the LDP test suite, which is no longer maintained.
09:28:17 <termontwouter> ... When I was working on LDP, after the WG was over, this was no longer touched. I tried to keep a fork of it up to date, but this is an important difficulty.
09:28:55 <termontwouter> samu: As a counterpoint, I implemented the test suite of SHACL and still report a bug to the WG because it was still going on.
09:29:12 <termontwouter> elf-pavlik: It would still be useable a few years later.
09:29:37 <termontwouter> samu: As a decision maker in production I would not touch something that old.
09:30:42 <termontwouter> elf-pavlik: I'm just arguing that it would make it easier if there is some easy-to-set-up implementation.
09:31:00 <termontwouter> samu: I agree, but it should not be a product of the WG.
09:31:32 <termontwouter> acoburn: This is where the work Eric was showing comes into play. There is not only code, but also a lot of data.
09:32:14 <termontwouter> ... As a WG we can publish this data, that is based on the UCs. Each implementation can then build on top of that.
09:32:46 <pchampin> q?
09:32:49 <termontwouter> samu: I can then take the actual requirements and materialise it into manifests.
09:32:57 <termontwouter> ... What is your timeline?
09:33:32 <termontwouter> laurens: For a CR, this fall, so we hope to get most issues out of the way by then.
09:34:05 <termontwouter> ... While we might already work on a test suite in the meantime, but after that timeframe we'd have a relatively stable spec.
09:34:18 <termontwouter> ... A stable test suite by the end of the year would be ideal.
09:34:34 <termontwouter> samu: and a stable implementation as well?
09:34:53 <termontwouter> pchampin: We first need to the test suite, that is a priority.
09:35:26 <termontwouter> samu: I understand, but to build it I would have to go back and forth with the spec and an implementation.
09:36:02 <laurens> q?
09:36:03 <termontwouter> jeremycaine: Should be put that into the timeline?
09:36:05 <elf-pavlik> elf-pavlik has joined #lws
09:36:05 <laurens> ack ericP
09:36:05 <Zakim> ericP, you wanted to say that the harness becomes worth it when two folks implement their own server tests. that said, we can help them collaborate and not take it as a WG
09:36:08 <Zakim> ... requirement
09:36:13 <jeremycaine> q+ to ask about timeline
09:36:56 <termontwouter> ericP: The implementation if not really our problem, but a question of willingness in the community to maintain it.
09:37:17 <termontwouter> ... As a community project, it also does not have to be perfect / over-engineered.
09:37:48 <termontwouter> ... So there is no reason for it to be the W3C, but there might be a bit more continuity that way.
09:38:19 <elf-pavlik> q+ to mention opportunity of having NLgrant already approved
09:38:24 <termontwouter> ... Is it possible to start elaborate the current Test Suite and add committers / managers to the project ?
09:38:41 <laurens> q+
09:38:42 <termontwouter> pchampin: Yes, we can do that, but we might have a separate repo instead.
09:38:48 <laurens> ack pchampin
09:39:14 <jeremycaine> q-
09:39:33 <termontwouter> ... About the calendar, after CR we start to request test reports, so the suite needs to be present more or less by then.
09:40:01 <termontwouter> ... When we believe the spec is stable enough, there is a lot of hoops to get it published, so then we have time to finalize the suite.
09:40:26 <termontwouter> ... Regarding the maintenance, this is indeed not the job of the WG.
09:41:15 <termontwouter> ... The data part (manifest) could either be maintained by a 'maintenance WG', or by the CG.
09:42:29 <acoburn> acoburn has joined #lws
09:42:30 <termontwouter> ... It would be good to have a clear link between normative statements and tests. ReSpec has some tooling for that. It is not really RDFa, but a custom annotation.
09:43:04 <termontwouter> ... It adds some classes to normative keywords, and an attribute pointing to a test URL, for example in the manifest.
09:43:28 <termontwouter> ... It would be much easier to spot any discrepancy between the spec and the test suite.
09:43:52 <laurens> ack elf-pavlik
09:43:52 <Zakim> elf-pavlik, you wanted to mention opportunity of having NLgrant already approved
09:44:20 <pchampin> https://respec.org/docs/#data-tests
09:44:23 <termontwouter> elf-pavlik: It's good that ODI can finance this work with an NLNet project.
09:45:05 <pchampin> q+ to speak in defense of the W3C process :)
09:45:05 <termontwouter> ... About the Process hoops, I feel it is not a good idea to get most implementation feedback only after reaching CR.
09:45:19 <pchampin> q-
09:45:47 <laurens> ack laurens
09:50:28 <acoburn> rrsagent, make minutes
09:50:30 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html acoburn
10:03:00 <laurens> laurens has joined #lws
10:03:29 <termontwouter> laurens: Let's wrap up the test suite discussion.
10:03:52 <termontwouter> ... Who is going to lead this on the side of the WG and on the side of the implementation feedback?
10:03:59 <elf-pavlik> elf-pavlik has joined #lws
10:04:23 <termontwouter> ... Samu, of course, and I would hope Eric as well. How do we follow up on this?
10:04:55 <termontwouter> ... What parts of the spec do we focus on the first?
10:05:17 <elf-pavlik> q?
10:06:55 <termontwouter> samu: How do you refer to auxiliary specs?
10:07:30 <termontwouter> laurens: There's profiles, and mandatory parts that are separated from the core spec.
10:07:59 <laurens> q?
10:08:08 <termontwouter> samu: This has a bearing on the modularity of the test suite (one vs one per subspec)
10:08:30 <termontwouter> ecirP: The traits should address this partially already.
10:08:52 <termontwouter> ... s/ecirP/ericP
10:09:59 <termontwouter> acoburn: Right now, this is editorially split up into the core spec and some subspecs, but this does not differ much from one spec with mandatory and optional sections.
10:10:31 <termontwouter> ... That said, I'd expect that a test suite picks one authentication method (not SAML)
10:10:51 <termontwouter> samu: I'd have to test all authentication suits.
10:11:44 <termontwouter> acoburn: You don't need to test the SAML setup itself, just use test data in that format to check if it works.
10:11:55 <termontwouter> samu: I would of course start from the core spec.
10:11:58 <elf-pavlik> q+
10:12:03 <termontwouter> laurens: Agreed
10:12:24 <termontwouter> ... Is there a recurring structure for feedback that works best?
10:12:37 <termontwouter> samu: Anything would work. Let's say monthly to start.
10:13:14 <termontwouter> laurens: I'll keep track of that as monthly agenda topic, and reach out one or two weeks in advance each time.
10:13:24 <laurens> ack elf-pavlik
10:14:07 <termontwouter> elf-pavlik: Would it be possible to prioritize some experimental options still under discussion?
10:14:42 <termontwouter> samu: Absolutely, but I'll first need some time to set things up. No need to wait for stability instead of valuable feedback.
10:15:20 <ericP> q+ to mention that folks often clarify proposals and arguments in the form of tests. having those in the test suite (marked appropriately) is useful
10:15:25 <termontwouter> ... It would be nice to first settle on an initial feature set to start with?
10:16:12 <termontwouter> acoburn: Yes, let's start with SSI-CID authentication.
10:16:27 <elf-pavlik> q+ about starting with auth
10:16:55 <elf-pavlik> q+ to ask about starting with auth
10:17:14 <termontwouter> ... In the core specification, we have three different roles. The test suit acts as a relying party, and tests some features of a resource server, and some features of the authorization server. Those two servers are two important components
10:18:01 <termontwouter> ... If you have those, we can test features like the discovery mechanisms, the container representations and operations, and the data resource representations and operations.
10:18:26 <termontwouter> samu: Can we first do this without authentication and authorization? Just the data model and the operations?
10:19:06 <termontwouter> acoburn: We can. We rely on the WWW-Authenticate header, so we can initially focus on public resources.
10:19:11 <laurens> q?
10:19:16 <termontwouter> samu: Happy to aim for that
10:19:43 <termontwouter> ... I think I will start with the server implementation, and not the test suite.
10:20:03 <laurens> ack ericP
10:20:03 <Zakim> ericP, you wanted to mention that folks often clarify proposals and arguments in the form of tests. having those in the test suite (marked appropriately) is useful
10:20:04 <termontwouter> acoburn: Sure, but recognize that the spec is still in flux.
10:21:18 <termontwouter> ericP: People often use tests to clarify proposals or arguments. In SPARQL WG it worked well to put both in the test suite.
10:21:47 <termontwouter> ... I am tempted to let it come naturally what to implement first and what next.
10:21:50 <termontwouter> scribe+
10:22:01 <pchampin> RRSAgent, make minutes
10:22:02 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html pchampin
10:22:15 <elf-pavlik> q-
10:22:34 <laurens> q?
10:23:23 <laurens> topic: Terminology
10:23:37 <pchampin> scribe+
10:24:47 <pchampin> acoburn: yesteday we finished the description of Storage Root. We are at the point of Container.
10:25:05 <pchampin> ... Container, Data Resource and Metadata Resource are probably the most contentious we have left.
10:25:17 <pchampin> ... Conversations happened yestedray in the meeting and after the meeting.
10:25:43 <pchampin> ... One outcome was to describe the resources in terms of "traits", each trait being defined in a given section.
10:26:00 <termontwouter> q+ to talk about clashing operations
10:26:29 <pchampin> ... I have slimmed down the def of Container to 3 things: managed by the storage, able to enumerate a collection of resources, and conforming to "Sec 8 Containers"
10:26:36 <elf-pavlik> q+ to bring up moving resources between containers
10:26:56 <pchampin> termontwouter: this is generally good, but there is a potential clash with other operations
10:27:30 <pchampin> ... it feels that the container is the thing that enumerates; perhaps formulate it has "having a container description"
10:27:55 <pchampin> acoburn: there may be representation of that resource that contain no enumeration at all; as long as it is *able* to enumerate, it is ok
10:28:24 <pchampin> ... there is a long history in Solid and Fedora where if you GET the container, then all the items are there
10:28:41 <pchampin> ... no provision for paging or other things
10:29:40 <pchampin> termontwouter: should we have a container description the same way we have a storage description? as a form of metadata that contains the enumeration
10:30:00 <pchampin> acoburn: I think that's the purpose of the data model that we are currently providing
10:30:20 <pchampin> ... Also, in our spec today, a container supports certain operations (POST to create)
10:30:32 <pchampin> q+
10:30:38 <laurens> q?
10:31:01 <laurens> ack termontwouter
10:31:01 <Zakim> termontwouter, you wanted to talk about clashing operations
10:31:06 <laurens> ack elf-pavlik
10:31:06 <Zakim> elf-pavlik, you wanted to bring up moving resources between containers
10:31:07 <pchampin> ... I would word it as a container needs to support the container representation, and support the POST operation
10:32:01 <pchampin> elf-pavlik: about "managed by a Storage"; we mentioned that it would be nice to be able to move resources from one container to another, by patching the linkset
10:32:28 <jeremycaine> q+ to ask about union intersection of containers
10:32:50 <ryey> q+ to ask about lifecycle of contained resources; also the performance requirement; also the possibility to be vague for multi-containment
10:32:54 <pchampin> [discussion about the wording of "managed by a Linked Web Storage"]
10:35:39 <pchampin> pchampin: is Container not a subclass of LWS Resource? Should this appear in the definition? The "whose lifecycle is managed by a Storage" should probably be moved up in the LWS Resource definition.
10:37:10 <pchampin> laurens: I think the definition should constrain the contained resource's lifecyle to be managed by the same storage as the container
10:37:21 <elf-pavlik> q?
10:37:41 <termontwouter> q+ to react to rui & laurens
10:37:52 <pchampin> ack pchampin
10:38:43 <laurens> q+
10:38:44 <pchampin> ryey: what exactly is managed by the Linked Web Storage? In the past I proposed things like "views", which would not be "managed by the Storage". Is this definition allowing for this?
10:39:04 <pchampin> termontwouter: I think it should be allowed, and should be seen as a resource that *is* managed by the LWS server.
10:39:24 <elf-pavlik> elf-pavlik has joined #lws
10:39:48 <pchampin> ... the binding between a URI in the storage namespace and what it binds to is managed by the server, even if the backend is somewhere else.
10:40:54 <pchampin> ryey: I'm not sure; suppose the software generating a set of resource for LLM usage, which is dynamic. Are those resources really managed by the storage?
10:41:49 <pchampin> acoburn: what I was trying to get at is: assume you have a container storage.example/data/ containing a number of items.
10:42:21 <pchampin> ... data/1, data/2, data/3 ; then there is storage.example/foo/ with a completely different kind of relationship
10:42:38 <pchampin> ... you can have it, but lws:contains would not allow that particular kind of thing
10:42:44 <pchampin> q+
10:43:07 <pchampin> laurens: what is important for clients is that lws:contains has some dependable semantics for it
10:43:38 <laurens> q?
10:43:40 <laurens> q-
10:43:48 <pchampin> ... if some implementation introduces additional semantics, this will be harder for client
10:44:03 <pchampin> ryey: my original question still holds: do we want to support such extensions
10:44:24 <pchampin> s/extensions/extensions?
10:45:24 <pchampin> termontwouter: this could be solved by the capability approach; you could declare additional hierarchy types you support, which would be distinct from lws:contains
10:45:54 <pchampin> ryey: that makes sense; so that allows other kinds of resources to exist?
10:46:15 <pchampin> acoburn: correct; we define several categories, not excluding others
10:47:09 <pchampin> ryey: then the "managed by the storage" should not be moved up to "LWS Resource". Some resources of other categories would not be managed by the storage.
10:47:24 <pchampin> termontwouter: I think that's a different interpretation of "manage"
10:47:40 <pchampin> acoburn: I agree; there is a lot of thing that happens underneeth that's out of scope of LWS.
10:47:40 <laurens> q?
10:47:49 <pchampin> ryey: ok
10:47:52 <laurens> ack next
10:47:53 <Zakim> jeremycaine, you wanted to ask about union intersection of containers
10:48:01 <elf-pavlik> q+ to propose published instead of managed
10:48:24 <pchampin> jeremycaine: let's say there is a data resource, that has a URI that maps to an external system, e.g. banking transaction history
10:48:25 <ryey> q-
10:48:34 <pchampin> ... the Storage may not be allowed to delete this resource
10:49:01 <pchampin> ... when we create a resource, should we be able to tell the storage what it can or cannot do?
10:49:54 <pchampin> acoburn: I don't know that we want to define that. This could be implementation specific?
10:50:18 <pchampin> laurens: should this be managed at the authz layer rather than HTTP?
10:50:31 <pchampin> ... There is nothing preventing you to create a mechanism allowing the creation of read-only resource.
10:50:56 <pchampin> ... I would be careful not to mix HTTP operations with authz concerns.
10:51:40 <pchampin> elf-pavlik: what you can do in Solid, you can create a resource via PUT, then modify the ACL to prevent deletion.
10:51:56 <pchampin> ... I agree that it is related to authz.
10:52:38 <pchampin> acoburn: [shows a part of the Fedora spec: "§3.9 External Binary Content"]
10:53:20 <pchampin> ... the Fedora server is not managing the data in the remote server, but it is managing the resource that is providing access to the external data
10:53:25 <laurens> q?
10:53:43 <pchampin> jeremycaine: I'm assuming that LWS will be linking to external data, adding authn/authz layer
10:53:50 <pchampin> acoburn: there are many ways to implement it
10:54:01 <pchampin> laurens: I see LWS as a protocol layer that you can put on an existing API
10:54:28 <pchampin> ... what I dislike in Fedora is that they make this external link very explicit. This should not be a concern of the client.
10:54:44 <pchampin> jeremycaine: so in the test suite, a valid response to DELETE would be "not allowed"
10:54:47 <laurens> q?
10:54:58 <laurens> ack termontwouter
10:54:58 <Zakim> termontwouter, you wanted to react to rui & laurens
10:54:59 <jeremycaine> q?
10:55:00 <pchampin> acoburn: yes, a server can always refuse what the client is asking
10:55:15 <jeremycaine> q+ to ask about union intersection container
10:55:31 <pchampin> termontwouter: I think we should rephrase it in a way so that it is clear without requiring the whole discussion that we just had
10:55:56 <pchampin> ... I was a fan of the "namespace" / "workspace" ideas :)
10:56:22 <pchampin> acoburn: I used the word "managed" because I saw it in other specifications
10:56:30 <pchampin> ... but I'm opened to use another one
10:56:48 <pchampin> ... The Terminology should be high level. The sections with the normative text can be more precise.
10:57:20 <acoburn> q?
10:57:52 <eBremer> pchampin: +1 on keeping terminology high level, managed may be confusing but the whole text needs to work
10:58:21 <eBremer> ... we focus on lifecycle management, not the content, some resources are proxies managed outside, from the point of the client it is managed by the storage
10:59:02 <eBremer> ... i was concerned about container ???? does it imply read only containers?
10:59:10 <eBremer> acoburn: we need to clarify it in text
10:59:43 <eBremer> ... interesting things has been said on interesting containment hierarchies, it should be considered data resources
11:00:05 <eBremer> ... because something has a hierarchical structures we don't need to schoehorn it as a container
11:00:36 <acoburn> q?
11:00:37 <eBremer> ... does it mean that some resources would be neither container or data resource? i'm open to discussion but we need to clarify things
11:00:42 <acoburn> ack pchampin
11:01:10 <pchampin> s/container ???/how acoburn described containers earlier,
11:01:32 <pchampin> elf-pavlik: the client does not know how LWS resources are stored, only how they are published
11:01:43 <gibsonf1> q+
11:01:52 <pchampin> ... isn't "lifecycle" too focused on implementation?
11:02:08 <pchampin> acoburn: I like "lifecycle" because it relates to the HTTP operations than can be performed
11:02:48 <pchampin> elf-pavlik: how about "it supports the corresponding operations"?
11:03:25 <ryey> +1 to elf-pavlik regarding both the problem words, and the suggested alternative
11:04:09 <jeremycaine> q-
11:04:51 <pchampin> acoburn: I'm trying to balance between a high level definition, and something not too abstract like "it is a thing, see section X"
11:05:38 <acoburn> q?
11:05:47 <acoburn> ack next
11:05:48 <Zakim> elf-pavlik, you wanted to propose published instead of managed
11:05:56 <acoburn> q?
11:06:29 <gibsonf1> q-
11:06:55 <termontwouter> q+
11:07:00 <ryey> q+
11:07:49 <pchampin> acoburn: the current definition is very small ("LWS Resource that conforms with Section X")
11:08:18 <pchampin> termontwouter: so do we need it? does it have any property that a container does not have?
11:08:22 <laurens> q+
11:09:07 <acoburn> ack next
11:09:22 <pchampin> [discussion about whether "content provided by client", vs. read-only data resources]
11:09:58 <pchampin> ryey: back to containers: does the wording about "enumerate" have anything to do with performance requirements?
11:10:06 <pchampin> acoburn: it does not imply anything about performance or paging
11:10:11 <elf-pavlik> q+ to comment that capabilities/ affordances / mixins allow more specific types to be defined
11:10:32 <pchampin> ... it is up to implementation to decide how enumeration happens; we describe it in more details in the corresponding section
11:11:09 <pchampin> ryey: regarding data resources: a container can also be a data resource, as well as metadata resource
11:11:13 <pchampin> gibsonf1: yes!
11:11:13 <acoburn> q?
11:11:17 <acoburn> ack next
11:11:19 <acoburn> ack next
11:11:38 <pchampin> laurens: as I look at LWS, a container is strictly something we have to introduce to because we need a root from which other resources can be discovered
11:11:54 <pchampin> ... people try to assign additional meanings to containers, and this should be allowed
11:12:26 <jeremycaine> q+ to ask containers are not data resource even if a container only contains one data resource
11:12:28 <gibsonf1> q+
11:12:29 <termontwouter> q+
11:12:29 <pchampin> ... but there is also great use in the distinction between having a container that is partly server / partly client managed, and a data resource
11:12:57 <pchampin> q+
11:13:42 <acoburn> ack next
11:13:43 <Zakim> elf-pavlik, you wanted to comment that capabilities/ affordances / mixins allow more specific types to be defined
11:14:07 <pchampin> elf-pavlik: if we think of these in terms of traits / affordances, container is clear
11:14:35 <pchampin> ... then what would be the special affordances of data resources? if they add nothing specific to LWS resource, then so be it.
11:14:53 <pchampin> acoburn: if we find that the concept of Data Resource is the same of LWS Resource, then we should remove one of them
11:15:25 <acoburn> q?
11:15:57 <pchampin> laurens: the PUT should be the distinctive feature of Data Resource
11:16:12 <acoburn> ack next
11:16:13 <Zakim> jeremycaine, you wanted to ask containers are not data resource even if a container only contains one data resource
11:16:17 <pchampin> pchampin: I take back my argument about the "read-only data resource", this would be just a LWS Resource
11:16:42 <acoburn> q?
11:16:56 <pchampin> jeremycaine: I think we should specifically say that a container is not a data resource; a container could have an associated data resource
11:16:59 <pchampin> ... that keeps things simple
11:17:09 <pchampin> acoburn: we don't actually have consensus on that point
11:18:03 <pchampin> ... if we define those categories as sets of capabilities, an implementation could delinerate them as exclusive categories
11:18:17 <pchampin> ... another implementation may allow for resources that have the properties of 2 categories
11:18:40 <pchampin> ... if we could agree on that, it could provide for gibsonf1's use-cases and others'
11:18:42 <acoburn> ack next
11:19:13 <pchampin> gibsonf1: I agree with the idea of merging LWS Resource and Data Resource
11:19:40 <pchampin> ... we have a notion of "intelligent PDF"; you can get it as application/pdf, or as a container that contains pieces of that file, extracted into data
11:20:20 <pchampin> ... the key issue is semantics, which is what Linked Data is about.
11:20:39 <acoburn> ack next
11:20:40 <pchampin> ... If we have LWS not supporting semantics, then what is it?
11:20:49 <pchampin> termontwouter: I would agree
11:21:10 <pchampin> ... laurens, you want containment to be void of any other semantics
11:21:31 <pchampin> laurens: I think the application/lws+json representation of the container should be void of any other semantics
11:21:38 <pchampin> termontwouter: I think we all agree of that
11:22:02 <jeremycaine> q+ to ask I think Fred example is really a feature e.g. get chunks of data of the applicaton/pdf (I suggest an intelligent pd f is a Data Resource)
11:22:02 <acoburn> q?
11:22:08 <pchampin> ... Data Resource is "any LWS resource that is not a container"
11:22:29 <ryey> It doesn't mean Data Resources is not Container Resource. The definition did not say "either this or that".
11:22:32 <pchampin> laurens: we should be thinking a the readers of the spec
11:22:43 <elf-pavlik> q+ to follow up on PUT
11:22:45 <pchampin> ... defining something negatively is confusing
11:23:13 <gibsonf1> q+
11:23:33 <pchampin> ... PUT is defined for Data Resource, and not for Containers
11:23:53 <ericP> q+ to say that devs and users are going to want to know whether they can store data in containers. it fundamentally affects the architecture of anything stacked on top of LWS. if we dance around this, we'll apepar to make progress but we won't enable Frank's clients to run on Aarons's server and visa versa.
11:24:10 <pchampin> termontwouter: if PUT is the defining feature of a Data Resource, that's what the definition should say
11:24:20 <acoburn> q?
11:24:25 <laurens> ack pchampin
11:24:44 <eBremer> pchampin: fred, your inteligent pdf use case, can you put to pdf content?
11:25:06 <eBremer> gibsonf1: if i do a PUT of data to it, if i upload a file to it, it does that, if i add items to the container they get added
11:25:39 <eBremer> pchampin: i would keep the distinction, do we need to say it supports GET? I would say it supports PUT
11:26:06 <eBremer> ... we must provision for containers to contain something that is not data resource or container, it can be managed by external service
11:26:25 <eBremer> ... those would be just LWS resource with no additional behavior specified
11:26:41 <eBremer> ... data resources you can PUT, containers give you something very specific
11:26:58 <eBremer> ... DELETE is i guest on linked storage resource
11:27:16 <eBremer> pchampin: with the trait approach data resources and containers are not specified as exclusive
11:27:17 <acoburn> q+ to talk about capabilities
11:27:33 <eBremer> ... what PUT to a container mean? implementations can define it
11:27:45 <eBremer> .... if you try to PUT container description to modify it
11:27:57 <eBremer> pchampin: i like the idea of traits / mixins
11:28:09 <eBremer> ... read only would be just LWS Resource
11:28:24 <ryey> +1 to pchampin regarding the separation of these definitions; also, Type Index is probably read-only
11:29:37 <elf-pavlik> q-
11:30:54 <pchampin> acoburn: I suggest to add in LWS that it supports GET; to add something to Container about how to add items
11:31:29 <pchampin> pchampin: suggest to word it as "any ability to add items is done like this" / "any ability to modify the content is done like this"
11:32:58 <acoburn> q-
11:33:57 <pchampin> ericP: whether or not you can store arbitrary data is a container is an important part of Solid. If the response is "it depends" there is a problem.
11:34:31 <pchampin> ... gibsonf1 has an implementation that meets his needs. acoburn had issues when dealing with etags.
11:34:39 <elf-pavlik> q+ to check how etags tie to media type
11:35:01 <pchampin> ... we do people a disservice by not telling them precisely how to implement this.
11:35:11 <gibsonf1> q+
11:35:37 <pchampin> ... I would suggest that gibsonf1 and acoburn try to find a common ground, and we put that in the spec.
11:35:42 <laurens> q+
11:36:31 <pchampin> acoburn: problem with conditional request is if you try to modify the enumeration with a PUT
11:36:42 <acoburn> q?
11:36:50 <acoburn> ack ericP
11:36:50 <Zakim> ericP, you wanted to say that devs and users are going to want to know whether they can store data in containers. it fundamentally affects the architecture of anything stacked on
11:36:53 <Zakim> ... top of LWS. if we dance around this, we'll apepar to make progress but we won't enable Frank's clients to run on Aarons's server and visa versa.
11:36:54 <pchampin> ... if the PUT on containers is meant to change other data than the enumeration, then I can see a way forward
11:37:17 <pchampin> jeremycaine: if we were to say that a container is not a data resource, then that goes against what gibsonf1 is talking about
11:37:52 <pchampin> ... what if we say "a container is not a data resource, but a data resource can contain other resources"?
11:38:12 <pchampin> ... you could PUT a markdown file, then access Section 4 of that file as a "contained resource"
11:38:24 <termontwouter> q+
11:38:31 <acoburn> ack next
11:38:32 <Zakim> jeremycaine, you wanted to ask I think Fred example is really a feature e.g. get chunks of data of the applicaton/pdf (I suggest an intelligent pd f is a Data Resource)
11:38:53 <pchampin> Zakim, close queue
11:38:53 <Zakim> ok, pchampin, the speaker queue is closed
11:39:04 <acoburn> ack next
11:39:14 <ericP> q+ to add new things to the queue
11:39:20 <pchampin> gibsonf1: on the ETag issue: the way we do it, every resource has a last-change state.
11:39:52 <pchampin> ... If you change any resource, it changesthe etags all the way up the container hierarchy
11:40:07 <pchampin> acoburn: that addresses one part of the issue, but we can leave that for earlier
11:40:08 <elf-pavlik> to bad ericP
11:40:13 <acoburn> acoburn has joined #lws
11:40:19 <acoburn> q?
11:40:36 <laurens> ack elf-pavlik
11:40:36 <Zakim> elf-pavlik, you wanted to check how etags tie to media type
11:40:45 <pchampin> elf-pavlik: I support ericP's proposal to list the known issues
11:41:00 <laurens> ack laurens
11:41:05 <acoburn> q?
11:41:18 <pchampin> laurens: I like the way that resource operations are specified in the text right now
11:41:27 <pchampin> ... I encourage people to look at it
11:42:09 <laurens> ack termontwouter
11:42:09 <pchampin> ... I don't want them to preclude how people implement them, I would support removing text that precludes that
11:42:37 <pchampin> ... I would strongly oppose any requirement for servers to consider all containers also as data resources
11:42:58 <pchampin> termontwouter: I agree
11:43:09 <pchampin> RRSAgent, make minutes
11:43:10 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html pchampin
11:56:08 <jeremycaine> jeremycaine has joined #lws
12:00:02 <TallTed> TallTed has joined #lws
12:03:32 <TallTed> present+
12:05:21 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html TallTed
12:14:20 <termontwouter> termontwouter has joined #lws
12:20:48 <pchampin> zakim, open queue
12:20:48 <Zakim> ok, pchampin, the speaker queue is open
12:21:00 <eBremer> scribe+
12:21:02 <laurens> laurens has joined #lws
12:21:31 <eBremer> laurens: lets start with easy resolutions
12:21:58 <eBremer> accoburn: I ammended the text for data resource
12:22:08 <eBremer> s/accoburn/acoburn
12:23:00 <eBremer> acoburn: for data resources I added the line "any ability to update or delete an existing data resource follows...
12:24:02 <elf-pavlik> elf-pavlik has joined #lws
12:24:53 <eBremer> laurens: a reason to split up the operations over containers....section 9 is just operations
12:25:32 <eBremer> elf-pavelik: not forbidden to move resources between containers
12:25:44 <eBremer> laurens: would want input from the WG to propose it as a separate PR
12:26:06 <eBremer> acorburn: back to def...the main quality is about describing the cpaabliity of the items
12:26:20 <eBremer> ... if you think of a class hierarchy...
12:26:35 <eBremer> ... an instance of a LWS resource may be a data and container
12:27:20 <laurens> q?
12:27:23 <eBremer> termontwouter: of what a lws server allows is fully up to a particular server
12:27:39 <eBremer> acoburn: i do think we will need to flesh that out.
12:27:51 <eBremer> ... i think there are answer to those questions in a fairly simple manner
12:28:12 <eBremer> acoburn: any objects here?
12:28:27 <gibsonf1> q+ to ask about metadata
12:28:29 <eBremer> s/ objects here/ objections here
12:29:02 <eBremer> acoburn: metadata resource...entirely absent at the moment...lots of prior art
12:29:13 <elf-pavlik> elf-pavlik has joined #lws
12:29:24 <eBremer> ... solid brought that in as an auxiliary resource
12:29:37 <eBremer> ... one: the rep of that resource is text/turtle
12:29:47 <TallTed> "whose lifecycle is bound to the" **LWS**, not Storage "resource it describes"
12:29:58 <eBremer> ... base level requirement.  2nd the life cycle of that is bound to that resource
12:30:23 <eBremer> ... applies to resources that are not self-describing
12:30:26 <TallTed> q+
12:30:33 <termontwouter> q+
12:30:41 <eBremer> ... less useful for self-describing resources like turtle
12:31:00 <acoburn> ack next
12:31:01 <Zakim> gibsonf, you wanted to ask about metadata
12:31:04 <laurens> q+
12:31:24 <eBremer> gibsonf1: you agree, to satisfy req, someone has to make another resource for this
12:31:38 <eBremer> ... there are implementations that dont have to do this
12:31:48 <eBremer> ... in general, everyone is going to be data first
12:31:58 <elf-pavlik> q+ to ask if it can have dedicated content type and or profile
12:32:05 <eBremer> ... having to make another resource doesnt make sense
12:32:17 <pchampin> q+ to respond to gibsonf1 about "resource"
12:32:33 <acoburn> ack pchampin
12:32:33 <Zakim> pchampin, you wanted to respond to gibsonf1 about "resource"
12:32:34 <eBremer> ... if your implementations has limitations, then fine make another resource
12:33:07 <eBremer> pchampin: we should be talking about interface not representation.   the URI provides this
12:33:19 <eBremer> ... that is all I am reading when I read the spec
12:33:35 <eBremer> ... you seem to believe we are constraining things when we are not
12:34:02 <eBremer> ... its an interface problem.  I do not think the spec is not against a data first arch
12:34:06 <acoburn> ack next
12:34:32 <laurens> ack termontwouter
12:34:35 <eBremer> tallted: metadata resource - should be LWS resource at the end
12:34:41 <acoburn> acoburn has joined #lws
12:35:08 <gibsonf1> q+
12:35:08 <eBremer> termontwouter: if you would request a metadata representation from the resource itself
12:35:22 <eBremer> ... that response would include content location to the metadata location
12:36:04 <eBremer> acoburn: additional context - in all of those cases, you have a resource, a link header with a rel=describedby.  thats it
12:36:19 <eBremer> ... that is where you would go to get the representation of that resource
12:36:25 <termontwouter> q+ to ask about conformance reqs
12:36:28 <acoburn> q?
12:36:35 <acoburn> ack laurens
12:36:41 <eBremer> laurens: as I understand, this is something that is referenced from the linkset
12:36:52 <eBremer> ... nothing in spec about the metadata resource
12:37:18 <eBremer> ... linkset is something that contains all of the linkheaders
12:38:30 <eBremer> acoburn: three options.  prior art.  LDP, Fedora (inherits LDP)  and solid which has its own.  what they do for these description resources, the server auto creates this description resource
12:38:35 <eBremer> ... the client does nothing
12:38:52 <eBremer> ... likewise there can be measures to prevent the deletion of that metadata resource
12:39:24 <eBremer> ... opt#1 we do that, continue to do.  what we have been doing for a while.  strict one to one relationship
12:39:24 <gb> Issue 1 not found
12:39:48 <eBremer> ... wanna define a required content type, what is allowed by an allowed header
12:40:21 <eBremer> ... alternative - like option 1, but diff media types that are implementation dependent
12:40:46 <eBremer> ... option 3 - a client is in control of the metadata resources, we've defined mechanism to do that
12:41:03 <eBremer> laurens: not define it, and create metadata resource and add link header
12:41:06 <TallTed> chair: acoburn
12:41:22 <eBremer> acoburn: i dont like option #2 but i thought I would put it in there
12:41:23 <gb> https://github.com/w3c/lws-protocol/issues/2 -> CLOSED Action 2 reach out on Solid-related chat rooms on Gitter (on jacoscaz) due 2024-11-25
12:41:28 <eBremer> laurens: I would go with opt 1
12:42:10 <eBremer> acoburn: what ilike about text/turtle.  very flexible.  best rdf.
12:42:12 <pchampin> q+
12:42:36 <eBremer> ... if we josonld people might be wanting to have arbitrary data, but what does in mean in a json ld frame and interop suffers
12:42:46 <laurens> ack elf-pavlik
12:42:46 <Zakim> elf-pavlik, you wanted to ask if it can have dedicated content type and or profile
12:42:46 <eBremer> ... if we say text/turtle we have high level of interop
12:43:05 <TallTed> q+
12:43:40 <eBremer> elf-pavlik: if we make turtle, you have possibility of composing those resourcews
12:43:49 <eBremer> s/resourcews/resources
12:44:05 <TallTed> q+ to suggest "must be available as text/turtle (optionally as other media types)"
12:44:05 <eBremer> ... each presentation has a diff representation link
12:44:25 <laurens> ack gibsonf
12:44:29 <eBremer> ... some things we can do by collapsing by a single uri, but many diff representations are allowed
12:45:01 <eBremer> gibsonf1: in our case it would all be one resource, it makes no sense to have diff rep
12:45:20 <eBremer> ... we are not having 5 different resources for diff versions
12:45:26 <pchampin> https://www.rfc-editor.org/rfc/rfc9110.html#resources !
12:45:32 <eBremer> elf-pavlik: what requirement says this?
12:46:02 <eBremer> gibsonf1: but you can specify the database
12:46:11 <eBremer> elf-pavlik: lws doesnt so that
12:46:26 <eBremer> ... theres nothing constraining you from doing that
12:46:45 <eBremer> acoburn: weve had this convo a couple of times
12:46:52 <pchampin> q?
12:46:53 <eBremer> ... we are defining URIs for resource
12:47:14 <eBremer> ... an entity that has an uri and you can perform different operations
12:47:24 <eBremer> ... we have certain requirements
12:47:38 <laurens> ack termontwouter
12:47:38 <Zakim> termontwouter, you wanted to ask about conformance reqs
12:47:41 <eBremer> gibsonf1: thats fine but maybe we should clarify that in the spec
12:48:16 <eBremer> termontwouter: the data resource itself can be accessed by another uri.  there is nothing said that they have to be different
12:48:46 <eBremer> ... so the idea that you could have both systems do content neg or various uri, i really like that
12:48:53 <laurens> ack pchampin
12:49:00 <eBremer> ... i wonder if we should make one of them authoratative
12:49:35 <eBremer> pchampin: be clear that wehn we spec a resource, we are specifying a behavior and a interface but not saying how it is implemented
12:49:51 <eBremer> ACTION: pchampin to provide examples for this
12:49:52 <gb> Created -> action #146 https://github.com/w3c/lws-protocol/issues/146
12:50:19 <eBremer> pchampin: im concerned about the overlap, i think it can be confusing
12:50:37 <eBremer> ... only non rdf resources have the aux uri as it would be confusing otherwise
12:51:10 <eBremer> ... i wouldnt fight for reinstating this in LWS
12:51:38 <acoburn> q?
12:51:42 <laurens> ack TallTed
12:51:42 <Zakim> TallTed, you wanted to suggest "must be available as text/turtle (optionally as other media types)"
12:52:04 <eBremer> tallted: suggest, rather than it must be turtle, it must be available as text/turtle
12:52:23 <eBremer> ... so you can store it as oatmeal...as long as client can request turtle
12:52:39 <termontwouter> q+ to propose profile field for metadata format
12:52:56 <laurens> ack termontwouter
12:52:56 <Zakim> termontwouter, you wanted to propose profile field for metadata format
12:53:19 <eBremer> termontwouter: provide alternative profiles that are available for a metadata resource
12:53:31 <eBremer> ... as a server, if it wants to block this just give an array
12:53:56 <acoburn> q?
12:53:58 <pchampin> q+ to propose a crazy idea to solve the LinkSet vs. text/turtle
12:54:43 <eBremer> elf-pavlik: if you have descr resource and non descript resource...you would get the same thing..does the server keep them seperate?
12:54:44 <laurens> ack pchampin
12:54:44 <Zakim> pchampin, you wanted to propose a crazy idea to solve the LinkSet vs. text/turtle
12:54:57 <eBremer> pchampin: dont know where people stand on this
12:55:15 <eBremer> ... the linkset is aux resource in that its lifetime is bound to its main resource
12:55:25 <eBremer> ...would if we merged them
12:55:41 <eBremer> ... the expressiveness is a superset to this
12:55:43 <termontwouter> q+ to point out LinkSets not supporting literals
12:55:47 <acoburn> q+ to talk about the challenges of merging linksets/aux resources
12:55:51 <eBremer> ... i expect this to be part of the link headers
12:56:04 <eBremer> ... we could potentially CN this
12:56:08 <elf-pavlik> q+ to ask if certain links have to point to resources in the same storage
12:56:17 <gibsonf1> +1 on two birds with one stone
12:56:25 <eBremer> ... have turtle in a specific pattern to describe the link headers in turtle
12:56:50 <eBremer> ... there would be constraints of course
12:57:02 <eBremer> ... anything that has an uri would be included in the link headers
12:57:18 <eBremer> ... i appreciate i cannot include arbitrary rdf like blank nodes
12:57:25 <TallTed> I think that merging in that way would demand a lot more from the implementation, and dictate more about how implementation is done.
12:57:36 <laurens> ack termontwouter
12:57:36 <Zakim> termontwouter, you wanted to point out LinkSets not supporting literals
12:57:44 <eBremer> acoburn: turtle is superset of whatyou can express as links
12:57:46 <laurens> ack acoburn
12:57:46 <Zakim> acoburn, you wanted to talk about the challenges of merging linksets/aux resources
12:58:12 <eBremer> ... adv of linksets and producing headers...having both headers and a linkset resource...useful when you have binary content
12:58:23 <eBremer> ... want to see binary resource and the headers in some way
12:58:36 <eBremer> ... or where you can go to get more info about resource
12:58:43 <laurens> q+
12:58:46 <eBremer> ... that def is more expressive
12:58:55 <eBremer> ... you will always have that second jump
12:59:22 <eBremer> pchampin: main added value of linkset is that you can have them appear in the link headers
12:59:33 <laurens> ack elf-pavlik
12:59:33 <Zakim> elf-pavlik, you wanted to ask if certain links have to point to resources in the same storage
12:59:41 <termontwouter> q+ to let the server make that choice
12:59:58 <eBremer> elf-pavlik: understood rdf is options...
13:00:09 <eBremer> s/rdf is options.../rdf is optional
13:00:39 <eBremer> ... for linkset itself, some of the links describedby, probably restrict that they can only point to something in storage
13:00:52 <eBremer> ... this would not be fully server managed
13:01:03 <acoburn> q?
13:01:08 <eBremer> ... that there would be very specific things that you could add
13:01:14 <eBremer> ... there are pros and cons in either
13:01:17 <acoburn> ack next
13:01:27 <eBremer> laurens: one of the reasons I would be concerned with merging
13:01:57 <eBremer> ... you would come into the situation that some resources that are both resource an container and you would end up with the same issues
13:01:59 <elf-pavlik> +1 laurens
13:02:08 <gibsonf1> q+ to ask on server vs user managed data
13:02:16 <eBremer> pchampin: probably not worth it
13:02:30 <laurens> ack termontwouter
13:02:30 <Zakim> termontwouter, you wanted to let the server make that choice
13:02:47 <eBremer> termontwouter: laurens for you the linkset is server managed?
13:02:56 <eBremer> laurens: it is both
13:03:15 <eBremer> termontwouter: what is lcient part?
13:03:38 <eBremer> laurens: add link relations to clarify types of content or profile
13:04:03 <laurens> ack gibsonf
13:04:03 <Zakim> gibsonf, you wanted to ask on server vs user managed data
13:04:03 <eBremer> elf-pavlik: or the parent relation
13:04:26 <eBremer> gibsonf1: are we talking this in the spec specifically?
13:04:35 <termontwouter> s/lcient/client managed
13:05:26 <eBremer> acoburn: with linksets.  enough constraints around the rep.  some server some client.  totally easily to handle
13:05:38 <eBremer> ... one that is def server manage is the linkset resource itself
13:05:54 <eBremer> ... if client could change it, that would be odd and break things in weird ways
13:06:01 <eBremer> ... i would block that
13:06:14 <termontwouter> q+ to propose required linkset but optional metadata resource(s)
13:06:15 <eBremer> ... i would probably allow just about any other operation
13:06:37 <eBremer> ... promote a data resource into being a container resource
13:06:48 <eBremer> ... subject to implementation constraints
13:07:05 <eBremer> ... for the most part, a linkset resource is almost entirely client managed
13:07:07 <acoburn> q?
13:07:34 <pchampin> q+ to propose to define "auxiliary resource" AND "metadata resource"
13:08:18 <eBremer> termontwouter: do we stand in lws the link for optional metadata resources?
13:08:54 <eBremer> acoburn: for me, the hierarchy of preference.  define the linkset resource.
13:09:04 <eBremer> ... and i think we are generally aligned with how that works
13:09:04 <elf-pavlik> q+ to mention lifecycle
13:09:14 <eBremer> ... having more the kind of metadata you can have
13:09:37 <eBremer> ... one could create description resources...
13:09:50 <elf-pavlik> q-
13:10:01 <eBremer> termontwouter: creating the link, make it managed
13:11:04 <eBremer> laurens: we have 20 more minutes
13:11:09 <acoburn> ack next
13:11:09 <Zakim> termontwouter, you wanted to propose required linkset but optional metadata resource(s)
13:11:14 <acoburn> ack next
13:11:15 <Zakim> pchampin, you wanted to propose to define "auxiliary resource" AND "metadata resource"
13:11:21 <eBremer> pchampin: the last discussion moving to option 4 (say nothing)
13:11:56 <eBremer> ... there are other aux resource,m linkset, acl, we do have a variety of aux resources whos lifetime is bounbd
13:12:05 <eBremer> s/bounbd/bound
13:12:29 <elf-pavlik> q+ to suggest advertise container for desc resource
13:12:38 <eBremer> pchampin: interesting notion to have them automatically bound and managed
13:13:05 <eBremer> ... last point, the notion of aux resource could use a defined header to indicate this
13:13:21 <eBremer> laurens: on one hand we have a def issue, defining aux resource.
13:13:54 <eBremer> ... on other hand, what we have currently, clarify separation between linksets and aux metadata
13:14:47 <eBremer> ACTION: termontwouter to clarify the distinction of a linkset being an aux resource and other aux resources and clarify in the terminology
13:14:49 <gb> Created -> action #147 https://github.com/w3c/lws-protocol/issues/147
13:16:06 <eBremer> laurens: gives linkset resource definition
13:16:45 <eBremer> ... they are bound in lifecycle to the primary resource
13:19:40 <gibsonf1> q+
13:19:58 <laurens> q?
13:20:13 <eBremer> acoburn: do we have alignment which options we want to approach with metadata resources
13:21:24 <eBremer> elf-pavlik: mention that in opt 4, if we have the describedby we have the automatic management
13:21:37 <eBremer> ... which would be server specific but contained in that container
13:21:48 <eBremer> ... also in solid, access control applies to it
13:22:05 <eBremer> ... we need to keep all the connected systems
13:22:17 <eBremer> laurens: we need to carefully consider that
13:22:23 <laurens> ack elf-pavlik
13:22:23 <Zakim> elf-pavlik, you wanted to suggest advertise container for desc resource
13:22:57 <eBremer> termontwouter: if we have the metadata resource as a separate branch, we could position it how ever we want
13:22:58 <laurens> ack gibsonf
13:23:00 <laurens> Zakim, close the queue
13:23:00 <Zakim> ok, laurens, the speaker queue is closed
13:23:13 <eBremer> gibsonf1: on term part, if you could switch back to that
13:23:37 <eBremer> ... there is an interesting problem, the aux resource, that they be in a container?
13:23:46 <eBremer> ... why couldn't the belong in a container?
13:24:48 <eBremer> acoburn: last oct, but the key thing here is that there is resource
13:25:14 <eBremer> ... sep from your basic container, contains two diff items.  also has these pointers to metadata resources
13:25:38 <eBremer> ... the metadata resource are not included in the return of container contained resources
13:26:09 <eBremer> gibsonf1: need to include a line that the aux resources cannot be contained
13:27:12 <eBremer> elf-pavlik: do we need to make an exception here
13:27:26 <eBremer> laurens: fair points and they need to be discussed
13:27:58 <eBremer> acoburn: propose - i open a PR with this terminology and we continue to iterate on terminology.
13:28:19 <eBremer> ... just do terminology
13:28:28 <eBremer> ... i will include all of these
13:28:38 <eBremer> ... controller or storage manager?
13:28:43 <gibsonf1> +1 controller
13:29:32 <gibsonf1> controller and storage controller
13:30:15 <eBremer> laurens: people will confuse it that controller doesnt entail any legal value
13:30:26 <eBremer> ... problem is controller is a nice term to use
13:30:45 <eBremer> elf-pavlik: social applications cannot won social data, only social agents can
13:30:52 <eBremer> ... this distinction is useful
13:31:17 <eBremer> laurens: fine with controller but just make the clarification
13:31:38 <gibsonf1> q+
13:32:06 <pchampin> https://www.worddb.com/another-word-for/owner
13:32:30 <eBremer> acoburn: i will use controller....i will use that
13:32:48 <laurens> Zakim, open the queue
13:32:48 <Zakim> ok, laurens, the speaker queue is open
13:32:51 <pchampin> +1 to qualify "controller"
13:32:58 <laurens> topic: Containers
13:33:28 <laurens> https://github.com/w3c/lws-protocol/pull/83
13:33:28 <gb> https://github.com/w3c/lws-protocol/pull/83 -> Pull Request 83 Multiple Containment for LWS Containers (by laurensdeb)
13:33:31 <eBremer> laurens: we can get two easy things out of the way
13:33:59 <termontwouter> q+
13:34:26 <eBremer> ... I'm inclined to close it, currently there's a single container hierarchy, multiple containment weakened that assumption
13:34:53 <eBremer> ... it would allow to have multiple parents, it defines operation to manage containment, parent could be modified
13:35:04 <eBremer> ... that my be desirable property in single containment as well
13:35:21 <eBremer> .. two votes, on to close that PR and second to cherry pick that operation
13:35:30 <pchampin> q+ to suggest a stronger resolution than "close 83"
13:35:40 <eBremer> ... move operations have complicated semantics, for example authoriztion
13:35:50 <laurens> ack termontwouter
13:35:59 <eBremer> termontwouter: i agree to try preserve the move feature
13:36:10 <eBremer> ... i agree that lws should be single parent hierarchy
13:36:40 <eBremer> ... we should publish/display different type of relations that are not lws:contains and still allow hierarchies
13:36:45 <jeremycaine> q+ to ask move data resource from one container to another has implementation impact such a 2PC
13:36:49 <eBremer> q+ elf-pavlik
13:36:55 <acoburn> ack pchampin
13:36:55 <Zakim> pchampin, you wanted to suggest a stronger resolution than "close 83"
13:37:03 <eBremer> pchampin: to suggest how to frame this resolution
13:37:18 <eBremer> laurens: yes we want to define it as out of scope
13:37:36 <laurens> ack jeremycaine
13:37:36 <Zakim> jeremycaine, you wanted to ask move data resource from one container to another has implementation impact such a 2PC
13:38:02 <eBremer> jeremycaine: the concept of moving data resource between containers, sounds good and has implications on implementation
13:38:02 <termontwouter> q+ to talk about authorization
13:38:21 <acoburn> q+ to talk about linkset modification and server constraints
13:38:43 <eBremer> elf-pavlik: no matter that it would be within one storage?
13:38:46 <laurens> ack elf-pavlik
13:38:49 <pchampin> scribe+
13:38:52 <TallTed> ACIDity
13:38:55 <eBremer> jeremycaine: yes since they could be stored in different places
13:39:24 <pchampin> elf-pavlik: +1 to preserving the mechanism for moving, it is a big shortcoming of Solid
13:39:37 <pchampin> ... regarding the impact on permissions: we should consider existing systems
13:39:57 <pchampin> laurens: the issue is: when is someone allowed to move a resource in a different content
13:40:18 <pchampin> elf-pavlik: should be the same as the permission to delete it from one place and create it in a different place
13:40:25 <pchampin> laurens: that needs to be defined
13:40:31 <laurens> q?
13:40:33 <laurens> ack termontwouter
13:40:33 <Zakim> termontwouter, you wanted to talk about authorization
13:40:38 <pchampin> scribe-
13:40:51 <eBremer> termontwouter: i agree that it may not be such a big issue if we define auth etc.
13:40:52 <laurens> ack acoburn
13:40:52 <Zakim> acoburn, you wanted to talk about linkset modification and server constraints
13:41:19 <eBremer> acoburn: i like the idea of patching the linkset to move resources, are we propose to require it or just don't disallow it
13:41:30 <eBremer> laurens: we can have two votes, i would see it as optional
13:42:11 <eBremer> acoburn: i coudl imagine if you have lws with no slash sematics i would imagine it easy, if it is also available in some future specifiation eg. Solid
13:42:25 <eBremer> ... if they require slash semantics, now we get bizzare behavior if we require it
13:42:46 <laurens> PROPOSAL: To keep multiple containment out of scope for the LWS v1.0 protocol.
13:42:46 <eBremer> ... we shouldn't require it if it stops adoption
13:42:50 <gibsonf1> +1
13:42:51 <termontwouter> +1
13:42:52 <pchampin> +1
13:42:52 <laurens> +1
13:42:53 <jeremycaine> +1
13:42:54 <eBremer> +1
13:42:54 <acoburn> +1
13:43:05 <ryey> +0.5
13:43:05 <TallTed> +0.5
13:43:29 <laurens> RESOLVED: To keep multiple containment out of scope for the LWS v1.0 protocol.
13:44:11 <laurens> PROPOSAL: To extract an OPTIONAL mechanism for updating the parent container in place as part of the container operations in LWS, by updating the resource linkset.
13:44:16 <gibsonf1> +1
13:44:17 <eBremer> q+ elf-pavlik to ask about discovery of this capability
13:44:17 <ryey> clarification: acceptable for time / deliverable constraints; hope still to explore possibilities after reaching 1.0
13:44:23 <eBremer> +1
13:44:24 <termontwouter> +1
13:44:24 <laurens> +1
13:44:26 <pchampin> +1
13:44:40 <acoburn> +1
13:44:44 <jeremycaine> +1
13:44:51 <pchampin> s/extract/extract from PR83
13:45:00 <ryey> +0.9 (+1 for supporting; 0.1 for optional)
13:45:26 <laurens> RESOLVED: To extract from PR83 an OPTIONAL mechanism for updating the parent container in place as part of the container operations in LWS, by updating the resource linkset.
13:46:19 <eBremer> ACTION: laurens to make PR extracting move of resources between containers
13:46:21 <gb> Created -> action #148 https://github.com/w3c/lws-protocol/issues/148
13:48:10 <TallTed> *** 15 minute break -- resume at top of the hour ***
13:56:36 <acoburn> acoburn has joined #lws
13:58:37 <acoburn> acoburn has joined #lws
14:00:29 <elf-pavlik> elf-pavlik has joined #lws
14:00:56 <eBremer> laurens: i have 11 container related issues, let's start with easy ones
14:03:33 <eBremer> ... #135
14:03:34 <gb> https://github.com/w3c/lws-protocol/issues/135 -> Issue 135 Reconsider Strict Tree layout (by damooo)
14:04:07 <eBremer> ... i propose to close it, starting with label and closing in 7 days, do we need a vote
14:04:31 <eBremer> acoburn: lazy consensus, if opose please speak up
14:04:46 <eBremer> s/opose/oppose/
14:05:18 <eBremer> laurens: issue #137
14:05:19 <TallTed> s/oppose please/opposed, please/
14:05:19 <laurens> laurens has joined #lws
14:05:20 <gb> https://github.com/w3c/lws-protocol/issues/137 -> Issue 137 Storage itself to behave as a Container (by gibsonf1)
14:05:22 <laurens> present+
14:05:24 <laurens> q?
14:05:44 <eBremer> gibsonf1: proposing to close
14:06:02 <eBremer> laurens: #90
14:06:06 <gb> https://github.com/w3c/lws-protocol/issues/90 -> Issue 90 Distinguish between Container and Data Resources in the metadata (by laurensdeb) [ready-for-pr]
14:06:26 <eBremer> ... it was raised by ben in PR ????
14:06:44 <acoburn> q+
14:06:49 <eBremer> ... we had discussions that go in direction of capabilities
14:06:59 <laurens> ack elf-pavlik
14:06:59 <Zakim> elf-pavlik, you wanted to ask about discovery of this capability
14:07:00 <laurens> ack acoburn
14:07:04 <termontwouter> q+
14:07:39 <eBremer> acoburn: not to revisit, i think that it is something that LDP does and nice to do, if resource acts as container it should include link header to advertise it
14:07:43 <gibsonf1> +1
14:07:48 <eBremer> ... this does not prevent resource claiming to be both
14:07:50 <termontwouter> q-
14:07:53 <termontwouter> +1
14:07:58 <eBremer> laurens: do we already have all needed link headers
14:08:07 <eBremer> acoburn: i think but I don't remember
14:08:19 <eBremer> laurens: i will assign it to myself
14:08:45 <laurens> q?
14:09:02 <eBremer> laurens: #114
14:09:04 <gb> https://github.com/w3c/lws-protocol/issues/114 -> Issue 114 TotalItems: count MUST be exact: propose to SHOULD (by bjdmeest)
14:09:19 <eBremer> ... there is a proposed change, looking for volunteer to open it
14:09:25 <eBremer> eBremer: i can do it
14:09:57 <eBremer> laurens: i want to discuss notion of deletion on containers and recursive nature
14:10:20 <laurens> https://w3c.github.io/lws-protocol/lws10-core/#delete-resource
14:11:00 <eBremer> ... lws says delete can be recursive, it doesn't really specify anything more than that, it specifies recursion depth eg. invinity
14:11:15 <eBremer> ... default is with reject with 409 unless header is present
14:11:24 <eBremer> eBremer: it's from WebDAV
14:11:37 <eBremer> laurens: is it sufficiently addressing #88 ?
14:11:41 <gb> https://github.com/w3c/lws-protocol/issues/88 -> Issue 88 Containers: specify behavior on deleting non-empty containers (by bjdmeest) [ready-for-pr]
14:11:44 <pchampin> q+
14:12:02 <eBremer> laurens: it seems addressed
14:12:04 <laurens> ack pchampin
14:12:28 <eBremer> pchampin: i was wondering if we covered the case if i don't have authorization to delete everything under?
14:12:45 <eBremer> laurens: if client lacks auth server must return 401, it doesn't define it being atomic
14:13:03 <eBremer> pchampin: it is dangerous to leave it unspecified, but it makes it more complicated
14:13:29 <eBremer> acoburn: it has been described in WebDAV with whole locking model, we could refer to it without bringing it in
14:13:35 <eBremer> laurens: is it separate issue?
14:13:58 <eBremer> acoburn: i would leave text as it is, it is worthwhile to add some notes
14:14:44 <eBremer> laurens: there is specified interface, we may need to do some cleanup, i will response to this issue suggesting to look at what is currently in the text
14:15:11 <eBremer> laurens: let's go till :30 past
14:15:46 <eBremer> ... #69 has combination of recursive deletion and virtual resources
14:15:47 <gb> https://github.com/w3c/lws-protocol/issues/69 -> Issue 69 (Recursive) resource/container deletion and virtual resources (by renyuneyun) [needs-discussion]
14:16:09 <eBremer> laurens: i would like to make decision on it, in some cases it is relevant, do we have time to specify it given our other concerns
14:16:10 <termontwouter> q+
14:16:23 <eBremer> ... will anyone take it up? i can't do anything more at this moment
14:16:24 <acoburn> q+ to talk about related work
14:16:34 <laurens> ack termontwouter
14:16:40 <jeremycaine> q+ to ask about virtual resources
14:16:52 <eBremer> termontwouter: i agree with the last comment of pchampin, that it shouldn't be something that we define
14:16:56 <pchampin> q+
14:17:04 <laurens> ack acoburn
14:17:04 <Zakim> acoburn, you wanted to talk about related work
14:17:18 <ryey> yes, I am
14:17:23 <eBremer> acoburn: Inrupt has done some related work, we keep it out of Solid hierarchy
14:17:47 <eBremer> laurens: it would be helpful to say that container contains data resources or containers but no other types
14:18:16 <eBremer> q+ elf-pavlik to ask about proposed restriction
14:18:51 <termontwouter> q+
14:18:55 <eBremer> acoburn: imagine you have one or more resources, and you want to do some interesting transformation into composed resource
14:19:07 <eBremer> ... think of it as a function
14:19:10 <laurens> ack jeremycaine
14:19:10 <Zakim> jeremycaine, you wanted to ask about virtual resources
14:19:23 <eBremer> jeremycaine: you have data resource, with uri pointing to something
14:19:40 <eBremer> ... it could point to URL which is pointing to something
14:20:01 <eBremer> jeremycaine: data resource can point to anything
14:20:21 <eBremer> laurens: there is no defined notion of virtual resource
14:20:28 <ryey> q+
14:20:55 <eBremer> ... could be anything, it could be managed by storage
14:20:59 <laurens> ack ryey
14:21:21 <eBremer> ryey: i agree that is lack of definition of virtual resource, hard to decide what to do with this issue
14:21:42 <eBremer> ... i generally agree with what virtual resource imply
14:22:43 <eBremer> ... it may be possible to ???? the only problem is that the type of this resource would not be container and client would not know if it can fetch contains predicates
14:22:43 <laurens> ack pchampin
14:22:43 <laurens> q+
14:23:08 <eBremer> pchampin: we are conflating two things, we shouldn't define virtual resources, i would consider specific problem
14:23:37 <eBremer> ... it says about client lacking authorization, if client is not allowed or can't delete resource it would be 403
14:23:58 <eBremer> ... I probably can't PUT or delete, it would be another reason to prevent recursive deletion
14:24:12 <eBremer> ... as soon as I can't delete something the recursive deletion fails
14:24:22 <acoburn> q?
14:24:38 <eBremer> ACTION: laurens: to change terminology to extend from the not allowed on virtual resources
14:24:40 <gb> Created -> action #149 https://github.com/w3c/lws-protocol/issues/149
14:24:41 <pchampin> scribe+
14:24:43 <laurens> ack elf-pavlik
14:24:43 <Zakim> elf-pavlik, you wanted to ask about proposed restriction
14:25:06 <pchampin> elf-pavlik: about restricting containers to only contain Data Resources or Container, it might prevent some affordances
14:25:18 <laurens> ack termontwouter
14:25:34 <pchampin> ... I would rather explicitly define that a particular kind of resources CAN NOT be in a container, than say a container can ONLY contain this and that
14:25:49 <eBremer> termontwouter: i agree that we shouldn't use this issue to define it, you don't write representation of the resource but the transformation
14:25:53 <pchampin> scribe-
14:25:59 <eBremer> ... it is an interesting notion
14:26:32 <eBremer> laurens: i would like to unassign myself, we either open separate issue to first introduce virtual resources, we close until that time and reopen as needed
14:27:01 <eBremer> acoburn: can i recommend that before we close we say "deletion works just as currently define"
14:27:38 <eBremer> action: ryey to open issue that defines virtual resources
14:27:39 <gb> Cannot create action. Validation failed. Maybe ryey is not a valid user for w3c/lws-protocol?
14:27:55 <eBremer> laurens: we have 4 more issues i'd like to discuss, most of them are by gibsonf1
14:28:10 <eBremer> ... please go through them and check if still relevant
14:28:26 <eBremer> ... we will still be discussing combination of data resource and contaienr
14:28:34 <eBremer> ... #177
14:28:35 <gb> Issue 177 not found
14:28:45 <eBremer> laurens: is this going to be solved by terminology
14:28:47 <laurens> q?
14:28:50 <laurens> ack laurens
14:29:12 <eBremer> acoburn: there is side component, depending if storage description a CID
14:29:30 <laurens> q?
14:29:51 <acoburn> scribe+
14:30:11 <acoburn> acoburn has joined #lws
14:30:21 <acoburn> topic: Type Indexes
14:30:30 <acoburn> rrsagent, make minutes
14:30:31 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html acoburn
14:31:02 <acoburn> eBremer: features: allow listing of types in a system and where they are located
14:31:07 <elf-pavlik> elf-pavlik has joined #lws
14:31:24 <acoburn> ... one endpoint gives a list of types, subject to action control
14:31:36 <elf-pavlik> q+ to ask about relationships to shapes
14:31:47 <acoburn> ... another endpoint/service to ask for locations for selected type(s)
14:31:57 <pchampin> q+ to ask about the reuse of "items"
14:32:02 <acoburn> ... type index API gives list of types registered in system
14:32:06 <termontwouter> q+ to ask where authz info comes from
14:32:46 <acoburn> ... type index search: A client sends a list of types and retrieves locations for resources with those types
14:33:00 <pchampin> q-
14:33:01 <laurens> ack elf-pavlik
14:33:01 <gibsonf1> q+
14:33:01 <Zakim> elf-pavlik, you wanted to ask about relationships to shapes
14:33:02 <acoburn> ... min requirement is to index Link header types
14:33:14 <acoburn> elf-pavlik: good starting point, would support merging it
14:33:29 <acoburn> ... this is an improvement over Solid type index
14:33:48 <acoburn> ... ODI is working shapes. There should be a clean way to connect to shapes
14:34:04 <termontwouter> +1 to shape integration
14:34:06 <laurens> q+ to propose allowing indexing over link relations (in addition to type)
14:34:07 <acoburn> ... no clear proposal for connection to shapes ATM
14:34:16 <laurens> ack termontwouter
14:34:16 <Zakim> termontwouter, you wanted to ask where authz info comes from
14:34:33 <jeswr> jeswr has joined #lws
14:34:34 <pchampin> q+
14:34:39 <jeswr> q+
14:34:47 <acoburn> termontwouter: design is good overall. The results depend on which types a client can access
14:35:10 <laurens> ack gibsonf1
14:35:13 <laurens> ack gibsonf
14:35:23 <acoburn> eBremer: it needs to have some connection to the access control layer
14:35:26 <jeswr> present+
14:35:31 <elf-pavlik> q+ to mention SAI using grants for discovery
14:36:17 <laurens> ack laurens
14:36:18 <pchampin> q-
14:36:18 <Zakim> laurens, you wanted to propose allowing indexing over link relations (in addition to type)
14:36:20 <acoburn> gibsonf1: an optional mechanism of supplying a (partial) text string (e.g. autofill) would be helpful
14:36:44 <acoburn> laurens: I like this approach. Could we also index other relations in the linkset?
14:36:55 <pchampin> q+
14:37:00 <acoburn> q+ to ask about location properties
14:37:19 <termontwouter> +1 for integration of other relations
14:37:20 <acoburn> eBremer: that was part of the original proposal, but was trimmed down
14:37:29 <laurens> ack jeswr
14:38:09 <acoburn> jeswr: does it make sense to have the interface for this be SPARQL?
14:38:23 <acoburn> pchampin: do you mean a very specific profile of SPARQL?
14:39:00 <acoburn> laurens: I would try to avoid a partial support for SPARQL
14:39:15 <acoburn> pchampin: a subset of SPARQL would be brittle
14:39:42 <acoburn> laurens: converting linksets to RDF would be necessary as a first step
14:40:10 <acoburn> ... nothing prevents a server from supporting other query endpoints
14:40:43 <gibsonf1> q+ to ask about search results
14:40:46 <acoburn> eBremer: we could add other linkset headers, which would start to look like a JSON-LD frame
14:41:29 <laurens> ack elf-pavlik
14:41:29 <Zakim> elf-pavlik, you wanted to mention SAI using grants for discovery
14:42:03 <acoburn> elf-pavlik: from SAI, access grants are used for discovery. Follow your nose from there
14:42:05 <laurens> ack pchampin
14:42:13 <acoburn> ... no separate type index service
14:42:50 <acoburn> pchampin: example 11 (response from type index service) look like a container representation
14:43:02 <acoburn> ... like a container with a list of unnamed types
14:43:48 <acoburn> ... example 15 (query for person or container)
14:44:07 <termontwouter> q+ to point out pchampin made my case for container-like collections with other relations
14:44:22 <acoburn> ... does this mean the container has a link header with type Person or that they contain things the contain Person
14:44:37 <acoburn> ... that makes the type relation ambiguous
14:45:39 <acoburn> ... reusing the container format makes sense, yet it is very different from containers. A bit uncomfortable for that reason
14:46:00 <acoburn> termontwouter: I like the fact that we reuse the same mediatype
14:46:13 <acoburn> laurens: I also like the reuse of the media type
14:46:44 <acoburn> eBremer: are there concerns about using different JSON-LD frames?
14:47:09 <acoburn> ... allowing this provides a lot of flexibility
14:47:51 <acoburn> ... based on the spec, I would need to create the frame first (client specified)
14:48:26 <laurens> ack acoburn
14:48:27 <Zakim> acoburn, you wanted to ask about location properties
14:48:27 <acoburn> ... would allow client to shape the metadata response.
14:48:45 <eBremer> acoburn: indexes were just added to solidproject.org/TR
14:48:57 <eBremer> ... they use two different properties, instance and instancecontainer
14:49:15 <eBremer> ... instance indicates resources of that type and instance container containers that contain resources of that type
14:49:34 <eBremer> ... they are two different types of queries, we seem to conflate the two and can we pull them appart
14:49:58 <eBremer> ... i want container that includes foaf:Person vs. all instances of foaf:Person resources
14:50:07 <eBremer> eBremer: you can request that you only have containers
14:50:35 <eBremer> acoburn: if you say container, i would think any container and the container itself has type foaf:Person
14:50:45 <eBremer> q+ elf-pavlik to suggest constraintedBy
14:50:55 <eBremer> eBremer: i want to know the key areas for it
14:51:27 <eBremer> ...  i could ask for foaf:Person and container it would return nothing
14:51:47 <eBremer> termontwouter: can we ???? and if it doesn't do that we get a list of items
14:51:59 <eBremer> acoburn: i think they are two different sets of questions
14:52:18 <eBremer> eBremer: if it makes it clearer we can do that
14:53:11 <termontwouter> s/can we ???? and if/can we let the server return a 'container' array and if
14:53:20 <eBremer> acoburn: on possible suggestion, where you say type=if you said instance=and the instance container being the container
14:54:03 <eBremer> ... typecontainer=schema:Person could give all containers that have instances of type person
14:54:07 <laurens> ack gibsonf
14:54:08 <Zakim> gibsonf, you wanted to ask about search results
14:54:29 <acoburn> gibsonf: this is something that graphmetrix has been working on
14:54:41 <acoburn> ... a container can be type:Person
14:54:42 <eBremer> gibsonf1: graphmetix was working on something we call ???? container can be a person, you can do a search on type person and get top level container is fine
14:55:03 <acoburn> ... in terms of instance, when you do a type search you are searching for instances
14:55:14 <eBremer> ... things can have many types, we have often 30 types on something
14:55:22 <acoburn> ... in terms of looking inside the hierarchy structure, the hierarchy can be quite deep
14:55:33 <eBremer> ... you may want to scope your search inside of some structure
14:55:45 <eBremer> ... for example inside of hierarchy look for something
14:55:45 <acoburn> ... often you might want to scope the query to a particular hierchy using an "in" operator
14:56:03 <eBremer> ... eg. give me all the carborators on specific car not all cars
14:56:04 <acoburn> ... e.g. give me all carbeurators in *this* car, rather than in all cars
14:56:41 <laurens> q?
14:56:42 <termontwouter> q-
14:56:49 <laurens> ack elf-pavlik
14:56:49 <Zakim> elf-pavlik, you wanted to suggest constraintedBy
14:56:50 <acoburn> acoburn: sounds like a nice feature
14:57:19 <acoburn> elf-pavlik: in terms of indexing over link relations, there is a CSS feature to perform this type of query
14:57:53 <gibsonf1> q+
14:57:56 <acoburn> ... we don't always want to query for containers that already contain resources of a certain type
14:58:07 <laurens> q?
14:58:11 <laurens> ack gibsonf
14:58:16 <acoburn> ... e.g. an empty container where we *want* to store future instances of type X
14:58:51 <acoburn> gibsonf1: you can use types to indicate that a container is for particular types
14:59:21 <acoburn> ... you wouldn't call a container type=Person for a container where you want to store Person types
14:59:30 <laurens> q?
14:59:36 <acoburn> ... but you might have a type of PersonCollection for the container
14:59:56 <acoburn> laurens: how do we move this along? Was the input helpful?
15:00:16 <acoburn> eBremer: I can take this feedback into the proposal and update
15:00:37 <laurens> https://docs.google.com/spreadsheets/d/1wiAg8UtF0i73bdMD3TBhC9nFdYLYkobBCbCGSF6XXn0/edit?gid=0#gid=0
15:00:50 <acoburn> laurens: we have a google sheet for people to sign up for working on features/deliverables
15:01:09 <acoburn> ... grouped into epics / editorial
15:11:20 <jeremycaine> scribe+
15:11:20 <laurens> topic: Administrative tasks
15:11:27 <acoburn> rrsagent, make minutes
15:11:28 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html acoburn
15:12:06 <jeremycaine> pchampin w3c process akidna - using for use case docs, but need reoslution for new deliverables
15:12:17 <jeremycaine> ... we need to agree to use akidna for all new docs
15:12:24 <acoburn> s/pchampin w3c/pchampin: w3c/
15:12:32 <acoburn> rrsagent, make minutes
15:12:33 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html acoburn
15:12:54 <pchampin> PROPOSAL: the working group decides to use Echidna to publish all present and future TR/ specifications
15:13:04 <termontwouter> +1
15:13:04 <pchampin> +1
15:13:07 <laurens> +1
15:13:08 <acoburn> +1
15:13:09 <jeremycaine> +1
15:13:54 <eBremer> +1
15:14:07 <pchampin> RESOLVED: the working group decides to use Echidna to publish all present and future TR/ specifications
15:14:46 <jeremycaine> laurens would like to wrap up and set out roadmap for next months
15:15:10 <jeremycaine> ... need to resolve identity, so put in the project task tracking
15:15:26 <jeremycaine> ... i.e dedicate some time at a next WG meeting
15:15:43 <jeremycaine> ...this week meeting:
15:16:17 <jeremycaine> ... is there anything we need to look at re: notifications for Access Requests
15:17:29 <elf-pavlik> elf-pavlik has joined #lws
15:18:03 <jeremycaine> ... wrt Notifications - couple of points in the task tracking: splitting; client to server; and remove certain things
15:19:02 <jeremycaine> acoburn issue notion of service description as a SID #117
15:19:03 <gb> https://github.com/w3c/lws-protocol/issues/117 -> Issue 117 Clarifications around containers and roots (by kaefer3000)
15:19:27 <jeremycaine> ... wrt Storage Description - we didnt dicuss capabilties
15:19:42 <jeremycaine> s/dicuss/discuss
15:20:24 <jeremycaine> ... general consensus to keep 'capabilities'
15:20:57 <jeremycaine> ... Aux Resources - need to distangle current text, linked sets etc - one other thing is clarify
15:21:19 <jeremycaine> ... do we need to define a Metadate Resource as an additional aux res
15:21:28 <jeremycaine> ... it would be extra scope
15:21:39 <laurens> q?
15:22:57 <jeremycaine> ... add system diagrams and pictures of containers etc
15:24:00 <jeremycaine> ... editorial: terminology
15:24:50 <jeremycaine> ... create a new issue for editorial re: former editors section
15:25:10 <jeremycaine> acoburn need to add an introduction to the spec
15:26:06 <acoburn> s/laurens would like/laurens: would like/
15:26:07 <jeremycaine> jeremycaine: would be happy to write the introduction
15:26:17 <acoburn> acoburn has joined #lws
15:26:42 <jeremycaine> acoburn: would like to clarify the connection to OAuth 2.0
15:27:18 <jeremycaine> acoburn: sort out Section 8 and 8.1
15:27:44 <jeremycaine> acoburn: section 9 normative stmt
15:28:33 <jeremycaine> acoburn: section 10 lws media type, content negotiation ... reword - two media types are equivalent
15:29:45 <jeremycaine> acoburn: pagination is in Section 10; move to a separate section Pagination
15:31:02 <jeremycaine> s/laurens would/laurens: would
15:31:41 <jeremycaine> acoburn: better define container parent, semantics of delete, move
15:31:52 <gibsonf1> q+
15:31:59 <laurens> ack gibsonf
15:34:26 <jeremycaine> @laurens: wrt TypeIndexs - Eric will follow-up and update proposal
15:35:01 <gibsonf1> q+
15:35:29 <acoburn> q+ to talk about did:key authN suite
15:36:12 <laurens> ack gibsonf
15:36:17 <laurens> ack acoburn
15:36:17 <Zakim> acoburn, you wanted to talk about did:key authN suite
15:36:29 <jeremycaine> gibsonf1: Acces Grants and Type Indexes clarification
15:36:53 <jeremycaine> acoburn: would like to followup on merging identity issues
15:37:20 <jeremycaine> s/merging identity/merging authentication
15:37:46 <pchampin> q?
15:38:12 <jeremycaine> ... do we need section 11 json-ld
15:39:54 <jeremycaine> ... other specs do not write out full json-ld doc
15:40:24 <jeremycaine> ... section 13 not sure we need a section for unstable features
15:43:55 <jeremycaine> acoburn: where to publish ? to github pages (it does JSON-LD)
15:45:11 <jeremycaine> laurens: elf-pavlik can help with test harness and pchampin with test data
15:49:00 <jeremycaine> ... will make gh issues from the google sheet tracker
15:49:12 <jeremycaine> ... next Mon - holding a WG meeting?
15:49:29 <jeremycaine> consensus is to have the planned meeting
15:49:52 <jeremycaine> and confirm follow-up actions etc
15:50:24 <laurens> q?
15:50:54 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html TallTed
15:51:24 <jeremycaine> laurens: propose to close meeting a few minutes early !
15:51:41 <jeremycaine> Thank you everyone :-)
15:51:55 <jeremycaine> laurens: next f2f will probably be TPAC
15:52:38 <acoburn> acoburn has joined #lws
15:52:46 <pchampin> RRSAgent, make minutes
15:52:47 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/28-lws-minutes.html pchampin
15:52:53 <acoburn> acoburn has left #lws
18:46:32 <Zakim> Zakim has left #lws