Are you currently working as a web developer? If you are, then you already know 70% of what needs to be done. You just need to go out and seek clients. If not, I highly recommend you build at least one website from scratch, if only to convince yourself that you can do it.
I don't know how vibrant the tech scene is in Pheonix - if it's big, then focus on meatspace marketing: print out a stack of contact cards, and start handing them out at meetups and networking sessions. Make sure people know that you're available for a job.
If Pheonix's tech scene isn't so great, fret not. Focus on online marketing: your Linkedin profile, portfolios, personal sites and such. Post your profile somewhere public: HN's monthly freelancer site has been good to me.
How much to charge? I don't know, start with $2000/project for a small project, just to dip your toes in the water. If it works out, continue to raise your rates until you stop getting new clients.
Don't worry about contracting and invoicing - for contracts I use Word, for invoices I use Excel. I can't comment on how freelance income is taxed in the US - you definitely should check on that.
Nope. I use gmail exclusively as POP3/SMTP server. I can't imagine why someone would prefer using gmail web interface over some powerful desktop e-mail client (The Bat!, Thunderbird, Claws...).
Slack is a complex tool made for teams of developers and we are a more lightweight solution, made for regular people, with a focus on file sharing and file organization.
Same reason as SOAP/WSDL: there's good money in consulting so it would be stupid to do something that to simple, people might be able to solve their own problems.
Honestly I get that there an advantage in respect to tooling and this might ease integration into existing system, but I can't help feel that this is introducing an extra level of complexity that you would only find acceptable if you at IBM customer level scale.
The ability to introduce at least some type safety seems nice though.
Because there are already tool chains to handle XML with features not (widely) available for JSON, for example validation (XSD) and transformation (XSLT).
To use existing XML 1.0 tools on data that comes in as JSON.
It may be somewhat problematic that it doesn't actually support all JSON, because the characters that are permitted (even with escapes) in XML 1.0 text do not include all characters that can appear in JSON values, so if you use it on legal JSON that isn't constrained to be XML 1.0 compatible, it will do something wrong (the docs aren't clear on whether it will fail or just drop the offending characters), so the only place that it seems safe to use is in a constrained internal environment where you control "JSON" to mean "JSON using XML-1.0-safe characters".
This. I'm not claiming it is a good idea... But, DataPower is a highly optimized data processing network appliance for XML. It provides transform speeds with minimal latency, etc. So, to extend its capabilities to a new popular data format (JSON), they transform JSON to XML.
