- From: David Brownell <david-b@pacbell.net>
- Date: Tue, 29 Feb 2000 10:25:52 -0800
- To: Ray Whitmer <ray@xmission.com>
- Cc: www-dom@w3.org
Ray Whitmer wrote: > > Unfortunately, this requires you to be able to detect whether > two node objects within a hierarchy represent the same node. > In some implementations, this can be done by using an == > comparison on the object references, but there is no guarantee > that the same object will always be returned for a specific node, The uncertainty is inherent in large scale systems; "identity" is a rather complex topic once you start to explore it. The short version of a _really_ long story is that object identity in a proxied/distributed system is a very hard notion. Within any small problem domain you can often make it testable. I've observed that people working exclusively inside one database tend to assume it's always testable (e.g. by tuple ID) while people integrating over wider data domains tend to assume the opposite. The convenient line is generally: within one address space, it may be practical to impose a policy that identity is testable, usually with a primitive like "==". As that single address space gets larger, that can become impractical ... and between address spaces it's often impractical to get trustworthy _and_ efficient answers. (Unless you turn it into a problem isomorphic with a single address space: master server and lots of clients or slave servers, for example.) > so this order comparison cannot be performed portably, unless I > missed something. The inability to compare node identity is an > omission that needs to be resolved. You don't need a strong notion of object identity in order to answer the ordering question. Ordering is a specific problem domain notion that is only incidentally related to the general problem of identity. - Dave
Received on Tuesday, 29 February 2000 13:26:15 UTC