Yes, it is designed to be a round-trippable expression of ordinary marc 
in XML. Some reasons this is useful:

1. No maximum record length, unlike actual marc which tops out at ~10k.
2. You can use XSLT and other XML tools to work with it, and store it in 
stores optimized for XML (or that only accept XML), etc.
3. You can embed it inside XML schema's that allow arbitrary embeddable 
XML.
4. (Of much lesser importance than these others, but still ends up being 
important to me -- saving the time of the developer does matter) it's a 
lot easier to debug the raw data, doesn't require me to open up a hex 
editor and count bytes.

Nate Vack wrote:
> Hi all,
>
> I've just spent the last couple of weeks delving into and decoding a
> binary file format. This, in turn, got me thinking about MARCXML.
>
> In a nutshell, it looks like it's supposed to contain the exact same
> data as a normal MARC record, except in XML form. As in, it should be
> round-trippable.
>
> What's the advantage to this? I can see using a human-readable format
> for poorly-documented file formats -- they're relatively easy to read
> and understand. But MARC is well, well-documented, with more than one
> free implementation in cursory searching. And once you know a binary
> file's format, it's no harder to parse than XML, and the data's
> smaller and processing faster.
>
> So... why the XML?
>
> Curious,
> -Nate
>
>