I'll just leave this here:

http://www.indexdata.com/blog/2010/05/turbomarc-faster-xml-marc-records

That trade-off ought to offend both camps, though I happen to think it's quite clever.

MJ

On 2010-10-25, at 3:22 PM, Eric Hellman wrote:

> I think you'd have a very hard time demonstrating any speed advantage to MARC over MARCXML. XML parsers have been speed optimized out the wazoo; If there exists a MARC parser that has ever been speed-optimized without serious compromise, I'm sure someone on this list will have a good story about it.
> 
> On Oct 25, 2010, at 3:05 PM, Patrick Hochstenbach wrote:
> 
>> Dear Nate,
>> 
>> There is a trade-off: do you want very fast processing of data -> go for binary data. do you want to share your data globally easily in many (not per se library related) environments -> go for XML/RDF. 
>> Open your data and do both :-)
>> 
>> Pat
>> 
>> Sent from my iPhone
>> 
>> On 25 Oct 2010, at 20:39, "Nate Vack" <[log in to unmask]> 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
> 
> Eric Hellman
> President, Gluejar, Inc.
> 41 Watchung Plaza, #132
> Montclair, NJ 07042
> USA
> 
> [log in to unmask] 
> http://go-to-hellman.blogspot.com/
> @gluejar