Unfortunately, while we can reach an informal consensus on what's wrong and how it should be fixed, we don't actually have a process or authority for approving corrections to specs now that the WGs have disbanded.

@michaelhkay Ah, I understand. Would it be more productive for me to submit the PR against the XPath 4 branch?

Would it be more productive for me to submit the PR against the XPath 4 branch?

In principle, yes. Except that I've already fixed it. (Though perhaps not committed.) A general point though about using Git for development of XML specs - the mechanisms for merging independent changes don't work too well when the bulk of the content is large XML files. There tends to be too much formatting noise resulting from the fact that different contributors use different XML editors. It's generally better to describe the change in prose and let the editor apply the change.

Got it! I'll close this PR then.

plehegar marked as non substantive for IPR from ash-nazg.

Actually, there is a process to update the document, even if it has not been used so far:
[[
W3C may publish a Recommendation to make this class of change without passing through earlier maturity levels.
]]
https://www.w3.org/2020/Process-20200915/#revised-rec-editorial

It allows W3C to do the republication without an active Working Group.

To trigger this process, we follow:
https://www.w3.org/Guide/transitions?profile=REC&rec=editorial

In short, for editorial changes only, you need to prepare the new document and request re-publication by sending the request to webreq@w3.org . I recommend cc'ing me and Carine Bournez in the request (we can act as Document Contacts). You will NOT need Director's approval to do this republication.

Since this has not been used in the past, we may need to tweak the documentation to make this clearer, so feedback is welcome.

cc @caribouW3

btw, there is also a process to update the Recommendation with substantive changes. It involves sending an update request and asking for Director's approval. So, a bit more process but it also allows W3C to update the Recommendation without a Working Group.

@plehegar Very interesting - thanks for this info!

@michaelhkay I'm happy to help if I can and will follow your lead.

@plh I am not convinced that the Amended REC process is necessary or applicable here: this fix is likely a class 1 change ("fixes invalid markup"). At worse you could argue it's a class 2 change ("correcting non-normative code examples"). But Amended REC is intended for class 3 changes (normative changes that do not introduce new features).

https://www.w3.org/2020/Process-20200915/#correction-classes

I think in this case, the Team can just republish the REC with this fix included. As the text is there in the first place, but failing to display correctly due to being incorrectly marked up, I'd argue this is a class 1 change. A very strict reading of the process might conclude that this is a class 2 rather than class 1 because it changes the visible text of the example, and might also conclude that the Team can only do class 1 changes on its own, not class 2, and in that case we'd be forced to do an amended REC. I don't believe that was the intent of the Process, and the upcoming Process 2021 (as currently drafted) intends to clarify that the Team can indeed do class 2 changes. Whether you want to do an amended REC anyway, or wait for P2021 to roll out so that you're explicitly in the clear, or just do it now is kind of up to you, but personally, going to Amended REC for this seems overkill.

Thanks for the input on process. I'm not sure anyone has the energy to do the editorial work needed to fix trivial problems like errors in examples, unless this is part of a process that also involves fixing more substantial errata; but if someone is able to find the time, it's nice to know there's a process.

In the shorter term, it might be better to focus on creating an errata document at the location linked from the published specs.