Re: Xquery might have some things right

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:<rIX7c.62404$a12.2807_at_newssvr33.news.prodigy.com>...
> "Tony" <andrewst_at_onetel.net.uk> wrote in message
> news:c0e3f26e.0403230201.7fb37da7_at_posting.google.com...
> > dwolt_at_iserv.net (Dawn M. Wolthuis) wrote in message
> news:<6db906b2.0403221645.1141ecf6_at_posting.google.com>...
> > > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:<9JC7c.62219$lV6.25494_at_newssvr33.news.prodigy.com>...
> > > > "Joe "Nuke Me Xemu" Foster" <joe_at_bftsi0.UUCP> wrote in message
> > > > news:1079920954.616425_at_news-1.nethere.net...
> > > > > "Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message
> <news:3z32c.18$zW4.150_at_news.oracle.com>...
> > > > >
<snip> > >
> > > What is the theory on which we base "our" disdain for navigation? Is
> > > the only rationale performance?
>
> No, it's just another manifestation of the (admittedly vague) what/how
> distinction. We should, at this point in the history of computing, be
> specifying WHAT we want, not how to get it. It's as if the (necessary)
> operational thinking that dominated the design of processors now dominates
> everything we do, rather than allowing us to return to "pure" logic, where
> we can actually achieve conceptual traction.

What we do might be described, in theory, not as a "how to" as a graph-theory navigation of a di-graph, just as it might be described as a set-theory operation, right? Either way, it is the application of a function/operation. Neither the end-user nor the programmer needs to do this navigation -- the vocabularly made visible in the metadata could include virtual "fields" that are derived via navigation -- but only the specification/definiton of that vocabularly needs to have the "how" spec.

Do you agree there is nothing purer or truer about a set-theorectical operation than a graph-theory navigation? thanks. --dawn

> > > In other words, if there were a data
> > > model where the implementation was zippy quick and navigation was a
> > > strategy for getting there, then is there something else upsetting
> > > about the navigation approach?
> >
> > It isn't a theoretical disdain. It is based on the fact that with
> > navigation you have to specify how to get the result, not just what
> > result you want. One of the strange things about many programmers is
> > that they don't trust computers, and always prefer to do all the work
> > themselves.
>
> A huge problem. I'm less and less in favor of "flexibility" in language
> design for commercial / industrial systems, since this is so often abused to
> no one's benefit. Specifying an access path, as opposed to simple criteria
> for selection, makes a world of difference.
>
> - Eric
Received on Wed Mar 24 2004 - 05:15:08 CET