As soon as I started thinking about the issues of multiple language programs interacting with the same couchdb documents, I immediately started down the primrose path of schemas. Of course, I thought about storing those schemas in couchdb itself, and that meant a json-based schema. There is a reasonably comprehensive approach to javascript schemas that tries to avoid some of the complexity of xml schemas, but in doing so it misses some of the key information needed to address schema versions. The “json hyper schema” at least addresses the addressability aspect but (implicitly) leaves revisions to the semantic flexibility of URIs.

In implementing a solr search for a CouchDB application, I was struck by another value of internal schemas- being able to translate your document schema to something entirely-other applications could understand. Well, I did that by hand… not sure whether there’s any real chance that any automated schema mapping is really possible.

The more I look at these issues, however, the more I feel like you either punt entirely, have a simple name as your type, and live with “running code and rough consensus“, or you have to swallow all the complexity that’s been implemented in XML-land. In which case, I’m not re-inventing relax-ng just because I like curly-brackets better than angle brackets.

Thus, for the moment I intend to punt on schemas at all, with the idea that I’ll use json->xml translation and then the rich set of schema tools in xml whenever there’s sufficient reason for going there.

Still feel like I should at least offer a revision string for type.