Can someone tell me the difference between XML and SOAP

I'm confused, i know SOAP is XML + HTTP, but then I read things saying "XML encode and decodes, and SOAP transports it." Anyone here can help me better understand?

I would like to know this as well, as I'm a bit confused by it myself.
Thanks!

I found this...

http://www.dotnettoday.com/articles/...tialdotnet.asp

XML--Data Encoded

To understand .NET you need to understand XML. XML, or the eXtensible Markup Language, is as foundational to .NET as the language we speak and write is to our own communication. We may have grand ideas and information to share, but if we can't communicate our ideas and information in a way that others can understand, our hard work and thought will lie fallow. XML is the lingua franca of .NET and is the basis for all .NET is and will become. Databases will read and write recordsets in XML. Web browsers will accept XML and display it when accompanied with style sheets. Visual Studio will even generate XML code! If you're not familiar with XML, you need to be. Without an understanding of XML and XML-related technologies you won't be able to communicate with .NET enabled resources (people or sites!).

Today, XML is nearly as ubiquitous as Web servers. Nearly every computing platform has the capability of parsing XML and therefore can retrieve the contents of the XML document. Windows can. Linux can. MVS and VMS certainly can. Even cellular telephones can! So if we can find a way to get the XML document to the remote system, odds are we can make sense of the data the document contains. As it happens, we ship the XML document using SOAP.

SOAP--Data Communicated

We've long used the HyperText Transport Protocol (HTTP) to ship Web pages and content to and fro. But when you combine HTTP (or some other Internet transport protocol) with XML and specify the format of the XML document itself you get the Simple Object Access Protocol, or SOAP for short. SOAP, at least as it was originally conceived, was designed to transport remote method calls from a local system to a remote one. What differentiates a SOAP-based architecture from other contemporary remote architectures--DCOM, CORBA, and RMI, to name a few,--is that the SOAP protocol can penetrate nearly every corporate firewall and the SOAP packets contain XML-encoded data, which is easy to parse and use. SOAP is also highly scalable, so we can serve a great number of users at one time.
SOAP is also highly scalable, so we can serve a great number of users at one time.

The SOAP model as originally conceived uses a request-response model, much like the Internet computing model we use today. (SOAP has since grown to include a messaging model.) The difference is SOAP encodes method arguments with the express goal of obtaining results for that method from the remote system. Instead of asking a Web site to provide me with a table of interest rates, for example, I can invoke a (as yet imaginary) remote method called CalculatePayment() on that same system and receive a personalized payment value. Yes, you can do that with a form today, but the point is there is a difference between invoking a service and submitting a form. Service invocation is a much more powerful concept.