Remove SPARQL on GET

[RubenVerborgh]

• it’s a bad idea for scalability, DOS, and other reasons
• it’s not implementable the way it is written (subset not defined)
• it’s not implemented or used anywhere as far as we know

I strongly favor removal over deprecation (#205).

[dmitrizagidulin]

👍

[michielbdejong]

Looks like two members of the query panel already agree on this so could be a quick decision :) cc @kjetilk @justinwb.

[acoburn]

👍
I agree that removal is preferred over deprecation.

[RubenVerborgh]

@dmitrizagidulin Thanks, could you do that as a review, too? 🙂

@michielbdejong Not sure what part of process to follow here, given that this is not a normative section. We might or might not need a week for the public and approval by three editors; also unsure if I can merge. Assigning to you; feel free to unassign.

[dmitrizagidulin]

👍 to removing this section. (I remember that it's caused numerous confused questions from developers reading the spec, since it wasn't actually implemented.)

[kjetilk]

Actually, I am a bit conflicted, since I could see how it could be implemented easily, and I'm not sure very extensive edits are needed to the document at this point as we restart from scratch. It might just stay there for historical reasons. But OTOH, since it hasn't been implemented and has problems, it can be removed just fine too.

[RubenVerborgh]

@kjetilk The issue is that, whatever is in solid-spec, will end up in vNext; the only option to not have a feature end up in vNext is to remove it from solid-spec. So my main reason for creating this PR is to ensure that vNext does not have this security hole in it.

[kjetilk]

Very well, I understand.