|
|
GeneralPrinciplesForSchemas
General principles for Jangle schemas
...and ILS/LMS schemas more generally.
The Principles
Jangle schemas should be developed bearing the following principles in mind:
- They should be as generic as possible: likely to offer representations for all the data any library system could store.
- They should accommodate the reality that there is no way such generic schemas will be able to capture all the variability of real library system data. So the representations offered must be extensible via standard mechanisms.
- They should be expressible using an XML schema language (e.g. XML Schema or Relax-NG).
Given these principles, ideal formats for storage are those already in widespread use. For example, RDF is particularly appropriate because it is simple and extensible. Extensions of RDF to other widespread formats (e.g. vCard RDF) should be preferred over proprietary (e.g. Talis-specific) or vertical (e.g. NCIP) formats.
Library-specific formats should also be considered. But we want to keep the core schemas generic to the extent that they are usable outside the library domain.
Schemas we're working on
Issues
(These are implementation issues, rather than issues with the idea of using XML schemas.)
- Rails doesn't have class definitions for model classes - the schemas we're outlining here are going to very often be for models, e.g. borrower, loan, reservation, item. Do we just keep this informal (have an XML spec. which we code our Jangle models to); or do we find a way to extract model metadata from Jangle's "ideal" models (perhaps from migrations - though that seems bad); or use a different ORM like DataMapper which stores properties on classes; or something else. I suppose we want to stay with ActiveRecord for now, as it's integral to Rails - so perhaps we need a way to have "ideal" models which are extended in actual connectors, or which connectors convert their own model classes to. DesignByContract for Ruby? Not sure about that.
Sign in to add a comment