I guess what I meant is that in MARCXML, you have a <datafield> element with subsequent <subfield> elements each with fairly clear attributes, which, while not my idea of fun Sunday-afternoon reading, requires less specialized tools to parse (hello Textmate!) and is a bit easier than trying to count INT positions. One quick XPath query and you can have all 245 fields, regardless of their length or position in the record.


On 2010-10-25, at 3:26 PM, Nate Vack wrote:

> On Mon, Oct 25, 2010 at 2:09 PM, Tim Spalding <[log in to unmask]> wrote:
>> - XML is self-describing, binary is not.
>> 
>> Not to quibble, but that's only in a theoretical sense here. Something
>> like Amazon XML is truly self-describing. MARCXML is self-obfuscating.
>> At least MARC records kinda imitate catalog cards.
> 
> Yeah -- this is kinda the source of my confusion. In the case of the
> files I'm reading, it's not that it's hard to find out where the
> nMeasurement field lives (it's six short ints starting at offset 64),
> but what the field means, and whether or not I care about it.
> 
> Switching to an XML format doesn't help with that at all.
> 
> WRT character encoding issues and validation: if MARC and MARCXML are
> round-trippable, a solution in one environment is equivalent to a
> solution in the other.
> 
> And I think we've all seen plenty of unvalidated, badly-formed XML,
> and plenty with Character Encoding Problems™ ;-)
> 
> Thanks for the input!
> -Nate