Related work

There have been a number of approaches to defining an exchange format for constraint models.

The seminal OPL language [VanHentenryck99] provides a modelling language for constraint programs, which is linked to Ilog's solver products. Its use an exchange format is limited by its proprietary background. MiniZinc [NethercoteStuckeyBecketBrandDuckTack07] is a subset of the Zinc modelling language intended to be compiled to multiple solver implementations. First, a model in FlatZinc is generated from the MiniZinc model, removing all iteration (respectively recursion). The flat model can then be compiled into different solver implementations, currently Mercury, ECLiPSe and Gecode. The development of new back-ends is facilitated by the co-development of the Cadmium [StuckeyGarciadelaBandaMaherMarriottSlaneySomogyiWallaceWalsh05] term-rewriting system, which can parse and transform FlatZinc code.

The work most closely related to our format probably is the XML format used for the CSP solver competitions [DongenLecoutreRoussel08]. We reviewed an earlier draft version before generating our own schema for the catalogue, the 2007 version (for the 2008 competition) is described in [XCSP2008]. It is intended as a solver independent format, which can be used by all participants of the competition. As a design choice, the authors decided not to fully structure the format, e.g. to use string values to hold structured information. In order to understand the actual meaning of the model, these strings need to be parsed and analysed as well. This may have size advantages for CSP data given in extensional form, but makes it more complex to check validity of a data file.