# W3C Solid Community Group: Weekly

* Date: 2023-05-17T14: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
* [Ted Thibodeau](https://github.com/TallTed) (he/him) (OpenLinkSw.com)
* [Jesse Wright](https://www.jeswr.org/#me)
* Jeff Zucker
* Maxime Lecoq (last half)

---

## 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
* JW: Currently working for Inrupt with main focus on data interoperability. Been in Solid space for about 1.5 years. I will be working with the [EWADA team](https://ewada.ox.ac.uk/) at Oxford in a few months. Got into this through semantic reasoning and that's been my main thing for a while.

---

## Topics

## Shapes repo
* SC: Would you be interested in moving it forward in these meetings?
* JW: Yes. I am working on [templates](https://github.com/jeswr/shapeRepo).
* SC: Would that be according to specs?
* JW: No, it would be putting commonly used shapes in applications into a repository outside the Solid Github Organisation.
* eP: There are shapes that are attached to a specification, we don't have specs attached to contacts, etc. aside from webid-profile. In the long run we need shapes that are domain specific (calender contacts, etc.), but these are not core solid protocol shapes. We should keep that distinct. We should not have business-specific shapes but only those used by specs. WebID-Profile, interop, maybe notifications, etc. there are already shapes that are defined. Business-specific shapes are needed but only backed by some implementations so we need a different process for those that are not accompanied by a Solid spec.
* JW: I agree that Solid shapes should be based on spec stuff. The goal of the template I am currently working on is to have a workflow like [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped/) so people can contribute/discover similar shapes to the ones in their app.
* eP: Jackson is doing some work with ShEx shapes + TS. https://github.com/o-development/ldo
* JW: Yeah, I have seen it.

## Talks and Presentations
URL: https://2023.mydata.org/

* SC: I was asked to talk about Solid / Solid Protocol / CG's work items. Will represent myself as chair and speak on behalf of the CG. Unless there are objections?
* SC: No objections.

### WIP Implementation Feedback
* SC: We'll allocate some time for implementation feedback or interest to implement. Links to products/projects and demos welcome.
* eP: I am working on implementing support for non-RDF sources. Some nuances working with non-RDF data. Looking into storing preferred filename in the description resource. If someone is interested in feedback, I'd be open to sharing this next week / on the chat.

### Recommend translation guide and consistent spelling
URL: https://github.com/solid/specification/pull/509

* SC: Resolves https://github.com/solid/specification/issues/508
* SC: Recommends "Use consistent spelling throughout the document." -- essentially it is Editors' responsibility. Rationale in https://github.com/solid/specification/issues/508#issuecomment-1461883028
* SC: Any objections to merge?
* TT: General guidance is good. The challenge is knowing what any doc is using. If you're reading something named in British spelling, you need to search documents on that thing and if they are using US spelling, you cannot find them.
* SC: For things that are terms that are defined,t hose will be whatever the initial definition is.
* TT: let's imagine there's a function "behaviour". You want to find all instances for that function but you have "behaviour" and "behavior". That's why the document is easy for the editor but maybe not the project.
* SC: So that is more about findability/searchability. If this issue would have been that significant it would have been a requirements.
* TT: The balance is to consider all the things and come up with the best suggestion. Manual of Style are "should".
* SC: There are a lot of guidelines that are not strictly following the MoS. People have different spelling and things configure for that spelling. If we put one of these and force everyone to switch, that's maybe not the right path.
* eP: I don't think there's a need to make a political/ideological statement. It could be useful for specs/readme to express who is responsible for spelling/proof-reading, and this person should have some flexibility and freedom of choice. I think it should be a native speaker thought it doesn't have to be.
* SC: That falls into the editor role. We can consider using en-US or en-GB as being chosen by the group and stick to it.
* TT: A large piece of the flexibility is lower the barriers to entry. If someone wants to write documents the flavor of English shouldn't be the barrier. I can read UK English but I might have hiccups. Same goes the other way around. It makes work more difficult for writers/editors, but easier for readers.
* VB: I don't know if picking one British or American is helpful. I think we should aim for consistency within the document itself. part of editing and proof reading, finding those things that can be ambigious. If there is word / term used in US or UK, that's part of editing to be more universal. The case with "behavio(u)r". I think there are other ways to handle that. Avoid using those contentious terms. I don't think it is going to be a huge thing. It depends on where you are searching and a lot of software already handle one or the other. If not, we should avoid those terms. Name of a function for instance. Use a synonym. Those things can be handled in different ways as part of editing or proof reading.
* SC: I don't know what GH does differentiating between different spellings.
* SC: I don't know if this PR closes the issue. The general recommendation is to use consistent spelling. The PR does not pick a standard. If it were up to me I'd say we use GB English. But I don't think it's appropriate for me to say we should use one because I prefer it, but at the same time other people have preferences and stick to that.
* TT: It might be a decision for the Great Solid Parliament. It's more challenging to decide one way and change later.
* SC: Any objections to merging this PR?
* SC: Could we defer this topic beyond PR or is this topic pressing?
* eP: Given those guidelines, if someone makes a PR and it's not matching the spelling of the document, can we expect the editor to accept the PR adding a commit or do we anticipate it'll have requested changes on spelling?
* SC: I'd expect the editor to make the changes. Any readability/spelling will be adjusted by the editor without changing the essence of the information, with some expectations where there are cultural expressions specific to a place. If the author submits something with spelling not align to the rest of the document, the editor should do it or ask the author to do it.

### Add server-content-type-payload
URL: https://github.com/solid/specification/pull/524

* SC: Add requirement for server to include `Content-Type` in messages with payload in Solid Protocol.
* SC: 3 approved reviews and other general approvals - thumbs ups.
* SC: Preview at http://htmlpreview.github.io/?https://github.com/solid/specification/blob/dd639ef5be43f02a6aee231f8d6185b80e2bd487/ED/protocol.html#server-content-type-payload (may need to re-trigger jump to anchor from addressbar to go to the requirement)
* SC: Any feedback or objections/clarifications?
* eP: I already provided my feedback to clarify that it is mostly the interpretation of HEAD in a message that contains a payload body. Switching to the new RFC would be a separate step where the payload body is referred to as content. In a message with payload body in the future could be renamed to content but still work.
* SC: The PR refers to a ??? that contains a payload body.
* eP: Once we move to the new RFC the payload body moves to content.
* SC: I was thinking of processing the whole spec where there's a reference to RFC-??? - not just about payload but other terms too. Once we replace we need to adjust grammar/terms used in the new spec, which is why I didn't want to jump into that now. We have an issue for that as separate step. As for the HEAD, it is identical to GET with the exception it does not have a payload. GET needs to have a content type, when you do HEAD you will get the same header. Not in the same category because HEAD is not ??? a message.
* eP: Does the current wording make it clear that it also applies to HEAD?
* SC: This requirement does not cover HEAD because it doesn't have a payload body, but because it covers GET and HEAD is equivalent to GET with headers ???. It might not apply to OPTIONS.
* TT: I'm not sure content type is inapplicable to HEAD.
* SC: The requirement.
* TT: Is there any guidance for messages that do not include. apyaload body?
* SC: Yes that's the RFC which says HEAD is exactly same a GET but without a payload.
* eP: I expect HEAD to return content type.
* TT: I expect the same.
* JZ: I agree that we should specifically mention HEAD as returning content type. If not there is a gap.
* SC: There are lot of things in RFC-??? that we don't duplicate. We assume if you dive into Solid protocol you know the expectations. Solid Protocol only adds new information that say things with a payload must have content type.
* JZ: Is there a statement that HEAD must have a content type?
* SC: No.
* JZ: I would like to see one.
* SC: Thre will be. RFC says HEAD is same as GET without the payload. When we add this new requirement it ensures we get a content type in the HEAD.
* JZ: For people that have read both.
* SC: It is a requirement for Solid protocol.
* TT: No guarantee that it will be observed. Why do we need to say that any response with payload must have a content type? Is that not required by RFC?
* SC: No. It's a SHOULD. This makes it a MUST.
* TT: why is it not a MUST?
* SC: It might be returning things that ???
* TT: I'm pretty sure a solid server should be used as any HTTP server.
* SC: ??? I'm weighing the security implications over...
* TT: and that's why it's a SHOULD, it incorporates security concerns.
* SC: When the server is offering a file, it needs to know what it's offering. Solid protocol is trying to be as secure as possible.
* eP: If you read through the dependencies of specs we can make it easier to ??? If the server knows the content type it must include it.
* SC: Is there an objection to merging this?
* TT: I need to re-read.

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

>* PA: Yes, I will review this PR and try to get feedback from other W3C people about how to address this. I like the idea to list them as other "adopted" drafts; however, this might indicate a stronger commitment.

* SC: PR open for one month. We discussed and factored in changed. The PR is still a significant improvement. I propose we merge now prior to other reviews from W3C. PA / W3C Team can follow-up when new information is available.
* TT: Okay to merge from my side.
* eP: I think we can merge and I can create an issue to capture what's not fully addressed.
* SC: I don't think we have to create an issue. If there's a problem PA can create an issue. Are you okay to leave it to PA to come back to it?
* eP: I approved it. If the PR is closed the discussion is archived. I'll create an issue to make sure we have a good strategy.
* SC: Let's leave it to PA for "last call".

### Clarify introductory motivation and background
URL: https://github.com/solid/solid-wg-charter/pull/34

* SC: Another pass at motivation/background section integration the feedback in https://github.com/solid/solid-wg-charter/issues/32 . Resolves issue.
* SC: 1 approved review. One general approval - thumbs up.
* SC: This is editorial. Any objections to merge?

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

* SC: Related issue https://github.com/solid/solid-wg-charter/issues/29 that can move to issue 9.

### Compatibility with existing implementations
URL: https://github.com/solid/solid-wg-charter/issues/31

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