# W3C Solid Community Group: Weekly

* Date: 2023-04-12T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification
* Status: Draft

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* [Virginia Balseiro](https://virginiabalseiro.com/#me)
* elf Pavlik
* April Daly
* Jeff Zucker
* [Hadrian](https://hadrian.solidcommunity.net/profile/card#me)
* TimBL
* Jaison B.

---

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/solid/specification/blob/main/meetings/README.md).
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Join queue to talk.
* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/).
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.

### Scribes
* Virginia

### Introductions
* name: text

---

## Topics

### Overview of today's agenda

* SC: Today's meeting will focus on the Solid WG Charter that follows 2023-03-22 meeting topic for reviews: https://github.com/solid/specification/blob/main/meetings/2023-03-22.md#solid-wg and continues on https://github.com/solid/specification/blob/main/meetings/2023-03-29.md and https://github.com/solid/specification/blob/main/meetings/2023-04-05.md
* SC: Agreement from earlier meetings is we will prepare issues/PR until we have agreement in the CG and PAC will be assigned to merge them.
* SC: Questions or suggestions for today's agenda?
* JZ: I will have to leave halfway through due to the team meeting.
* VB: There's a topic to discuss the meeting clash, I will be there on the second half.
* SC: CG meeting has been on the calendar.
* SC: First open PRs then issues:

### fixed spelling and such
URL: https://github.com/solid/solid-wg-charter/pull/27

