I see your point. The original post doesn't address these issues, and I'm not sure it is ever designed to. If someone wanted to create a globally accessed, mul

I see your point. The original post doesn't address these issues, and I'm not sure it is ever designed to. If someone wanted to create a globally accessed, multi-language, all-encoding supported fully validated business information XML-RPC protocol they certainly wouldn't have arrived at "business.txt". The main problem it was trying to solve is to prevent business owners from having to update their information everywhere it ends up - not to ensure proper encoding (99% of applications would be happy with UTF-8) and formatting. In almost all use cases simply copying what was there and plopping it into a string would be fine. Which brings me back to my point about XML. A lot of the time, XML produces complexity that simply isn't necessary. Following the 80/20 rule, designing it for your specific use case will be multitudes faster and work fine for your target audience, no need to build an enterprise system and standard global protocol out of the gate.