This page will hold a matrix summarizing the evaluations of various "short-list" candidates for the core-supported serialization format, as well as links to each individual format evaluation page.
For the time being, however, is consists of the general evaluation objectives (requirements and desired functionality) as well as a link to the stub evaluation page (coming as soon as this is posted) and some additional requirements.
Please do participate with edits and comments as you wish.
- Format must be able to represent what Drupal users will need.
- Basic static field types.
- Inter-resource links (entityreferences).
- Local media resources.
- Remote, 3rd-party media resources (Youtube, Flickr, etc.).
- Remote entities/resources (open profiles, etc.)
- Format must be able to support ad-hoc resource definitions (Drupal entities and bundles).
- Format must be able to be consumed by browser applications.
- Format must support UUID.
- There must be a PHP library for the format.
- The format must support collections.
- Format must be able to support both read and write data.
- Themed and unthemed content.
- How mature/stable is the format?
- What are the mid- to long-term prospects for the format?
- How active is the community developing and using the format?
- How mature, stable and active is the PHP library for generating and consuming the format?
- Does a Drupal module implementing the format in whole or in part already exist? Are the members interested in participating in the project?
- How complex is the format to understand/implement?
- Can the format easily be represented/mapped to both XML and JSON?
- Can the format represent semantics (tuples, etc.)? Support semantic querying? Be combined with other semantic formats, etc.?
- How prevalent is use of the format in the CMS space?
- How prevalent is use of the format among systems frequently interoperating with CMS systems?
- How elegantly, reasonably does the format represent a sampling of Drupal objects?
- Taxonomy Terms
- Media resources
- Layouts (in the D8 sense)
- Does the format support any sort of API discovery?
In order to support consitency across format evaluation, and to provide useful information as a product of the evaluation process, each format's specific abilities and approach is reviewed for significant components of each of the evaluation domains.
The domains were developed initially between Crell and ethanw on IRC (mostly Crell), and are open to suggestion and revision if there are any signficant use cases or considerations for a canonical representaiton format not currently covered.
The individual evaluation focus areas have been identified following some established resources and texts in the field, primarily the Rest API Rulebook[rest_rulebook], Building Hypermedia APIs with HTML5 and Node, and, of course, Feilding's Dissertation (more for inspiration), Architectural Styles and the Design of Network-based Software Architectures.
Please feel free to share any additional resources in the comments or in a list below.