Change the name of the normalize function

[JesseKPhillips]

While D has good tools to handle name conflicts it can still be useful to avoid needing to use them. And std.uni.normalize seem likely to be a function that might be imported when dealing with XML and so I believe that avoiding the conflict all together would be a good choice.

[jmdavis]

I don't know. I don't entirely disagree, but I have no clue what else to name it, and the language does provide good ways to disambiguate. normalize is the best name that I could come up with, and I don't want to go with a bad name just to avoid naming conflicts. What would you suggest it be called?

[JesseKPhillips]

Well, technically I think decode is closer as we have it std.xml already, though that doesn't solve the conflict problem because std.utf also has decode. unescape could work.

[jmdavis]

Hmm. Well, unescape seems decent, though it doesn't work as well in the sense that removing carriage returns doesn't involve escaping or unescaping anything. If we had unescape, then the reverse would be escape, whereas right now, we have normalize and the opposite (which hasn't been released yet) is currently denormalize, which I'm not a big fan of. Maybe escapeXML and unescapeXML? I don't like that they don't fit the carriage return behavior very well, but they could still be better overall. I'll have to think about it. Whatever I end up with, hopefully I can avoid a bunch of bikeshedding when it finally comes time to try and get dxml through the Phobos review process.

[ghost91-]

kxml, the XML library I was using before the release of dxml, calls those functions xmlDecode and xmlEncode, which seems a good fit (though I'd prefer encodeXML and decodeXML and escapeXML, unescapeXML would also be fine imo). However, those functions don't about \r. The fact that we have difficulty in finding a proper name for the function because of handling \r leads me to think that maybe it should not be handled in the same function.

A side note: I think handling of \r is not done correctly at the moment: If I understand the code correctly, normalize simply strips all occurrences of \r. However, the correct behaviour as by the XML spec is to replace both any 2 character sequences \r\n and any \r not followed by a \n by a \n (see https://www.w3.org/TR/REC-xml/#sec-line-ends).

[jmdavis]

However, those functions don't about \r. The fact that we have difficulty in finding a proper name for the function because of handling \r leads me to think that maybe it should not be handled in the same function.

Handling them in a separate function means processing the data twice to strip out the carriage returns and transform the character entities. So, I don't think that it really makes sense to separate that into two separate functions.

A side note: I think handling of \r is not done correctly at the moment: If I understand the code correctly, normalize simply strips all occurrences of \r. However, the correct behaviour as by the XML spec is to replace both any 2 character sequences \r\n and any \r not followed by a \n by a \n (see https://www.w3.org/TR/REC-xml/#sec-line-ends).

That's not quite true. https://www.w3.org/TR/REC-xml/#sec-common-syn also talks about either removing \r or replacing it with \n, so it would be correct for the parser to either ignore \r or treat it as \n. So, for everything except for counting lines, the parser treats it as \n, since that's the simplest. Regardless, it's impossible for the parser to actually do anything to \r while parsing, because it returns slices of the input, and so all of the carriage returns must be left in - which is why normalize then strips them out. For better or worse, the spec gives leeway on how to handle carriage returns, and what dxml does takes advantage of that.