Re: [xtm-wg] Issue with instanceOf

["Steven R. Newcomb" <srn@coolheads.com>]

Oops.  I wish to make a subtle but important disclaimer.

*Only* for the sake of improving the understanding of the
processing model, I wrote:

> ...if a topic were to somehow lose one of its memberships
> in some association, perhaps because the association is
> deleted, its memberships in various scopes would probably
> be completely unaffected.  I say "probably" rather than
> "certainly" because there is a possibility that the
> deleted association might have the topic in its scope, and
> it might be the only association in that scope, so the
> s-node might go away, too.  In that sense, then, the
> question of the existence of an association between topics
> might also be the question of the very existence of an
> s-node.

This sounds as if I was describing a processing requirement
for the Spec itself, by implying that there are occasions
when s-nodes have to be deleted.  There is no such
processing requirement.  Indeed:

* There is no requirement that nodes be deleted just because
  they aren't connected to other nodes in certain ways.

* It is even possible that, as implemented, a graph can
  always contain all the s-nodes that are possible, given
  the number of different topics that exist, regardless of
  whether they are actually used as the scopes of any
  a-nodes.  There is no reason why the Spec needs to
  constrain the behavior of implementations in such a way as
  to require that only the actually-used s-nodes are allowed
  to exist in a conforming topic map graph.  This is an
  example of a trade-off that implementers, and only
  implementers, should be allowed to decide about: is it
  better 

  (a) to limit the number of s-nodes in memory to those that
      actually serve as the scopes of a-nodes, or

  (b) to minimize the amount of work required to manage the
      graph's inventory of s-nodes by permitting unconnected
      s-nodes to hang around?

In general, we must avoid placing any unnecessary
constraints on implementations.  I was not trying to express
or create such a constraint in the passage quoted above.  I
was just trying to clarify part of the model, and, in
process, I'm afraid I created muddiness elsewhere.

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

405 Flagler Court
Allen, Texas 75013-2821 USA

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com