Applications of IDness: Get it from the storage system (Was RE: [xml-dev] The XMLReader Interface, Chapter 7 of Processing XM L with Java)

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

From the second half of the article:

"So while we're full-blown XML, what we expose through the SOAP messages and
through the HailStorm 
data-manipulation layers has these XML boundaries coded into the system.
Then, once you have 
this node, you can throw it into a DOM and get finer-grained access to the
XML.

This red and blue thing is a core piece of the HailStorm model. We used to
have [other] names for 
these things, but the way it evolved is we would decorate our work with red
and blue decoration, 
and we finally ended up dropping the artificial names, deciding to call it
"red" and "blue" 
because that's how we think of it. Blue nodes have these properties and red
nodes have those 
properties.

Besides the difference in granularity, blue nodes become the cache-line
boundary for replication 
and for taking the information offline. For that to work, the boundary-the
blue node-has to be 
uniquely identified. So we have the "ID=" attribute-a unique ID for that
blue node. We generate 
that ID by hand out of the XML storage system. We also have a ripple-through
change number, 
which lets you take a cached copy of an address and look for addresses where
the change number 
is not equal to the one that I have in my hand. I either get a new one,
which will now become 
the definitive copy, or I get nothing and know that I'm in sync.

All of the HailStorm information follows the same basic pattern. It is
designed to be taken 
offline. It's designed to be highly cacheable so you can do things like take
your address 
book into your cell phone, update it from there, and keep up to date with
the master."

And they reinvented the geo-locator nodes of public safety systems.
Interesting.  Comment 
to MS:  public safety databases already have those mappable geo-locators.
We thank 
you for your adulation and support. :-)

len