What should the core dojo.data.core.Notification API look like (independent of how it appears in declarative bindings)  Here's some thoughts. this should be taken on the the contributors list for further discussion.

2. 1. programming model
      A) "Standard" Topics and message format

// Update notification for an item
itemTopicRoot = datastore.getNotifyTopic(item);

// Update notifications for the data itself
// (Example, a ATOM or RSS feed with retryEvery x minutes). 
// Clients can subscribe to be notified when new feed data arrives.
dataTopicRoot = datastore.getNotifyTopic();

// Notify callback any time item state is updated
dojo.event.topic.subscribe(itemTopicRoot+dojo.data.notify.UPDATED,callback);
dojo.event.topic.unsubscribe(itemTopicRoot+dojo.data.notify.UPDATED,callback);

// datastore can implement top-level data changed notification as follows...
    issueChangeRequest: function () {
        dojo.event.topic.publish(this.getNotifyTopic(), {
            oldData: this.oldData,
            data: this.data } );
    },

// datastore can implement item-level data changed notification as follows...
    dojo.event.topic.publish(this.getNotifyTopic(item)+dojo.data.notify.UPDATED, {             item: item,
            attribute: attributeName,
            oldValue: oldValue,
            newValue: value }
    },


B) Listener/Observer style

• addObserver(), removeObserver() ... similar to early dojo.data Observer api
• store.addObserver(item, callback)
  

CM: Concern with this approach is that the datastore will need to keep track/manage the observers.  ie. requires more infrastructure on datastore itself
Skinner: I'm think the observer approach may not require any more code inside the datastore than the topic appraoch -- and in either case, hopefully we can supply most of this infrastructure code in an abstract superclass, so that individual datastores don't need to do much work themselves. The advantage of the observer model is that it requires less code for the user:

• using an observer:
  • datastore.addObserver(item, callback);
• using a topic:
  • itemTopicRoot = datastore.getNotifyTopic(item);
  • dojo.event.topic.subscribe(itemTopicRoot+dojo.data.notify.UPDATED, callback);

CM  After thinking this over a bit more, I agree, we have two viable alternatives for implementing the observation of changes on items in a datastore. 1) topic based 2) listener based.  As you point out, the more important thing is that the store's api for registering an observer callback function upon state changes be as simple as possible. 
How about shorting the names to simply:

store.observe(item,callbackObj);
store.unobserve(item,callbackObj);

Next question is, what are the standard functions on the callback, eg. onUpdate, onCreate, onDelete...

store.observe(item,{
   onCreate:function (changedItem){...},
   onDelete:function (changedItem){...},
   onUpdate:function (changedItem,oldItem){...}});

Skinner: Looks good. A few thoughts:

• We might also want to be able to provide a scope object that the callbacks can be called on.
  
• For the onCreate callback, we'll want a way to register that callback that doesn't require you to pass in an item. (For example, in the case of an empty datastore, where you still want to be notified as soon as an item is created.)
• We'll probaby want a way to register interest in a bunch of items at once, or register interest in changes to *any* item in the datastore.
  
• We might want a shorthand to register a single callback function for any sort of observer notifaction (create, update, delete) -- maybe something like onAnyChange:

Maybe something like this:

store.observe({item:foo, onDelete:callback});
store.observe({onCreate:callback});
store.observe({items:[foo, bar, biff], onDelete:callback});
store.observe({onAnyChange:callback});
store.observe({
    scope:listener,
    onCreate:callbackOne,
    onDelete:callbackTwo,
    onUpdate:callbackThree });
var token = store.observe({item:foo, onDelete:callback});
store.unobserve(token);

2) events

Which state changing events should be tracked for items and attribute changes, and what granularity of change tracking?
What information is important for client applications observing the changes?
    eg. UPDATED: item, attributeName, oldValue, newValue
          UPDATED: oldItem, newItem  <== this can be the root of the data
          NEW: item
          DELETED: item
// Child update notification can be heavyweight to track, depending on native item implementation...do we need?
          CHILD_UPDATED: item 
          CHILD_REMOVED: item

Here are some examples of state tracking that we used in an early JSDO datastore implementation which tracked state changes at an item level...

JS DO Datastore state change constants
    //Client-side state changes
    UPDATED: 1,         //The value of this object has changed.
    NEW: 2,                 //This object is newly created.
    DELETED: 4,         //This object has been deleted.
    CHILD_UPDATED: 8,    // A child of this object has been updated or created.

    CHILD_REMOVED_OR_ADDED: 16,//A child of this object has been deleted