 |
 |
Let me openly state that I've never used Turbomarc. I believe the "special case" they are referring to is the subfield code with a value of "η", which is non-alphanumeric. I don't know enough about MARC to even begin guessing what this means or why it might occur (or not). The use case I see for Turbomarc is when you: 1- have a need for high performance 2- are converting binary MARC to XML 3- are writing your own XSLT to manipulate that XML (since it's not MARCXML) The first comment claims a 30-40% increase in XML parsing, which seems obvious when you compare the number of characters in the example provided: 277 vs. 419, or about 34% fewer going through the parser. But, really, look at that XML (if it can even be called that). Turbomarc somehow manages to make MARC even more inscrutable. But hey, it's fast. MJ On 2010-10-28, at 11:35 AM, Cory Rockliff wrote: > I've only just had a chance to catch up on this thread. I'm not offended in the least by Turbomarc (anything round-trippable should serve just as well as an internal representation of MARC, right?), but I am a little puzzled--what are the 'special cases' alluded to in the blog post? When would there ever be a non-alphanumeric attribute value in MARCXML? Is this a non-MARC21 thing? > > C > > On 10/25/10 3:35 PM, MJ Suhonos wrote: >> 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 >> --- >> [This E-mail scanned for viruses by Declude Virus] >> >> >> > > > -- > Cory Rockliff > Technical Services Librarian > Bard Graduate Center: Decorative Arts, Design History, Material Culture > 18 West 86th Street > New York, NY 10024 > T: (212) 501-3037 > [log in to unmask] > > BGC Exhibitions: > In the Main Gallery: > January 26, 2011– April 17, 2011 > Cloisonné: Chinese Enamels from the Yuan, Ming, and Qing Dynasties > Organized in collaboration with the Musée des arts Décoratifs, Paris. > In the Focus Gallery: > January 26, 2011– April 17, 2011 > Objects of Exchange: Social and Material Transformation on the Late-Nineteenth-Century Northwest Coast > Organized in collaboration with the American Museum of Natural History > > --- > [This E-mail scanned for viruses by Declude Virus]