13:56:24 RRSAgent has joined #lws 13:56:28 logging to https://www.w3.org/2025/03/31-lws-irc 13:56:54 zakim, start meeting 13:56:54 RRSAgent, make logs Public 13:56:56 please title this meeting ("meeting: ..."), acoburn 13:57:00 meeting: Linked Web Storage 13:57:15 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250331T100000/#agenda 13:57:15 clear agenda 13:57:15 agenda+ Introductions and announcements 13:57:15 agenda+ Action items 13:57:15 agenda+ Charter schedule 13:57:15 agenda+ Use cases update 13:57:17 agenda+ Clarify scope of portability use cases 13:57:29 RRSAgent, make minutes 13:57:31 I have made the request to generate https://www.w3.org/2025/03/31-lws-minutes.html acoburn 14:00:11 present+ 14:00:12 TallTed has joined #lws 14:00:32 cpn has joined #lws 14:00:38 hadrian has joined #lws 14:00:45 present+ 14:02:08 present+ 14:02:17 bendm has joined #lws 14:02:17 present+ 14:02:17 present+ 14:02:31 eBremer has joined #lws 14:02:36 present+ 14:02:41 AZ has joined #lws 14:03:32 TallTed has changed the topic to: LWS WG -- 2025-03-31 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250331T100000/ 14:04:56 laurens has joined #lws 14:05:02 present+ 14:05:05 I have made the request to generate https://www.w3.org/2025/03/31-lws-minutes.html TallTed 14:05:12 scribenick: cpn 14:05:12 present+ 14:05:12 scribe+ cpn 14:05:26 present+ 14:06:00 previous meeting:https://www.w3.org/2025/03/24-lws-minutes.html 14:06:02 next meeting: https://www.w3.org/2025/04/07-lws-minutes.html 14:06:18 ericP has joined #lws 14:06:19 chair: acoburn 14:06:41 Zakim, open first item 14:06:41 I don't understand 'open first item', TallTed 14:06:48 Zakim, next agendum 14:06:48 agendum 1 -- Introductions and announcements -- taken up [from agendabot] 14:07:04 ryey has joined #lws 14:07:08 present+ 14:07:40 acoburn: One announcement, we're all in daylight savings, so scheduling should be back to normal 14:07:44 ... anything else? 14:07:54 zakim, open agendum 2 14:07:54 agendum 2 -- Action items -- taken up [from agendabot] 14:07:54 (nothing) 14:08:22 acoburn: Action items, weekly update on the UCS issues repo 14:08:46 hadrian: Issues 122 and 125 have been closed 14:09:03 present+ 14:09:12 zakim, open agendum 3 14:09:12 agendum 3 -- Charter schedule -- taken up [from agendabot] 14:09:38 acoburn: According to our charter, we're behind schedule 14:09:44 s|Issues 122 and 125|Issues w3c/lws-ucs#122 and w3c/lws-ucs#125 14:09:54 ... I wanted to go through roles and responsibilities 14:10:14 ... Hadrian is editing use cases and requirements. We'll soon move to the main protocol documents 14:10:29 ... We want editors to have autonomy and be able to work efficiently 14:10:55 pchampin: We had similar discussion a few weeks ago in the RDF-Star WG 14:11:12 ... PRs are made in the open, by editors or anyone else 14:11:34 ... The issue we had in RDF-Star is long discussions in PRs that didn't converge, so we had lots of pending PRs 14:11:58 ... Editors are the owners of the document, they should feel entitled to merge PRs, even if not all points of discussion have been resolved 14:12:16 ericP has joined #lws 14:12:26 q+ 14:12:28 present+ 14:12:33 ... Merging a PR can result in issues being raised if not all points have been resolved 14:12:48 ... Editors are expected to respond to comments, but they can defer until after merging a PR 14:12:59 ack next 14:13:44 tallted: There are a lot of English-isms that foreign speakers my not understand 14:13:59 ... Editors merging PRs happens often, with my disagreement 14:14:16 ... If PRs are merged, the issues should not be marked as resolved in the PR thread 14:14:37 ... It's difficult as participant to keep track of which comments were made, and have been resolved or not 14:14:53 ... It makes a big difference to know that things aren't being closed out of hand 14:15:14 ... Rather than clicking the Resolve button, putting in a comment to explain helps 14:15:17 q+ 14:15:25 ack next 14:15:39 pchampin: +1 tallted, important to have transparency and traceability 14:15:55 ... So don't mark Resolved, so we can still see what's pending 14:16:28 ... If we use Echidna, it will turn every merge into a new public WD. But these WDs aren't expected to reflect group consensus 14:16:34 q+ 14:16:48 ack next 14:16:56 ... This speaks in favour of giving editors autonomy while allowing unresolved issues to be solved later 14:18:05 acoburn: I'm not so concerned about whether a PR is merged by the editor. Depends on the status of the document. We can go faster this way up to FPWD, I'm OK with it 14:18:25 s/acoburn:/csarven:/ 14:18:30 ... Also things like making sure requirements relate to use cases 14:18:45 rrsagent: make minutes 14:18:46 I have made the request to generate https://www.w3.org/2025/03/31-lws-minutes.html acoburn 14:19:06 ... We could put energy into doing that yet, or wait to FPWD 14:19:43 ... We may be able to save time. But I want concrete agreement on which option we're going with 14:19:59 ... We need to review things, and make sure it's what we agreed on 14:20:14 q+ 14:20:44 ... When we're writing the spec, if this has FPWD, the members will review it. If the paperwork isn't aligned, it becomes a target for objections 14:21:08 ... I believe that will come up. Some people aren't in favour of what this WG is doing 14:21:52 ... Editors should feel comfortable to move forward as best they can, but needs to reflect group consensus 14:22:19 acoburn: So you're saying any WD should reflect WG consensus? 14:22:48 csarven: It's better to have more people on board at FPWD stage than find out at CR that there's disagreement 14:22:53 q+ to comment on consensus and WD 14:22:57 ... So get early agreement as much as possible 14:23:06 ack next 14:23:31 ericP has joined #lws 14:23:32 FPWD starts the patent policy clock, among various other arcane things, and does not require the same level of consensus os CR or PR 14:23:45 hadrian: I agree with what's been said. Is there something we're trying to improve? 14:23:50 ack next 14:23:51 pchampin, you wanted to comment on consensus and WD 14:24:43 pchampin: To csarven's point, we're in general agreement. My point was we don't need to get consensus at the granularity of every WD, which changes with every PR with Echidna 14:25:16 ... Not suggesting to wait for CR to see if we have consensus 14:25:47 q+ to say that including issues inline in the doc makes it easy for readers/contributors see where there are disagreements and whether they are editorial 14:26:00 ... hadrian, I brought this up as it was necessary in the RDF-Star WG. At the moment, the way we've worked with the use case document is aligned with this way of working 14:26:01 ack next 14:26:02 ericP, you wanted to say that including issues inline in the doc makes it easy for readers/contributors see where there are disagreements and whether they are editorial 14:26:45 q+ to mention correction classes and the role of the editor 14:26:53 There is relevant ReSpec markup for issue inclusion, which includes a link to the issue on GitHub, among other things. 14:26:56 ack next 14:26:57 csarven, you wanted to mention correction classes and the role of the editor 14:27:06 https://www.w3.org/policies/process/#correction-classes https://www.w3.org/guide/editor/role.html 14:27:34 csarven: Correction classes, this is a guideline, doesn't apply to every kind of document 14:28:01 ... What works in my experience, if a PR says what kind of a change it is, it gives a heads up to reviewers 14:28:43 ... A PR needs to explain what is the ask. Correction classes can be a good guide: e.g., adding a new feature - does it break anything, etc? 14:28:48 I have made the request to generate https://www.w3.org/2025/03/31-lws-minutes.html TallTed 14:28:59 ... If it adds a new use case, that's like adding a new feature 14:29:34 ... The editor guide is useful. If editors feel it's faster to push things through, there'll be a moment when we can review it, that's a fair approach 14:30:06 ... The time we're taking in meetings for use cases and requirements, should be reflected in PR with links to minutes 14:30:11 q+ to say that a measure of whether a change is substantial is whether it would change an implementation 14:30:28 ... It makes reviewing easier, leading to less confusion 14:30:44 ... I just reviewed a PR earlier, I wanted to know where the requirements are coming from 14:31:03 q+ 14:31:30 ... Lots of energy went into the PR, good to acknowledge that, the requirement is in scope and relevant for the protocol spec, and it links to the use case 14:32:06 ... The rest is authoring level changes - does it accurately reflect the requirement? 14:32:16 ack next 14:32:17 ericP, you wanted to say that a measure of whether a change is substantial is whether it would change an implementation 14:32:18 ... Those two links are useful to read 14:32:38 ack next 14:32:41 ericp: A way go gauge if editorial or not is if it changes implementations 14:32:46 s/go/to/ 14:33:41 hadrian: Anybody can make additions to issues and PRs. But not everything can be solved asynchronously. I'm available if you or anyone wants to push things forwards 14:33:51 acoburn: I think we have consensus on where we want to go 14:34:04 ... May be some details on the best path 14:34:34 ... We want documents that reflect consensus, whether per-PR or at significant points in the lifecycle 14:34:42 ... Other comments on this topic? 14:34:49 (nothing) 14:35:06 zakim, open agendum 4 14:35:06 agendum 4 -- Use cases update -- taken up [from agendabot] 14:35:12 q+ 14:35:47 pchampin: One small thing, I haven't set up GitHub Pages on the use case document, to have the HTML rendered automatically 14:36:08 ... I'll set it up, unless anyone objects? 14:36:21 (no objection) 14:36:26 acoburn: Go ahead 14:37:05 hadrian: pchampin and I discussed last week after the meeting. Everything I tried after that worked 14:37:12 ... One thing is writing text vertically in the matrix 14:37:37 ... If we have too many columns, we can split into multiple matrices based on categories 14:37:48 ... I created a Miro board, should be ready to share next week 14:38:12 ... I tried to use the same personas, and created some context so it's clearer in what context the use cases apply 14:38:21 ... It's work in progress 14:38:51 ... No pointer to the minutes though, and the other issue was about the glossary 14:38:59 ... Any questions? 14:39:11 (nothing) 14:39:49 hadrian: I started looking into the consent part. Didn't have time to look into discovery, but it's high on my list 14:39:59 zakim, open agendum 5 14:39:59 agendum 5 -- Clarify scope of portability use cases -- taken up [from agendabot] 14:40:46 acoburn: Could spend more time on consent, but want to look at other use cases than go deeper 14:41:02 hadrian: Portability is a big topic, would be good to gauge the group's opinion 14:41:31 ... Portability refers to moving data between storage, or from a provider. Want to do it without breaking anything, or as little as possible 14:41:55 ... Depending on the governance, it should not always be a required feature, a negotiation between a service provider and a user 14:42:06 ... Some storages should not be moved outside a specific jurisdiction 14:42:16 jeswr has joined #lws 14:42:27 ... The user may not have complete control over the portability process, but the spec should allow that as much as possible 14:42:40 present+ 14:42:50 q+ 14:42:50 q+ 14:43:02 ... Need to deal with identity. If the identifier is issued by the SP, that's OK, and you may get another identifier in the new SP 14:43:15 ... Need something controlled by the user, to ensure continuity 14:43:40 ... An alternative is to use self-sovereign identifiers, which would make it easier, but means dealing with discovery 14:43:59 ack next 14:44:05 ack next 14:44:28 tallted: This is where things start getting complex. I have question about the question being asked 14:44:39 ... Identifiers are a challenging aspect of portable web storage 14:45:01 q+ to mention URI persistence, AWWW 14:45:17 ... The idea I have stuff on one provider, move it somewhere else, and have it still work. Requires use of portable identifiers instead of provider based identifiers 14:45:28 ... purls and dids 14:46:48 ... This is where portability of data structures becomes important. Maybe one provider only stores JPEGs or PNGs. Users will hit these things, the point of standardised structures so any application can work with your picture album 14:46:49 q 14:46:52 ack next 14:47:27 jeswr: In response to tallted, that we're necessitating ?? identifiers 14:47:30 q+ 14:47:55 ericP has joined #lws 14:48:05 ... Suggest we ensure identifiers are portable, but not require that, so that whatever identity method we use, not restricting use of non-portable identifiers like web ids 14:48:30 ... A meta comment, when we have these use case discussions in other groups, is there a structure that's followed to help get a written form of consensus faster? 14:49:11 q+ 14:49:25 pchampin: No straightfoward answer... 14:49:30 q+ to say that portable IDs, for individuals out resources, lean on a some shared resource 14:50:14 tallted: Same. A small WG could do it. It could be helpful to set up a structure, e.g., announcing which use case we'll discuss in a meeting, focus less on administrivia 14:50:36 ... Then enable async communications so we don't have to do everything in a group call 14:50:48 ack next 14:50:49 csarven, you wanted to mention URI persistence, AWWW 14:50:52 ... F2F is more efficient 14:50:57 https://www.w3.org/TR/webarch/#URI-persistence https://www.rfc-editor.org/rfc/rfc9110#name-purpose 14:51:12 csarven: On portability, we need to be careful with the charter scope 14:51:38 ... Whether the protocol is covering things around the interface, HTTP is the key candidate, there may be others 14:51:53 ... If describing other aspects of storage, e.g., whether encrypted, things behind the interaction 14:52:05 ... HTTP for example hides those details 14:52:30 ... How representations are stored is up to the implementation 14:53:11 ... If the representation is expressed using relative URLs or has a particular way of referring to things, from one lens, that could be fine, but from another we could constrain it to use absolute URIs or have canonicalization 14:53:24 ... This ties into the web architecture's URI persistence 14:53:55 ... If you put something on the web, announce a URI, there's a social agreement, you have the means to keep it up, the semantics of the resource. You can 404 or redirect to the new storage 14:54:05 "Cool URIs don't change," except that they do. 14:54:15 ... So the former owner of the URI can redirect to the new storage 14:54:15 q? 14:54:39 ... Whoever has authority of the URIs will make the call 14:55:04 ack next 14:55:15 ... Need to clarify what level of the storage we're talking about. The protocol doesn't need to describe implementation details. It's the web architecture's description of persistence 14:55:56 hadrian: Web ids are portable provided you use your own domain 14:56:22 ... Other solutions for portability is to have part of the URL, the path, that's controlled by the user, and part that's controlled by the service 14:56:40 ... What do we want as a group? Jessie demonstrated this a few years ago with SOLID 14:56:49 ack next 14:57:13 tallted: A lot of these open questions that csarven and hadrian are highlighting, are part of the picture when discussing a use case 14:57:31 ... Use case may be that you want images available at the same location for ever 14:57:42 ... Capture these in the requirements area of a use case 14:58:13 ack next 14:58:14 ericP, you wanted to say that portable IDs, for individuals out resources, lean on a some shared resource 14:58:16 ... The use cases may have things that are common and things that are specific, e.g., storage and portability of the storage. Just needs hashing out 14:58:54 ericp: Any portability requires on a shared resource, could be DNS, a registry like purl.org which we've seen fail, a shared ledger 14:59:13 q+ 14:59:25 q- 14:59:26 ... In use cases need to figure out if we want portability when their data provider turns evil and they don't do the equivalent of a domain transfer 14:59:46 acoburn: there's more to discuss here. Want to see some more direction. Let's discuss additional details on this next week 14:59:52 RRSAgent, make minutes 14:59:53 I have made the request to generate https://www.w3.org/2025/03/31-lws-minutes.html pchampin 15:00:31 acoburn has left #lws