Add possible semaphore mechanism wording

[kjetilk]

I'm proposing a draft of the wording I proposed in #322. I think this is the minimal change we can do to SPARQL that also legitimizes the behaviour in NSS with regards to the semaphore mechanism.

[csarven]

Should this be "if" or "when"? (I know sparq11-update says 'if' but context may be a bit different here.) Trying to first get a sense of where you want to go with this.

Didn't make this change but would consider whether the language should be closer to "abort the sequence of operations, causing the subsequent operations to be ignored" instead of "any modification".

Changed to sparql11-update reference as that's the specific spec being referred to.

server-patch-sparql-outside-subset is already in use. Changed to server-patch-sparql-abort for now -- not sure if that's specific enough.

[kjetilk]

Should this be "if" or "when"? (I know sparq11-update says 'if' but context may be a bit different here.) Trying to first get a sense of where you want to go with this.

Yes, I couldn't see the practical difference, and so I chose to align with the terms that was used in most of the sentence.

Didn't make this change but would consider whether the language should be closer to "abort the sequence of operations, causing the subsequent operations to be ignored" instead of "any modification".

As explained in #322 , this is a different thing, that applies when the request contains several operations, in this case DELETE INSERT WHERE is a single operation, so it doesn't apply. However, I recognize that "any modification" might not be sufficiently precise, as there might be side effects, you could have an audit log for example that is modified as a result of an aborted operation. I'm not sure that should tie us up right now though. I think we should stay focused on what would be sufficient for defining the current NSS behavior without departing too far from SPARQL.

[RubenVerborgh]

I just realized this is not going to work, because NSS rejects even if there are no variables: #322 (comment)

Whereas I personally think that this NSS behavior is the wrong behavior for Solid, it does mean that this PR does not achieve our goal.