https://www.w3.org/TR/xml-names/ says

All other prefixes beginning with the three-letter sequence x, m, l, in any case combination, are reserved.

under 3 "Declaring Namespaces".

Also https://www.w3.org/TR/REC-xml/ says

Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification.

under "2.3 Common Syntactic Constructs".

Change https://golang.org/cl/203417 mentions this issue: encoding/xml: namespace prefix case insensitive check

Can I help with anything?
The second version of my CL is simpler and more explicit, I hope.

Ping.

Thank you for filing this bug and for mailing the CL! I shall provide some feedback on your change, and awesome to have your contribution to the Go project!

@tgulacsi I sent some feedback to your CL about 20 days ago, please take a look, so that we can get it going before the code freeze. Thank you.

Sorry, haven't seen it.

Change https://golang.org/cl/240012 mentions this issue: doc/go1.15: remove encoding/xml doc

Change https://golang.org/cl/240179 mentions this issue: Revert "encoding/xml: fix reserved namespace check to be case-insensitive"

Reopening and retargeting for Go1.16 to address the raised cause of rollback during Go1.15.

Ping

@tgulacsi A minor point, but if you want us to review a change, please ping the change, not the associated issue. Thanks.

But now I'm not sure what is going on here. Is there a change to review? What is the ping for? Who are you pinging?

I'd like some directions - my previous CL was reviewed, accepted, then reverted.

Now I don't know what was the problem with it, what should I change to have it accepted - without information, I can only reissue the same CL.

Change https://golang.org/cl/254978 mentions this issue: encoding/xml: opt-in fix reserved namespace check to be case-insensitive

PTAL https://go-review.googlesource.com/c/go/+/254978 - it reintroduces the same code change, but puts it behind an Encoder option.

@tgulacsi Thanks for the context. I look at dozens of different issues every day, so I can't always keep them all in my head.

The CL that reverted your CL, https://golang.org/cl/240179, says "Reason for revert: This change changes uses of tags like "XMLSchema-instance" without any recourse" and refers to #39876. #39876 explains the problem, and you commented there. That issue has a test case whose behavior changed. Any change we make should not change the behavior of that test case, or other similar test cases.

The Go project takes backward compatibility very seriously. We do not want to break existing programs. There needs to be a very good reason to not do that. Perhaps we made a mistake in the fix for #5040, but we still don't want to break existing programs.

Worse, as #39876 says, after your earlier change (https://golang.org/cl/203417) there was no way for a program to get the string that it got before. So not only did the behavior change, there was no way to get the old behavior.

In your new CL (https://golang.org/cl/254978) you are introducing new API: a new method xml.(*Encoder).XMLPrefixCaseInsensitive. We usually use the proposal process for new API.

But first let's take a step back.

What is the real problem here that we are trying to solve? What goes wrong if we don't fix this? Perhaps you understand that, but I don't. Perhaps that can help guide us to the right solution.

Thanks.

From one of my clients, I got back this:

<bmRating xmlns:XMLSchema-instance="http://www.w3.org/2001/XMLSchema-instance" XMLSchema-instance:nil="true"></bmRating>

error: Prefix can't begin with XML: XMLSchema-instance

Prefixes beginning with "xml" (regardless of casing) are reserved for use by XML.

And https://www.w3.org/TR/REC-xml/ says she's right.

That's what I try to solve.

Sorry if this is a dumb question, but where is the string XMLSchema-instance coming from?

As far as I see, it's https://github.com/golang/go/blob/master/src/encoding/xml/marshal.go#L339 where it starts to pick a short name (tag?) for the namespace. If possible, it uses the namespace url's path's last section.

AFAIK a random name would work, too - that's why I don't understand what does it break.
That short name could be anything - though it cannot start with [xX][mM][lL].

@tgulacsi OK, I've looked into this, and I've come around to the view that you are correct: we should make this change and fix code that breaks.

Thanks for your patience with this.

Change https://golang.org/cl/264024 mentions this issue: encoding/xml: fix reserved namespace check to be case-insensitive

Thank you @ianlancetaylor and @odeke-em !
This is not a big issue for me, I have and use a not-so-simple-but-working workaround.

The big thing is that I thought I can contribute to the Go project, and have a tiny improvement on Go,
my beloved language, standard library and ecosystem.
I was in joy and then it's been rolled back.

So thanks again for looking again into it, and rolling forward!