The \ character is fine from a HTML or XML standards standpoint, it isn't considered to be an escape character or similar as it is in some other languages.
The only place it may trip up would be further downstream in the processing, if (and only if) the code that uses that entry to try and create or read any files in that location, and for the sake of C/C++/Java runtimes, it was expecting to use the value literally since then it would need to have been escaped like c:\\niku in order to work. These runtimes are also what allow for a unix-styled path to work against OS's that wouldn't normally support them (e.g. c:/niku).
I've not looked at this specific operation to see if an escaped or unix-style path would be necessary though, so this is just a blanket statement on the topic.
Browsers will often not apply an XML schema definition against the data they are showing in the browser window; instead they supply their own XSLT in order to perform syntax highlighting and colouring of the data they show (and in IE's case the collapse/expand javascript snippets). As such, the browser can only tell you if the XML is formed at a basic level (i.e. just as a bunch of XML characters, are they well-formed or not, such as missing end tags).
The complaint in this case comes in a stage that occurs after that where the XML is then validated against a schema, and it is found not to contain specific elements or other items where they were supposed to go. To resolve that, if the file isn't small enough to simply 'eyeball' it for a reason, then you will need to employ an XML parsing library that can perform multiple schema-definition validation parsing for you, which the msv.jar referenced in my posting will try and do for you (though it's just a developer library with a couple of command prompt invocations - it's not a rich or user-friendly client).