|
Hi Folks, Yesterday I wrote: Ø
Let me summarize the key ideas being discussed.
Ø
Please inform me of the parts that I misunderstand. Hmm, I pretty much got it all wrong. Hans sent me a message which brilliantly clears up my misunderstanding. He graciously granted me permission to post his
response: Roger, In detail... > We need an info space Yes, we do! But my conception of it is perhaps differs from yours. Here is mine: The info space is a forest of nodes within which XPath
can move freely. It is the possibility of unobstructed and very efficient movement, what transforms a heap of nodes into a space of nodes. The space must not be imagined - it must be perceived. I feel uneasy of talk about how distributed bits of information
may be combined in a novel way, obliterating the need to think of URIs etc..... when such thoughts seem to redefine the space, replacing something amazingly practical, real and powerful with something imagined and speculative, if not downright hazy. Imagination
is important, but when it blurs the essential it can be disastrous. The info space exists already: to be experienced and verified by any person mastering XPath/XQuery/XSLT. It is this perception and experience from where we must proceed, taking steps to broaden
and deepen the potential of the space -- pushing its boundaries, increasing its conductivity.
> We need domain-specific navigation axes I would prefer to express this point more generally, not insist on new axes, which are but one of several possible answers to a single basic problem: semantic
navigation, as opposed to structural navigation. (The generic axes are structural axes, as opposed to semantic axes; and an earlier version of the Balisage paper spoke of "data-driven navigation" vs. "structural navigation".) >
In an info space you don’t know where the data is
> physically located, so the generic navigation axes
> are useless. To me, the essence of the info space is XPath navigation in a node forest. Structural navigation is the very core of the XPath achievement. An emerging awareness
that it is not the answer to every question and that there is also the possibility of something else - navigation unawares of structural relationships - should not blur the proportions: structural navigation is and will remain the core, semantic navigation
might and should complement it. Frankly, I look at those domain-specific axes a little skeptically. At least until Michael will explain them in more detail. What is the semantic difference between
an axis and a function call, or a collection URI? An axis supplies us with a set of nodes which depends on our actual position. (This is, up to now, always a structural position, but might in future include a "content position", like the typed value of the
context node.) So does a function (properly written), when we communicate our position to it; and so does a filtered collection, if our position enters the filter. (In fact, axes are filtered collections, where the unfiltered collection is the sum total of
the context document.) But the concept of an axis seems to include the combination with a name test or a kind test. Is this really what we want, looking for vacant rooms? Functions hiding the structural knowledge seem to me more appropriate than axes, whose
implicit combination with node tests does not seem a natural fit in typical scenarios of semantic navigation (vacant rooms...). And Michael sounded as if he would accept functions in place of axes, too.
> We need to be able to define super structures that Yes we do. But those super structures should in my opinion not replace conventional documents, but complement them. > file sitting on your hard-drive. In the info space such
> documents don’t exist. The data that makes up an
> XML “document” may be scattered far and wide. To
> give the user the experience of a “document” we need
> to be able to define a super-structure layer on top of
> the scatter bits of data. Hans |