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,

Cordial thanks for starting this discussion and now presenting a summary! In this summary, there are several aspects with which I do not agree. They have a common root, I think: the info space is *already* here (created by XPath); and after recognition of the space, the main challenge is not to replace current structures, but to add new structures and new navigational options, complementing existing structures and the existing navigation model.

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.

Our conventional view of distinct, URI-identified documents will not be replaced by other models any time soon. I am personally very interested in super-documents (in any form, with or without additional support by evolving standards), as something layered on top of the conventional view, complementing it, not replacing it. I am really alarmed by a view which wants to do away with documents as we know them... Let us add structure, not try to replace it (and fail).

> 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.

Conclusion: I suggest to emphasize the need of semantic navigation, rather than the need of domain specific axes. And I would like to stress that it should complement, not replace structural (conventional) navigation.

> We need to be able to define super structures that
> integrate divers bits of data into a single logical structure

Yes we do. But those super structures should in my opinion not replace conventional documents, but complement them.

> Forget the current notion of documents, i.e., a physical

> 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.

Let us not say "forget!" about something which we will not forget. Let us think about *additional* possibilities and perspectives, which may allow us - in certain situations - to forget the URIs. The info space as I perceive it is composed of documents, not scattered bits of data. Super-structures are additional perspectives, essentially an enhancement.

Hans