Architecture of Preferences and Data
The GPII Personalization Framework takes a unique and powerful approach to data modelling and interoperability. Our goal is to enable developers to represent data, such as user preferences, in whatever formats and structures best suit their needs and implementation constraints. This "agree to disagree" approach emphasizes the fundamental mutability of simple data structures such as JSON, allowing the GPII Personalization Framework to easily adapt and transform data structures as needed in order to interoperate with others. Using the Model Transformation library that was developed for Fluid's Infusion application framework as a basis, the GPII development team will provide implementers with the tools necessary to use their preferred formats and structures while still retaining interoperability and compatibility with others.
The Preferences Server
The GPII Preferences Server is designed with a RESTful approach. REST, which stands for Representational State Transfer, is not new or obscure; it's actually the Web's architectural philosophy. In the RESTful approach, Web services are modeled as series of Resources, each with its own unique URL. Resources represent the content of the Web service, and are distinct from the many Representations, or formats that those Resources can be presented in.
In the case of the GPII Preferences Server, the primary Resource in the architecture is the user and their preferences. These will be identified by a URL such as:
http://preferences.gpii.net/users/<anonymous user token>/preferences
The Preferences Server will support multiple Representations of a user's preferences, corresponding to particular formats and structures that are optimized for distinct use cases and implementations. While the server will indeed provide a standardized JSON Representation, consisting of the preferences mapped as flat key-value pairs that correspond to the AccessForAll preferences registry, there will be other formats. For example, a more terse and hierarchical JSON structure suitable for the high-performance processing and interchange requirements of the GPII Personalization Framework. One can even imagine HTML Representations of the user's preferences, enabling them to review the preferences they've set and edit them accordingly.
example of flat preferences format
example of hierarchical preferences format
In each case where the the Preferences Server exposes a particular data Representation (in JSON format), there will also be an accompanying "schema" or map, describing how data structure corresponds to the underlying AccessForAll preferences registry. This will ensure that multiple formats can coexist harmoniously; each Representation will be self-describing, ensuring that implementations can easily understand the format and its meaning. Here's an example:
example of preferences schema
In this way, the GPII Preferences Server takes advantage of RESTful principles and self-describing Resources to ensure that we can widely interoperate, supporting the diverse needs and requirements of implementers.
The Role of JSON
JSON plays an important role within the GPII architecture. While we're committed to interoperating with other formats as needed, JSON provides several key advantages over competing formats such as XML. In particular, it maps directly to the core data structures supported by any programming language, device, and operating system. Its structure corresponds with the basic data types every programming is familiar with (such as numbers, strings, arrays, and dictionaries). Robust JSON parsers exist for just about every programming language and operating system known. The cost of parsing JSON is extremely low, both in terms of performance and code complexity; this makes it particularly well suited to use with mobile and embedded devices.
While JSON may initial seem to lack the features of a more complex format such as XML, those features are typically easily represented within JSON, and--when needed--support for things such as schemas is well-established. For developers, supporting JSON comes at a fraction of the complexity of XML.
Most importantly in the context of the GPII architecture, JSON's correspondence with the fundamental data types of computation mean that it can be easily traversed, understood and transformed. Unlike XML/XSLT, it's easy to write code and declarative rules to adapt, transform, and restructure data represented in JSON.
For these reasons, the GPII Personalization Framework will leverage JSON extensively throughout the core system, binding to other data formats whenever needed in order to support legacy applications and broad interoperability with code that may not have been designed with the GPII in mind.
The Role of Standards
Effective, easy to use standards are always driven and informed by working implementations.