The Echidna run for this PR failed as the whole repo seems to be out of date with respect to the global local-biblio.js file. I assume that this will be resolved when @pchampin's PR #256 is merged.

Rebasing should mean this PR only has changes for spec/index.

Yes, indeed.

Perhaps I made a mistake in the way I rebased (I am not doing that so often). In my local version of the feature branch for this PR, I did:

git rebase main

After that, I did:

git pull

But the latter (pull) didn't work; git said I first have to do one of the following three things

1. git config pull.rebase false
2. git config pull.rebase true
3. git config pull.ff only

I did the second (because I thought that this is what I have to do in order to rebase). After that, git pull worked, and finally I did git push

The branch now has rewritten the 2 commits from main (different hashes) on top of your changes. that wil show up when merged to main (probbaly "skipped previously applied commit").

After git rebase, it should have been git push -fwhich replaces the remote branch with the updated local state.

Solution:

git rebase main # again.
# Ignore the  "skipped" messages
git push -f

and now the branch has the commit from main (same hash) and will be rebase-and-merge compatible with main.

As I've got that locally, I'll "push -f" the PR branch. (after - now 1 file changed).

After git rebase, it should have been git push -f which [...]

Thanks!

@TallTed, I included all your suggestions except for the one about code-fencing the keyword SELECT. That one I left out because, in this part of the spec, there are a lot of mentions of SPARQL keyword and none of them is code-fenced. Thus, code-fencing just this one mention of "SELECT" would be inconsistent with respect to the rest of this part of the spec.

I understand your thought process here, and I generally agree with consistency. However, I believe that all SPARQL keywords in all sections should be presented as code, just as you can see in lines 8622 and 8718 of this PR. I think the error is that "this part of the spec" does not already do so.

(I also think that the <b> and some <code> seen in the document through this PR are incorrect. I'm fairly certain that the variable <code>v</code> should become variable <var>v</var>. I don't know what the best marksup would be for Let <b>P</b>, <b>P1</b>, and <b>P2</b> be graph patterns nor and <b>E</b>, <b>E1</b>,..., through <b>En</b> be expressions, but I'm quite certain it's not <b>.)

@TallTed, I included all your suggestions except for the one about code-fencing the keyword SELECT. That one I left out because, in this part of the spec, there are a lot of mentions of SPARQL keyword and none of them is code-fenced. Thus, code-fencing just this one mention of "SELECT" would be inconsistent with respect to the rest of this part of the spec.

I understand your thought process here, and I generally agree with consistency. However, I believe that all SPARQL keywords in all sections should be presented as code, just as you can see in lines 8622 and 8718 of this PR. I think the error is that "this part of the spec" does not already do so.

I agree. But, again, if we implement such a change, it should be done in a dedicated PR.

(I also think that the <b> and some <code> seen in the document through this PR are incorrect. I'm fairly certain that the variable <code>v</code> should become variable <var>v</var>.

Yes, and then also in the table below that paragraph, as well as in the paragraphs below the table.

I don't know what the best marksup would be for Let <b>P</b>, <b>P1</b>, and <b>P2</b> be graph patterns nor and <b>E</b>, <b>E1</b>,..., through <b>En</b> be expressions, but I'm quite certain it's not <b>.)

These should all be <var>..</var>. Another issue here is that the table doesn't even use all these variables; it uses expr instead.

I agree. But, again, if we implement such a change, it should be done in a dedicated PR.

Fair enough. Created #260 to move that way.