Dec 3, 2009 at 4:46 PM
Edited Dec 3, 2009 at 5:16 PM
What is it?
The purpose of Simple Feed Bindings (SFB) is to define XML namespace extensions that represent an application metamodel, where the metamodel describes the structure and properties of items that can be found in the feed. This allows publishers to understand
how to create or update items and it also allows subscribers to understand how to process them.
SFB was primarily designed to allow the creation of simple forms where both data and presentation aspects could be specified, allowing for heterogeneous applications and implementations to provide a common user experience. It was also designed so that
these simple forms could be dynamically updated such that the changes would propagate to all applications and implementations.
How did the need for it arise?
In August of 2006, members of the Concept Development Team attended the
Strong Angel 3 disaster response demonstration event. One of the main reasons for attending was to test how well
FeedSync would allow structured information to be shared in an environment with unreliable network connectivity and different applications/devices from different companies participating in the sharing.
In order to prepare for the event, members of the Concept Development Team created an XML based contact schema as the data to be shared during the event so that information about participants could be shared and updated with each other. The contact
schema was shared with other participants of the event, prior to the actual event, so that they would have time to make any necessary modifications to consume and produce the data.
FeedSync proved to be successful during the event with contact information being shared and updated between many applications/devices from Google, Microsoft, Adesso Systems, BlueForce and others. In some cases custom applications were used to consume
and produce the information, and in some cases feed readers and web applications were used. As the event continued, participants demonstrated the need for optionally capturing geographic information as part of the contact schema. The contact
schema was updated to including this information, but then a new challenge arose – how to communicate the changes to the other participants. Since no programmatic mechanism existed, members of the Concept Development Team had to verbally communicate
the changes and work with the other participants to make the necessary modifications. This was a very time consuming and error prone process, with multiple applications having to be recompiled and in some cases redeployed. Also, each application
chose to display a different UI for the newly added elements of the schema, which caused some confusion among participants. Finally it should be noted that not all of the participants chose to update the schema, but all still wished to participate in
After the Strong Angel event had finished, the Concept Development Team revisited what had happened with the contact schema. Essentially what had been demonstrated was:
The need for a common way to represent the schema for simple form based data
The need for a simple way to be able to add and update elements of the schema
The need to be able change schema while it was already being used
- The need for data created with the original schema work side by side with the updated schema
- The need to communicate the changes so that all participating applications/devices could be made aware of them
What were the requirements to be met?
The conclusion was that there was a need for a type of schema representation that would:
Be technology/connectivity/OS agnostic
Be simple enough such that a simple text editor could be used to create and maintain it
Be programmatically processed in order to determine elements of the schema
Be able to provide some visual hints/cues so that a common UI experience could be created by heterogeneous applications
Ultimately the decision was made to layer the schema representation on top of FeedSync feeds so that schema modifications followed FeedSync synchronization rules. This decision added the following requirements:
Be able to change the schema from any participating application/device (i.e. there is no single authoritative data source)
Provide a good experience for feed readers
- Not show up as feed items
- Provide a way for meaningful value to be set for the title and description of feed items
Why didn’t you use an existing standard or technology?
We really wanted to use something that already existed, and examined a variety of schema representations including (but not limited to)
Relax NG, XAML,
RDF. Representations were deemed non-viable for our purposes if one or more of the following occurred:
Require out-of-band references. We wish to avoid the complexity associated with synchronization for occasionally connected devices (e.g. how do I fix up URI/URL references locally vs. remotely)
Does not accommodate for providing visual hints/cues in addition to schema information.
Adds nontrivial increases to content size or complexity. We did not wish to make developers learn one or more other representations and then apply a subset of them - if an application developer has to write customized parsing code, we want it to
be as simple as possible.
After examining many schema representations – it was determined that none of them met all of the expressed requirements, so SFB was created. Again, we are not trying to boil the ocean here or succumb to “Not Invented Here” syndrome
- SFB should be viewed as one way for form based applications to express their data model. It is our hope that SFB starts a discussion about how to best build piping for lightweight, loosely coupled data meshes where the data and schema can evolve.