Difference between revisions of "Architecture of Preferences and Data"

From wiki.gpii
Jump to: navigation, search
(Architecture, Implementation, and Standards)
(Architecture, Implementation, and Standards)
Line 90: Line 90:
** What techniques, algorithms, and data structures will implementers needs to use?
** What techniques, algorithms, and data structures will implementers needs to use?
** What performance characteristics will the proposal have?
** What performance characteristics will the proposal have?
* Are there existing implementations that provide this feature? How do they work?
* What alternative proposals might fit this same use case?
* What alternative proposals might fit this same use case?

Revision as of 01:52, 3 April 2012


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.

Flat, URL-keyed Preferences Profile in JSON Format

    "http://registry.gpii.net/accessforall/language": "fr-ca",
    "http://registry.gpii.net/accessforall/speechSynthesis/speechRate": 100,
    "http://registry.gpii.net/accessforall/keyboard/repeatKeysRepeatRate": 0.5
    "http://registry.gpii.net/accessforall/keyboard/repeatKeysAutomaticDelay": true

Hierarchical Preferences Profile in JSON Format Conforming to the Current ISO 24751 Standard

    user: {
        language: "fr-ca"

    display: {
        screenReader: {
            speechRate: 100

    control: {
        alternativeKeyboard: {
            repeatKeys: {
                repeatRate: 0.5
                automaticDelay: true

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:

    "user.language": "http://registry.gpii.net/accessforall/language",
    "display.screenReader.speechRate": "http://registry.gpii.net/accessforall/speechSynthesis/speechRate",
    "control.alternativeKeyboard.repeatKeys.repeatRate": "http://registry.gpii.net/accessforall/keyboard/repeatKeysRepeatRate"
    "control.alternativeKeyboard.repeatKeys.automaticDelay": "http://registry.gpii.net/accessforall/keyboard/repeatKeysAutomaticDelay"

In this example, keys within the hierarchical structure (separated by dots) are mapped to their corresponding AccessForAll Registry entries via their unique URI. Any application built in a Registry-aware way would be able to understand the meaning of this preferences profile, regardless of its particular structure.

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.

Architecture, Implementation, and Standards

Effective, easy to use standards are always driven and informed by working implementations. When it comes to personalization standards, the GPII Personalization Framework is being designed and architected to serve as a strong and viable implementation from which standardization decisions can be made.

Here are some of the key considerations for proposing a new feature or standard:

  • What is the use case, why do users need it, and what impact will the proposal have on them?
  • What are the particular strengths and weakness of the proposal in regards to implementation, such as:
    • How difficult will it be to implement?
    • What techniques, algorithms, and data structures will implementers needs to use?
    • What performance characteristics will the proposal have?
  • Are there existing implementations that provide this feature? How do they work?
  • What alternative proposals might fit this same use case?

In the case of new formats, query languages, or Domain Specific Languages (DSLs), a proposal should be accompanied by:

  • A working parser reference implementation that covers the full extent of the proposal's grammar, syntax, and semantics
  • A comparison of existing implementations and parsers