Semantics of links to orgls

[Ravi Pandya <ravi>]

In the process of putting together the data structures to support docs
and links, some holes in the semantics have appeared, one minor, and
one that could be major.

The minor one is that there is currently no way to refer to "the
entire element at this part key" in a context path tree. For example,
if you wanted to link to the entire document, you could not just use a
null context path tree, because this would get you back a null orgl
when you followed it. Hugh and I came up with the notion of a
"wildcard" specifier, which would match anything below a given level
when doing a follow operation. Thus a link to an entire document would
have KEY(WILDCARD) as its context path tree; a link to the entire text
space of that document would have a single orgl [KEY(TEXT_SPACE) ->
KEY(WILDCARD)] as its CPT.

An alternative is to use a null orgl as a wildcard specifier. I think
that this is conceptually ugly -- using something to stand for its
opposite. It could also lead to problems if for some reason you wanted
to have a null orgl at the bottom of the CPT.

This problem becomes more serious if you look at it backwards: When
you have a link of this type, how do you find it on a backfollow?
Using the text space CPT above, if you backfollow from
KEY(TEXT_SPACE), you will get every TextualDoc in the known universe.
There is no unique EAddress like there is for links to actual
characters.

The particular case in which this arose was in trying to attach a link
end descriptor to a LinkEnd orgl using a link. Adding a wildcard makes
the link doable (CPT = [link id -> [FROM_END -> WILDCARD]]) but then
there is no way to find the link to the descriptor when you just have
the link end. It so happens that the link id is semi-unique (it is
only found referring to the same link in other versions of the same
document). We could thus backfollow from the link id, and do some post
filtering, to solve this particular problem.

However, I think that these kinds of links to parts of a composite
structure are going to be useful. How are we going to backfollow them?

MarkM suggested using a nested coordinate space for part keys: one
general key like TEXT_SPACE along with one unique key. This
complicates life substantially, more than I would be comfortable with.

So, there it is. Any suggestions?
	--ravi