# W3C Solid Community Group: Solid Editors

* Date: 2021-11-03T14:00:00Z
* Call: https://meet.jit.si/solid-specification
* Chat: https://gitter.im/solid/specification
* Repository: https://github.com/solid/specification

## Present
* [Sarven Capadisli](https://csarven.ca/#i)
* Justin B
* Ruben Verborgh
* Kjetil Kjernsmo
* Dmitri Z

---

## Announcements

### Meeting Recordings and Transcripts
* 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.

### 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
* Sarven

### Introductions
* name: text

---

## Topics

### Level of SPARQL Update support
URL: https://github.com/solid/specification/issues/125

* KK: Not entirely clear how PATCH updates should be done especially in a way that Tim wants. That is in conflict with a requirement in SPARQL update.. which makes it a bit messy. Haven't had the chance to talk to Tim so not sure what he thinks. So ended up making four different PRs. The 4th is a bit inconsistent and deviates a lot from SPARQL. There may be chances to get it into SPARQL if we go for it. There is also the code that Ruben used for N3Patch which is an alternative way. I don't want to mangle sPARQL to omuch to the point that the SPARQL group woldn't go for it. This is the issue we need Tim to discuss with. So, lets look at different issues.

* JB: It seems N3Patch proposal not contested too much. It seems from Tim's perspective it is not either. It doesn't seem like it is violating or deviating from existing standards. seems like the path of least resistence. I'm not sure we can figure out a compliant way for SPARQL that would satisfy everyone.

* KK: I haven't contested it yet but have reservations. That is basically.. I'm still not sure what Tim is trying to achieve. There may be a misunderstanding of SPARQL. would like to clear that possibility out first.

* RV: That may be a misunderstanding.. but we can still get a proper subset of SPARQL or any deviation.

* KK: If you know what triple it is that you want to change. That is easy.. basically. It is also legitimate to change the triple and insert ??? If it is something else/more, then yes, we probably shouldn't be going with (that?) SPARQL now.

* RV: Open question is: is this suitable for 1.0 or go for undisputed approach for 0.9.

* KK: Perhaps. Would you implement it in CSS?

* RV: The reason Tim wanted this.. he said you have 3 weeks to do it. Not my proudest work but it is simple. It is extensible. The support for N3 libs and support for CSS would be trivial. It is a low hanging fruit with a lot of option for extensibility. Lowest common demoniator so to speak.

* KK: What do you all think?

* SC: Go for it until someone

* JB: ??? +1 n3 patch support

* DZ: +1

* KK: Doesn't it also mean we are deprecating the behaviour (in NSS)?

* RV: I'd say there is disagreement around the behaviour. It is not stable yet. The stable version could be N3.

* KK: At risk word would be use

* DZ: What does solidOS use?

* RV: SPARQL Patch. All of the code that's needed is already there.

* KK: That's the client side? Right.. okay.

* SC: General agreement to support N3 patch.

* RV: Do I need to contribute to spec text?

* KK: Yes. That'd be good.

ACTION: RV to make initial draft. KK to assign relevant issues to RV. KK to record 'something' on that issue.

### Write methods as requirements
URL: https://github.com/solid/specification/pull/304

* KK: Also for testing for compliance... if we have to test for eventuality that Solid server that does not support write operations then that makes the test suite more complex. We would want to support servers that are read-only but that is mostly just a Web server right.. At some point we want to introduce conformance classes. In addition, we want to have language that allows servers for read-only. Which is also in the spec.. Therefore to not tackle more than this then I'd like write methods for required.

* RV: That clarifies a lot. I can imagine read-only servers. How do we know if a solid server announces whether htey are read or write?

* KK: accept headers.

* RV: or status codes.

* SC: Test suite shouldn't be driving factor for the requirement

* KK: I disagree with that idea because. The test suite is important for the health of the ecosystem. As a principle that is important but if there is no easy way to automate the testing then it is a toy.. you don't have a production system you have a toy.

* SC: spec comes before test.. even has test modes have different ways of checking.

* KK: there is principle and pragmatism. In general I agree to adopt the test to requirements. But if we go to the

* SC: then we are requiring automated test - that needs to be a specific requirement of what we expect from the requirement.

* KK: what can we do that's testable in one week. instead of later on. if we want to do thta. so it does infuence a lot of stuff. I have spoken.

* JB: Trying think of a case where

* DZ: test sensor..

* SC: some mentioned in the PR/issues.

* JB: if you can 405 and not .. would you set out a case where you have a solid server and just have only read-only. or is it authz to make it read-only.

* KK: I suspect that you can configure apache with configuration only to be read-only. yes, that thing will exist. at some point we just need a conformance class to have a read-only then that is very

* SC: ...

* RV: use case is read-only / private.

* KK: that makes it more complex to implement.

* DZ: 405?

* SC: yes

* RV: but maybe it needs to be 403 not 405 if we say that write is required.

* JB: okay with 405 and not against 403.

* RV: fine with it.

* KK: language in my patch leaves it open so that can be defined in different terms.

* DZ: i'm on the side of 405 because 403 notes to me with diff credentials it oculd work.

* SC: 403 can be forbidden for any reason. not just authorization.

* JB: in our case 403 seems more associated with authz butnot strictly either.

* KK: the lang in the spec

* SC: 405 is cheap.

* DZ: Might raise less support requests. 403 might raise more issues?

* DZ: We are encouraging UCs to allow read-only eg. archives, right?

* KK: I think current lang in the spec that allows that.

* DZ: that seems not a hard requirement. not difficult to implement.

* SC: that was intended. 'when', these are the rules.

* SC: {inaudible back and forth}

* DZ: KK, what's the downside to this approach?

* KK: ends up being tweaks in the Protocol. I think that to make this clearer, I'd introduce conformance classes and I don't want ot do that now. in that case read-only would be a conformance class

* DZ: why a conformance class?

* KK: doesn't change the behaviour but it owuld make it.

* SC: seems okay to me.

* DZ: but why an issue for tests?

* KK: I don't want to have the extra logic that would say that an apache server would be a com

* SC: that's a huge win IMO. why wouldn't an apache server be a conforming solid server if it does read-only?

* DZ: seems valid to me.

* KK: I prefer if we can say 0.9 today.. and we don't.

* SC: why is this issue/PR blocking 0.9?

* KK: if we do that, how would i test it? it is hard to test things in the spec. that is a problem.

* SC: i ack that concern.

* KK: even if we make must or not it doesn't.

* SC: but then people write the write operation bits but the code path will never be used.

* JB: what if the wording in the PR said - keep it exactly as you wrote it for read-write as MUST - but have OR must respond with 405 if they don't support these methods. if you add that at the tail of each statement, then you're being more explicit. so someone that's reading it, if i want to make a read-only server i can be compliant by with these specific methods for reading-writing then i return 405.

* KK: that is possible.

* SC: but we acknowledge that 405 can be returned for any reason (for any method ) for a particular resource.

* KK: every test we do.. we can in principle.. and not fail.

* SC: what would be the point of that?

* JB: if you're reading/writing this section on the MusT, tailing the statement with or provides room to someone that they can do read as an option. the key there is the or.