I was looking at Jeremy Allaire's proposal for RSS-Data last night, and it made me think of a few things about RSS Data, and the Delta Web idea. First, I'd like to think that if people want to put foreign payloads into RSS feeds, then XML namespaces should be enough. You don't need to force people to use a specific markup - just because there are tools out there that can read this markup. the fact is, at some point an aggregator has to understand the domain specific meaning of a block of data, so the data may as well be encoded in the domain specific format associated with its domain namespace. Plus, isn't the whole idea behind a namespace to enable a set of XML tags to have a single, universal meaning (rather than a meaning relative to a document) - by way of the uniqueness of the namespace? I thought so... So, if someone wants to add data to an RSS feed that's outside the scope of RSS, then just use a namespace and be done.
But this got me to thinking about the Delta Web idea. In the Delta Web, I proposed using two references to identify a change. One was the reference to the context of the change (i.e. an XML document - for example), and the other one was a reference to the changed entity (i.e. an XPath reference to the changed stuff in the doc - for example). This is all well and good, except that if these are references, and there's no "copy" of the changed content, then it might be hard to find out what the content is if the original content has since changed. That's a mouthful I know.
here's what I mean. If I add an <event> element to my <calendar> XML document, and I create a Delta Web doc that identifies both the contextual ref, and the relative ref - that's great for right now. This is because an interested party (like my aggregator) could go to the original doc and find the reference to what changed, and read it - if it wanted to. But, now let's say that two minutes after I add the <event>, I decide to rip it out and replace it with a different <event>. And I'm a good boy and I update my Delta Web doc with two new entries - a delete and an add - and they exist right after the first one. Note - these three entries will all have different dates - so they're unique in the delta web sense.
However, if my aggregator reads the delta web doc and goes to the web doc trying to see "what" changed, it won't be able to find the first "added" entity. This is because the second change obliterated it. Oops. Well, wait a minute. maybe the job of the Delta Web is not to capture the content of the change, but just the metadata about it. That's the way I'm leaning. Maybe it's an extension of the Delta Web schema to have tags that might capture copies of the data that changes at each point. Why load up the Delta Web with all that change data if it's not even the job of the delta web to preserve the content of the change.
Of course, it would be easy enough to have an optional element in the Delta Web schema that would reference the changed content - or actually be a locally embedded copy of it. that's easy. I would just want to make it be optional. Also, I would want to be able to have my delta web doc define what changed - rather than necessarily be a complete re-buildable representation of how it changed.
This kind of ties back into my thinking of the Delta Web as being the first derivative of the web with respect to some parameter(s) like time. The derivitive function is not supposed to be something that enables rebuilding of the original function. To do that in math you need to integrate the derivative function with respect to some boundary conditions. Maybe the concept of "boundary conditions" is analogous to the concept of the data snapshot copies that could be optionally included or referenced by a Delta Web entry. I don't know.
Next, I think we need a trial schema for the delta web.
2:07:42 PM 
|
