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" <njv...@wisc.edu> 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 > > e...@hellman.net > http://go-to-hellman.blogspot.com/ > @gluejar