– DRAFT –
Linked Web Storage WG

Introduction & Announcements

ericP: intro and announce?
… any new people? no

<ericP> [no announcements]

Test suite update

<ericP> [deferred]

Use Cases & Requirements document

acoburn: lots of work done on UC and req doc about 18mo aho
… but still needs lots of work e.g UC need to be consistently organised
… aligned with what LWS is trying to achieve
… what we have has gone beyond the initial scope being planned to be produced
… who wants to help editing / uplifting the docs

<Zakim> elf-pavlik, you wanted to connect it to tracking interest in implementing #171

elf-pavlik: person proposing a use case should write into the do

<jeswr> Use case repo: w3c/lws-ucs

elf-pavlik: UC proposal does not need to be implemented

<jeswr> Use case spec doc: https://w3c.github.io/lws-ucs/spec/

TallTed: UC proposer can be a consultant to the implementor

<Zakim> Happy, you wanted to assist on use case effort, want to get a sense of whether group is ok with having an LLM pipeline there which is what I having going with personal projects now

jeswr: happy to help out; has automated pipelines
… also using code gen LWS apps
… similar to solid code work

acoburn: UC > requirements > implementation
… current requirements have multiple upstream UCs
… should not assume UC proposer has to implement

jeremycaine: i wanted to understand a little bit more as someone who chooses to implement use case
… are they going to have to implement a reference implementation and build app to implement use case?
… what is the general process

ericP: is it regarding elf-pavlik proposal to connect impl to use cases?

<Zakim> ericP, you wanted to ack if anyone object to claude authoring

jeremycaine: is the goal to implement reference, past the tests and app to demonstrate the use case?

ericP: use case will have some requirements and they may need to be included in the test suite
… does anyone object to use llm to work on use cases, as long as human baby sit it?

<TallTed> LLMs must be treated as junior coders, at best. *heavy* code review.

<eBremer> +1 TallTed

<Zakim> acoburn, you wanted to say that we are ultimately responsible for the content

jeremycaine: i don't have any objections to agentic coding, i think it can do more senior coding
… what is missing, you need to be very clear on the test suite for the use case, to prove implementation
… we don't have it in use case document

ericP: we don't have anything in document to anticipate agentic coding

<Zakim> acoburn, you wanted to re-center discussion

jeremycaine: we need a test, no matter if we vibe code it or write it ourselves

acoburn: this is specific about helping out with ucs document

<Zakim> gibsonf, you wanted to ask that no vibe coding is ever used for making tests

gibsonf1: vote for vibe coding - should not be used for writing tests

Test suite update

Auxiliary Resources: PR#165 and PR#167

ericP: who can summarise 165 and 167

acoburn: pchampin and termontwouter are present

termontwouter: 165 - redefines the basis of what is the content stored on the server
… conceptually
… defines it in terms of representation
… metadata by client or server are representation of the same data

pchampin: 167 - don't like metdata or linkedsets of primary data resource
… in order to get it, you can do media request
… linked set aux resource contains things that could evolve
… primary resource could have arbitary media types
… 167: want to able to merge them in my implementation - aux res might be same as primary res
… still discovered by a link header

eBremer: problems around application/linkset
… thinking - using profile parameter

<Zakim> elf-pavlik, you wanted to suggest focusing on specific scenarios, like one brought up by PAC about client managed `application/linkset`

elf-pavlik: need to some specific scenario examples to further discussion

ericP: there is a PR for test content

termontwouter: profile parameter in content neg could work

<elf-pavlik> do we have documented somewhere the issue with profile param and cors?

<Zakim> pchampin, you wanted to discuss how "application/linkset" is blocked by 165

termontwouter: if we don't find compromise; happy to let 165 go and go for 167

pchampin: problem with 165 is content neg is sufficient to switch to partially server maanged
… application/linkset is partially client managed
… should not force all implementations to merge
… 165 is ok if it was clear content neg was not the single mechanism

<Zakim> acoburn, you wanted to talk about the core requirements we are trying to address

ericP: PRs are basically the same rE: application/linkset goal

acoburn: test what we are trying to accommodate? clients can find and modfy linked headers
… in solid these headers are important - server managed, fixed at creation time
… linkset - clients need to be able to discover and modify for a given resource

<Zakim> elf-pavlik, you wanted to ask about proactive vs. reactive conneg and various examples of client interactions

acoburn: is that what we want?

elf-pavlik: need more exmaples both client and server managed

<elf-pavlik> w3c/lws-protocol#39 (comment)

<gb> CLOSED Issue 39 Cool URIs for the Semantic Web: 303 URIs forwarding to Different Documents (by elf-pavlik)

elf-pavlik: server managed client was big topic in solid
… what will be the must and should?
… focus on these in the normative text

<Zakim> pchampin, you wanted to respond to acoburn

pchampin: respond to acoburn - agree with what linkedset was introduced for
… the PRs (165, 167) - response to fred's use case - sometimes metadata and primary resource could be same
… aux res lifetime is linked to lifetime of primary resource

<gibsonf1> +1 on 167 change

pchampin: need to avoid undesirabel content neg

termontwouter: second pchampin - both solve fred's problem; could write out eBremer profile idea for next week discussion

<pchampin> I think the profile-based negotation can be added regardless to both PRs

termontwouter: if you add few sentences to 165 then it solves pchampin issue

eBremer: propose accept 167, and then have an addendum (updated 165)

<ericP> PROPOSED: merge PR#167

<gb> Issue 167 not found

<TallTed> gb, status?

<gb> TallTed, the delay is 15, issues are on, names are off, full issues are printed 10 at a time, commands are ignored from RRSAgent, agendabot, m2gbot and Zakim; and the repositories are w3c/lws-protocol w3c/lws-ucs

<ericP> PROPOSED: merge w3c/lws-protocol#165

<gb> Pull Request 165 Define aux & meta in terms of representations (by termontwouter)

<gibsonf1> +1

<eBremer> +1

<termontwouter> +1

<jeremycaine> +1

<pchampin> +1

<ericP> +1

<elf-pavlik> +1

<acoburn> -1

<TallTed> +0

<gibsonf1> Hold on!

<gibsonf1> I thought this was 167?

<gibsonf1> also - remove vote

<gibsonf1> -1

<ericP> PROPOSED: merge w3c/lws-protocol#167

<gb> Pull Request 167 auxiliary resource as a role (by pchampin)

cancel that vote - error

<gibsonf1> +1

<eBremer> +1

<pchampin> +1

<jeremycaine> +1

<acoburn> +1

<termontwouter> Thanks for noticing!

<termontwouter> +1

<elf-pavlik> +1

<TallTed> +0

<ryey> +1

<ericP> APPROVED: merge w3c/lws-protocol#167

<Zakim> pchampin, you wanted to explain the "issue not found error", for future reference (meta)

pchampin: gb bot can manage several repos; do a PR #167 i.e. with space - use the first repo e.g. LWS

<gb> Pull Request 167 auxiliary resource as a role (by pchampin)

Threat Model Issue#177

elf-pavlik: need a diagram
… create a PR for a diagram
… use same visual language from threat modelling

<ryey> sure!

elf-pavlik: ryey to help

ryey: do we use likec4?

elf-pavlik: we can figure it out

<elf-pavlik> https://likec4.dev/

acoburn: thanks to those reducing issues on friday
… will keep on meeting

<Zakim> link, you wanted to calendar invite?

<acoburn> Issue triage meeting: https://www.w3.org/events/meetings/41133143-8a1f-4f4a-bf69-44daec340f79/

move to close meeting