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