profile
viewpoint
Kjetil Kjernsmo kjetilk Inrupt Inc. Hallenskog, Norway http://www.kjetil.kjernsmo.net/foaf#me Employee of Inrupt Inc. Ph.D. in informatics, with Semantic and Social Web as main interest. Master's in astronomy, with a general natural science interest.

ewilderj/doap 244

RDF schema for describing software projects

kjetilk/ConfigMerge 2

Load a configuration directory tree containing YAML, JSON, XML, Perl, INI or Config::General files

kjetilk/doe-sparql 2

Using statistical Design of Experiments in SPARQL Endpoint Evaluations.

kjetilk/CodeMirror2 1

In-browser code editor

kjetilk/2016-in-memorium 0

The RIP list in the #axkit-dahut topic got too long so we had to make a list ...

kjetilk/4store 0

4store

kjetilk/arduino_dimmer 0

This is the code I use to control the dimmers in my house.

kjetilk/arduino_fridgealarm 0

A thermometer for my refridgerator than sounds an alarm if the temperature is wrong

kjetilk/arduino_rdftemp 0

Pushing temperature sensor readout as RDF

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentsolid/specification-tests

Use tags on features/scenarios to allow skipping tests

 subjects: /data/test-subjects.ttl sources:   # Protocol spec & manifest-  # Editor's draft (fully annotated)-  - https://solidproject.org/TR/protocol+  # Editor's draft (Version 0.9.0 - https://solidproject.org/TR/2021/protocol-20211217)+  - https://solidproject.org/ED/protocol

The question here is what should be the default, the ED or the TR version. My feeling is the TR, since people should be implementing and verifying against a published and stable spec, but I'm open to other suggestions.

edwardsph

comment created time in 2 days

issue commentsolid/specification

Does the protocol spec govern exact status codes?

There was some discussion in https://github.com/solid/conformance-test-harness/issues/155 and following that, my suggestion is that we resolve this issue with the conclusion is that we sparingly bring upstream spec requirements (importantly HTTP) into the Solid Protocol spec, but that we create a comprehensive test suite that authoritatively details response codes, so that developers will be able to see if their implementation is compliant and since we link to requirements, also quickly see why.

RubenVerborgh

comment created time in 2 days

delete branch solid/specification-tests

delete branch : fix/unimplemented-methods

delete time in 2 days

PR merged solid/specification-tests

Reviewers
Remove the DAHU test

Following https://github.com/solid/conformance-test-harness/issues/155 I'm proposing the remove the corner case evil DAHU method test to. Instead, this has a TRACE test, which is in HTTP but not in Solid.

Unfortunately, it is hard to have a conditional test now, and previously, I also checked the Allow header as that should be on every 405 but with this variability, it is hard to do, so I removed it for now.

+10 -9

0 comment

1 changed file

kjetilk

pr closed time in 2 days

push eventsolid/specification-tests

Kjetil Kjernsmo

commit sha bfb8937bfc9cf87643a62c0fa8012291d33f4a26

Remove the DAHU test

view details

Kjetil Kjernsmo

commit sha 403c7bf404175db113b478a940981e3a1ab71347

Update protocol/read-write-resource/method-not-allowed.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 9112ef3869c6b7b48974d876204fcd47ae67488c

Update protocol/read-write-resource/method-not-allowed.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 477fae072eb9c93312e6028c9e27b80cdf8c7fe6

Update protocol/read-write-resource/method-not-allowed.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 36d4e445c10b50ad3eed4691a844a0aebb09c3dc

Merge pull request #71 from solid/fix/unimplemented-methods Remove the DAHU test

view details

push time in 2 days

push eventsolid/specification-tests

Kjetil Kjernsmo

commit sha 477fae072eb9c93312e6028c9e27b80cdf8c7fe6

Update protocol/read-write-resource/method-not-allowed.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

push time in 2 days

push eventsolid/specification-tests

Kjetil Kjernsmo

commit sha 9112ef3869c6b7b48974d876204fcd47ae67488c

Update protocol/read-write-resource/method-not-allowed.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

push time in 2 days

push eventsolid/specification-tests

Kjetil Kjernsmo

commit sha 403c7bf404175db113b478a940981e3a1ab71347

Update protocol/read-write-resource/method-not-allowed.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

push time in 2 days

PullRequestReviewEvent

Pull request review commentsolid/conformance-test-harness

