On Fri, Mar 5, 2010 at 1:10 PM, Houghton,Andrew <[log in to unmask]> wrote:

>
> I decided to stick closer to a MARC-XML type definition since its would be
> easier to explain how the two specifications are related, rather than take a
> more radical approach in producing a specification less familiar.  Not to
> say that other approaches are bad, they just have different advantages and
> disadvantages.  I was going for simple and familiar.
>
>
That makes sense, but please consider adding a format/version (which we get
in MARC-XML from the namespace and isn't present here). In fact, please
consider adding a format / version / URI, so people know what they've got.

I'm also going to again push the newline-delimited-json stuff. The
collection-as-array is simple and very clean, but leads to trouble
for production (where for most of us we'd have to get the whole freakin'
collection in memory first and then call JSON.dump or whatever)
or consumption (have to deal with a streaming json parser). The production
part is particularly worrisome, since I'd hate for everyone to have to
default to writing out a '[', looping through the records, and writing a
']'. Yeah, it's easy enough, but it's an ugly hack that *everyone* would
have to do, as opposed to just something like:

  while (r = nextRecord) {
     print r.to_json, "\n"
  }

Unless, of course, writing json to a stream and reading json from a stream
is a lot easier than I make it out to be across a variety of languages and I
just don't know it, which is entirely possible. The streaming writer
interfaces for Perl (
http://search.cpan.org/dist/JSON-Streaming-Writer/lib/JSON/Streaming/Writer.pm)
and Java's Jackson (
http://wiki.fasterxml.com/JacksonInFiveMinutes#Streaming_API_Example) are a
little more daunting than I'd like them to be.

Not wanting to argue unnecessarily, here; just adding input before things
get effectively set in stone.

 -Bill-

-- 
Bill Dueber
Library Systems Programmer
University of Michigan Library