>ACTION: TT to make further suggestions via PR following merge of [pull#26](https://github.com/solid/solid-wg-charter/pull/26)

* SC: Assigned to PAC but anyone can review or ask questions. Objections?
* SC: No objections.

### Clarify normative, tentative, new Deliverables
URL: https://github.com/solid/solid-wg-charter/pull/28

* SC: Summarises the PR.
* SC: Currently difficult to separate what is actually a deliverable to what may become one. It uses the charter template which has a field for draft status and where it was adapted ???
* SC: Separates deliverables we will have and new deliverable that will be taken up. Doesn't change the essence of the text, just moves text around.
* SC: I have looked at feedback given on charters in the past, there were formal objections on some of them, and the resolution was to separate deliverable from incubation work. eg: https://www.w3.org/2022/11/das-wg-charter.html , https://www.w3.org/2019/05/webapps-charter.html
* SC: The way the group passed the objection was to clarify ??? and what new deliverables had been added. I am hoping that by making this clarification we can avoid potential formal objections.
* SC: Clarifies relationship between WG and CG.

### Scope needs to be tightly defined with narrow focus
URL: https://github.com/solid/solid-wg-charter/issues/9

>* SC: eP mentioned something earlier about connecting the WG and CG more clearly. That would help. If you'd like to create an issue we can work on it and pick it up next week.

* SC: Issue [Add to charter template hook for CG relationship (split of work, etc.)](https://github.com/w3c/charter-drafts/issues/262) is acknowledged / of interest. Useful guideline for us:
* SC: https://github.com/solid/solid-wg-charter/pull/28 covers some of the relationship based on incubated work towards adding a new deliverable in the charter.
* eP: We haven't clarifies this requirement for normative dependencies. As I recall, Tim said normative dep. needs to be at CR stage. We should clarify those requirements.
* SC: Yes, that's probably what we have to do: make sure those deps are CR level. But we're making a proposal with just Solid Protocol and hope that we will need to make those specs more mature. We probably need to bring to ??? not sure if we're able to propose all those specs as a deliverable. Agreement is Solid Protocol is the primary deliverable.
* JZ: Is this a separation of what the group deals with or what is a deliverable? Do these other things (AuthZm, etc) fit within the WG just not deliverables yet, or are still within CG?
* SC: Within the scope, but no hard commitment on them being a deliverable. If we can get ??? these other specs still incubated to mature, we have a path to make them a new deliverable.
* JZ: Sounds good.
* SC: This is based on how other formal objections were made. I expect we will get some objections on insufficient incubation.
* TBL: On the Solid Protocol?
* SC: They may raise that because we don't have every ??? we have server, apps, and they are linked to the charter.
* TBL: We have servers that have been running for years.
* SC: One example: using verifiable credentials data model to do integrity checks. There's also mentions on data synchronization. Things are being mentioned in the charter that we haven't done in the CG which may come across as something totally new. For the Solid Protocol itself I don't think it is an issue. If we can clarify the things that might be nitpicked we have an better chance for this to be accepted. So this PR separates what's been incubated from what's in the works.
* SC: So, Solid Protocol is a deliverable, WAC etc, for example, are not as it stands.
* eP: I still think it'd be safer to wait a couple days and clarify this requirement. If it turns out to reach CR all the dependencies have to be at least CR, that is self-contradicting. If we may not deliver WAC but it's a normative dep. for protocol, it sets an impossible outcome.
* TBL: Do you imagine that the work in WAC will be pursued by people outside the WG?
* eP: We have a Solid Protocol as an adopted draft which has normative refs on the 4 drafts that are tentative deliverables. How can we deliver protocol without its dependencies?
* TBL: WAC has to be a normative ref. because it's a big part of Solid. If not sufficiently stable, then work needs to be done to stabilize it.
* SC: We can have an easier transition/adoption of those deliverables once we have protocol accepted. Right now, if we dump those deps. as deliverables it may be a harder sell. We need to promise to be able to deliver all that work, and that's at least 5 specs.
* TBL: Can we list them?
* SC: It's in the PR. Solid-OIDC, WAC, ACP, Notifications protocol. http://htmlpreview.github.io/?https://github.com/solid/solid-wg-charter/blob/12a9e08ff5876e24c0f1b7c0f180d3e1bc5b6efa/charter/index.html
* TBL: Notifications is the only new thing. Well ACP too. Dependency on Solid-OIDC is critical as it is a valuable thing by itself. The concern seems to be it is evolving.
* SC: It'll be easier to get those specs into track if acknowledged as deps
* eP: Did you check in those examples if the deliverables has deps
* SC: No. Didn't get to it.
* eP: I see two options: if we propose protocol as currently is, the other parts need to go into deliverables as well. we can't leave them optional. other option is to extract solid storage, which can be delivered without deps on the other ones.
* TBL: if you;re proposing to make WAC optional, then we don't explain how NSS/CSS work.
* eP: Tentative dependencies says those are optional.
* SC: They're not optional. My intention was not that the specs are optional, I just adopted the language that they used there. I know they are required, and we do need to get them into Rec track.
* SC: I think we need to have all contributors to be in full commitment on the deliverable in order to be successful. If we add these things and have the same patters we currently have, we will be in a situation where we have to ask to recharter.
* TBL: If WG doesn't make progress, then the system is broken.
* SC: There's no reason why we cannot advance those specs right now. Anyone can help. Whereas in a working group only the Members and IEs, and in addition to open contributions on GH but without voting rights. In CG the barriers are lower. Those that do want Solid-OIDC, WAC, etc to advance there is no reason why we can't work on them in the CG. Now we're saying we want to have those specs pulled from CG into WG.
* TBL: Hoping WG pushes things to be more formal.
* SC: Fingers crossed. I suggest we get this deliverable accepted, and then it will be easier to get those other specs.
* TBL: You're saying we should not add them?
* SC: Not now. Once the group starts we can from early on raise them as a need and plan how to transition those things. WebID for example is also a dependency.
* TBL: WebID is needed by the server for AuthN.
* TBL: There's no reason for the working group to be involved in profiles. WebID-Profile the only thing WG needs to talk about are where it is needed for OIDC.
* SC: Which includes the notion of WebID.
* eP: Solid-OIDC requires that there is a solid-oidc issuer ??? so it depends on WebID for that. AuthN is dependency of WAC ???
* SC: Solid Protocol refers to these specs as a normative reference. If those need to be CR or something more mature, we need to make sure those are advanced as well. If we list out all the things, it will be way too much for the proposal. It is easier to move them once we pass this hurdle.
* TBL: The WG does not have to do all that work itself. The WG just needs to make sure it or somebody else gets all the dependency to the level that ???
* SC: We have a lot on our plate with implementations and test suites for all those specs.
* eP: If we make those optional, we can anticipate the WG might not deliver them, so the Solid Protocol would need to be able to make those optional.
* TBL: You can only mark something as at risk if system cannot work without it.
* eP: In that case the protocol will not work without those so they cannot be tentative. So this PR is not coherent.
* SC: Can we change the language around it? The intention is not that they are optional. If "tentative" gives that impression we should change it. The current state of the charter doesn't make them deliverables.
* TBL: Is that dependent on progress? I don't like "tentative". These are hard deps. If other groups do not advance these hard deps, then the WG will do it itself.
* SC: In one of the other charters, it mentioned that depending on the web platform community group progress... etc. in our version I took that out. so it was no depending on CG progress.
* TBL: there could be a WAC WG. Doesn't matter who does it. depending on "external".
* SC: What about changing from "tentative" to "dependent deliverables"?
* TBL: Maybe just dependencies?
* SC: Sure.
* eP: Unless other WG has it on their charter, it should be here otherwise it is too vague.
* SC: changing "tentative" to "dependencies", and "depending on the progress of other groups it will also produce".
* eP: Should we specify which groups?
* SC: TBL, would you mind clarifying?
* TBL: who's working on Solid-OIDC?
* SC: Solid CG atm.
* TBL: Is there a panel?
* SC: Like I said earlier, the other charter used CG. If you think that is a better way we can bring that in.
* TBL: Similarly WAC, at times other people have worked on WAC. But now is it definitely just the CG?
* SC: Yes. Other communities use WAC but they are not advancing it. For example, https://fcrepo.github.io/fcrepo-specification/ refers to WAC.
* eP: If you can find if the tentative deliverables are hard dependencies, yes, if not it is a completely different case.
* SC: Web share API is listed under tentative, it lists File API as a normative ref. Oh nm.

### Clarification on Solid and comparisons
URL: https://github.com/solid/solid-wg-charter/issues/5

### Update mission
URL: https://github.com/solid/solid-wg-charter/issues/7

### Review from TAG should be requested prior to Member review
URL: https://github.com/solid/solid-wg-charter/issues/15

---

### JSON-LD Context URI
* SC: Noting that published Solid-OIDC JSON-LD context is https://www.w3.org/ns/solid-oidc-context.jsonld
* SC: Proposed (not yet published) Solid Notifications Protocol JSON-LD context is: `https://www.w3.org/ns/solid/notification/v1`.
* SC: Should we set a URI template for all JSON-LD context URIs or leave it open to specifications to use a template of their choice?
* SC: `notification/v1` is similar to `vc/v1` and `credentials/v2`.