Use tags to skip inapplicable tests

         <commons.text.version>1.9</commons.text.version>         <commons.cli.version>1.5.0</commons.cli.version>         <wiremock.version>2.27.2</wiremock.version>-        <solid.vocab.version>0.0.12</solid.vocab.version>+        <solid.vocab.version>0.0.13</solid.vocab.version>

does pom.xml need to be checked in?

edwardsph

comment created time in 2 days

PullRequestReviewEvent

PR opened solid/specification-tests

Remove the DAHU test

Following https://github.com/solid/conformance-test-harness/issues/155 I'm proposing the remove the corner case evil DAHU method test to. Instead, this has a TRACE test, which is in HTTP but not in Solid.

Unfortunately, it is hard to have a conditional test now, and previously, I also checked the Allow header as that should be on every 405 but with this variability, it is hard to do, so I removed it for now.

+10 -9

0 comment

1 changed file

pr created time in 2 days

create barnchsolid/specification-tests

branch : fix/unimplemented-methods

created branch time in 2 days

issue commentsolid/conformance-test-harness

Failed to send authorized request / header parser received no bytes

I tend to be OK with us not formulating a lot of HTTP requirements in the spec, but when it comes to testing, I think it is very important to be helpful and have tests for an authoritative understanding of underlying specs.

As I said in spec#288, pragmatically, a developer should be able to go with their intuition and be confident that if their intuition is wrong, they will fail a test, and then they can discover an authoritative answer by inspecting the test (which we are very conscious about making easy). Or they can suggest a change. If we don't specify anything/much from HTTP and also have no tests because we don't have references to attach it to, then we are being very unhelpful.

We are already going in a rather different direction that I would like to, since we don't encode a lot of the understanding in tests, and so we're not being terribly helpful already. I would not want to take it even further in that direction.

We could of course make a "Solid Authoritative HTTP test suite" separate from the protocol test suite. That might actually be a good idea.

RubenVerborgh

comment created time in 2 days

issue commentsolid/conformance-test-harness

Failed to send authorized request / header parser received no bytes

Yeah, it seems to be rather in conflict with the gist of https://github.com/solid/specification/issues/288

RubenVerborgh

comment created time in 2 days

issue commentsolid/conformance-test-harness

Failed to send authorized request / header parser received no bytes

That's not correct IMHO: we can test good and bad Solid paths. Just not (good or bad) non-Solid paths.

Sure, but there really isn't a lot of bad Solid paths left with the way that we're formulated the spec... It makes me concerned for the overall health of the ecosystem.

RubenVerborgh

comment created time in 2 days

issue commentsolid/conformance-test-harness

Failed to send authorized request / header parser received no bytes

I think there is a more general problem here: There seems to be tension when we're trying to close the world. Whenever we're just specifying an open world, it is easy to test, but not very interesting, because you can only test the good path. The open world has quite a lot of affordances, you can in principle respond to every request with a 405, "you're not allowed to do anything here", or a 501, "it's OK to ask, but no" but closed world is interesting because it allows to test things that shouldn't happen, because they may have harmful effects.

I can go with 400 in this case (although I agree with some of the commenters there that Node should not make that decision). I think it is important to close the world in situations where the user may be exposed to manipulation, but in this case, it should suffice that the server does not change the state of the target resource and sends an error, which is kinda trivial, and yet, what I wanted to test.

RubenVerborgh

comment created time in 2 days

push eventsolid/specification-tests

Kjetil Kjernsmo

commit sha 0828dc81995fe3572a8980bdd4ddf44819fa16aa

Add Allow header tests

view details

Kjetil Kjernsmo

commit sha da22cc2509bda7819615f6ced311c2c8b2f1d104

Add Allow header tests

view details

Kjetil Kjernsmo

commit sha c42f209b008ec6923726cb3e644d81093d29e192

Use And keyword

view details

Kjetil Kjernsmo

commit sha fc235ee17a191460648294056e74462233683854

Test for POST to non-existing

view details

Kjetil Kjernsmo

commit sha c53affaa5c04cf055c38546f599fdc0d41793016

Add more content-types

view details

Kjetil Kjernsmo

commit sha b3aa723420cedea2ec0032922546ea66965b9d47

First test for deleting containment triple

view details

Kjetil Kjernsmo

commit sha 64389522e8152514c3f0504425319092808a341c

Move test resource creation

view details

Kjetil Kjernsmo

commit sha 6d76af04f5b4954890268307bd8ee1f099094732

Add container removal

view details

Kjetil Kjernsmo

commit sha 32bc72fd3bb9e2bd812665d5332f5fec06fc8f59

