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.

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.

On Mon, Mar 15, 2010 at 11:22 AM, Houghton,Andrew <[log in to unmask]> wrote:

> > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> > Jonathan Rochkind
> > Sent: Monday, March 15, 2010 11:53 AM
> > To: [log in to unmask]
> > Subject: Re: [CODE4LIB] Q: XML2JSON converter [MARC-JSON]
> >
> > I would just ask why you didn't use Bill Dueber's already existing
> > proto-spec, instead of making up your own incomptable one.
>
> Because the internal use of our specification predated Bill's blog entry,
> dated 2010-02-25, by almost a year.  Bill's post reminded me that I had not
> published or publicly discussed our specification.
>
> Secondly, Bill's specification looses semantics from ISO 2709, as I
> previously pointed out.  His specification clumps control and data fields
> into one property named fields. According to ISO 2709, control and data
> fields have different semantics.  You could have a control field tagged as
> 001 and a data field tagged as 001 which have different semantics.  MARC-21
> has imposed certain rules for assignment of tags such that this isn't a
> concern, but other systems based on ISO 2709 may not.
>
>
> Andy.
>



-- 
Bill Dueber
Library Systems Programmer
University of Michigan Library