> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Bill Dueber
> Sent: Monday, March 15, 2010 12:40 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Q: XML2JSON converter [MARC-JSON]
> 
> On the one hand, I'm all for following specs. But on the other...should
> we really be too concerned about dealing with the full flexibility of
> the 2709 spec, vs. what's actually used? I mean, I hope to god no one 
> is actually creating new formats based on 2709!
> 
> If there are real-life examples in the wild of, say, multi-character
> indicators, or subfield codes of more than one character, that's one
> thing.

Yes there are real-life examples, e.g., MarcXchange, now ISO 25577, being the one that comes to mind.  Where IFLA was *compelled* to create a new MARC-XML specification, in a different namespace, and the main difference between the two specification was being able to specify up to nine indicator values.  Given that they are optional in the MarcXchange XML schema, personally I feel that, IFLA and LC could have just extended the MARC-XML schema and added the optional attributes making all existing MARC-XML documents MarcXchange documents and the library community wouldn't have to deal with two XML specifications.  This is another example of the library community creating more barriers for people entering their market.

> BTW, in the stuff I proposed, you know a controlfield vs. a datafield
> because of the length of the array (2 vs 5); it's well-specified, but
> by the size of the tuple, not by label.

Ahh... I overlooked that aspect of your proposal.


Andy.