Add test for text resource

view details

Kjetil Kjernsmo

commit sha b650f2f90364bd3266e8056ce1f0c1aeab261abc

First test for protected container

view details

Kjetil Kjernsmo

commit sha d9c1dac2782adc3708ef3c91e8a359771eb4a3fa

Tests for other resources

view details

Kjetil Kjernsmo

commit sha 5fad293316540668c80dfe8db04c4ff58fcc934e

Update protocol/solid-protocol-test-manifest.ttl Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 766349806ead803cafe25d51fa2d679854630064

Update protocol/solid-protocol-test-manifest.ttl Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 3e4319280c81dade2949ab704e8612560f2da45b

Update protocol/solid-protocol-test-manifest.ttl Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha f7712ff323bae2f088e3a26d374add484573832d

Update protocol/read-write-resource/read-method-allow.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha a3ed9415d8de59de2add1c7be28fda24a5290df2

Update protocol/read-write-resource/read-method-allow.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 6f1282e564fcb6da15ef50d7a56baed0672eda76

Update protocol/solid-protocol-test-manifest.ttl Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 3127b7a4028345f15f7b138f0c14b533b5fb38c9

Update protocol/writing-resource/delete-protect-nonempty-container.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha b53202b3061037d0fde228559f4a76cf0e608699

Update protocol/writing-resource/delete-protect-nonempty-container.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

Kjetil Kjernsmo

commit sha 0f86cc84617fffbda4a626a1f2aad37ed057c4ee

Update protocol/writing-resource/delete-protect-nonempty-container.feature Co-authored-by: Pete Edwards <edwardsph@users.noreply.github.com>

view details

push time in 4 days

pull request commentsolid/specification

Restriction to only respond to authorized with Allow et al

Two scenarios with public access:

1. If a resource has public append permissions, and supports public POST say, then the app needs to know that that is possible.  Does it get Allow: POST in the first GET it does, even though unauthenticated?

Yes, it does, that is my interpretation of HTTP.

2. If a resource has public read only but private Append, then the app will do what -- read unauthenticated and get Allow GET, then prompt the user to  log in, to a head, and then check that it has Allow: POST ?

In that case, it will see Allow: POST in both cases, which indeed isn't terribly useful (and I haven't found Allow to be very useful), but in that case, the app will find WAC-Allow more useful, right? Isn't the intention of WAC-Allow to address exactly that kind of problem?

kjetilk

comment created time in 4 days

pull request commentsolid/specification

Introduce constraint on PATCH to only patch target resource

I absolutely see multi-resource patches as desirable, and atomic ones important too.

The question is whether that should be going through this kind of interface.

My concern is that users may be duped by apps, possibly because the app has a vulnerability, to modify a resource they didn't intend to modify. I'd like to plug that possible hole at the protocol level.

To support multi-resource updates in a single request, I don't think a resource-centric interface makes sense, it is not a single resource anyway. In that case, thinking in terms of endpoints (e.g. a SPARQL endpoint) makes much sense, and I suppose you could do this already using the SPARQL Protocol.

kjetilk

comment created time in 4 days

pull request commentsolid/conformance-test-harness

Improve raw http send method and http client

This will close https://github.com/solid/specification-tests/pull/69 I presume?

edwardsph

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentsolid/conformance-test-harness

Improve raw http send method and http client

 public String getUser() {         } else {             builder.method(method, HttpRequest.BodyPublishers.noBody());         }+        if (version != null) {+            builder.version(HttpClient.Version.valueOf(version));+        }

OK, I suppose this may answer my question in https://github.com/solid/specification-tests/pull/69 ?

edwardsph

comment created time in 5 days

PullRequestReviewEvent

pull request commentsolid/specification-tests

Document additional version param on send method

One thing, though: Do I need to send HTTP version with every send* request always? Or is there a default?

edwardsph

comment created time in 5 days

PullRequestReviewEvent

pull request commentsolid/notifications

Replace separate gateway endpoint with RDF-based protocol discovery

I agree on describing https://websocket.example/subscription , but then for it to be fully self-describing, it should be an RDF document and respond to GET, HEAD.

If it can do that, great.

Exposing its description in another resource is not what's generally considered as self-describing.

and if it can't, I wouldn't take a dogmatic approach to self-description, and still do it even though it wouldn't be self-describing. It would be a better knowledge graph, and when there's tension between self-description and knowledge graphs, then I would rather side with the knowledge graph, because, if you don't, what use is RDF?

acoburn

comment created time in 6 days

more