Re: [xml-dev] XML vs relational database

[Rick Marshall <rjm@zenucom.com>]

Computer Science 101...

This of course is nonsense.

I proposed this at UNSW in the late 1970's and was soundly hounded down 
because at the end of the day everything can be turned into a Turing 
machine to do it's work and ergo the algorithm is predetermined. With 
all due respect to Alan - it ain't.

It was the start of the relational religion as a mainstream religion and 
provable algorithms as the holy grail.

In a handwaving way here is the 'proof' that reflection is just old 
fashioned optimisation in disguise if you leave out explaining itself:

The basic idea of optimisation is that if you know some mathematical 
property of an operation you might be able to make a decision NOT to do 
something provided it is significantly (order of magnitude?) more 
expensive to do the something than not to do it. eg. x * 0 = 0 in all 
circumstances. So determining that x == 0 or 0 == 0 and therefore the 
result is 0 can be done very quickly (assuming comparison is quick and 
multiplication is slow). Fully compiled code does this sort of thing all 
the time - so contrary to the claims of the Wikipedia entry, it can be 
reflective. The compiler code has meta information about calculations 
and optimises them. I'll reflect ;) on the explanation bit later.

Then came SQL. Solving big queries but often slowly. The optimiser 
people at Oracle and IBM (principally in the early days) realised that 
they had a lot of information about the tables and queries and built 
large optimisation machines to use this knowledge to speed up the 
calculation of SQL statements. Absolutely reflective. I'll reflect ;) on 
the explanation bit later.

UNIBASE uses more meta data about table relationships and equations to 
drive a runtime engine that constantly looks at what it is doing, what 
it knows and what it doesn't know to work out what to do next. Very 
reflective. I'll reflect ;) on the explanation bit later.

I haven't looked at the guts of the XSLT stuff but it seems reasonable 
to me that it does similar things.

There's an evolution there.

Now how do we get these things to explain what they're doing? That's the 
problem. We can't and shouldn't really try. (That was the crux of my 
conflict in the 1970's). Even modern optimised code can't adequately 
explain why. And there's a reason. We give the compiler/interpreter a 
set of rules and then allow it to apply them. From the outside we 
observe results and when it's not what we want we modify the rules. Now 
where have I seen that before? Oh yes... raising children. They can't 
always explain their behaviour, but we can usually tell when and what we 
have wrong with the rules we gave them and how well they follow them. 
I've also seen it late at night in my favourite bar, but maybe that's 
for a later discussion...

The situation gets significantly worse when the interpreters can work 
with calculus rather than algebra. Neural networks are possible the 
ultimate example of self modifying (trainable?) structures that can't 
explain themselves.

Reflection is just the runtime (and essential) part of optimisation.

Rick

Tei wrote:
>
>
> On 8/16/07, *Sylvain LOISEAU* <sylvain.loiseau@wanadoo.fr 
> <mailto:sylvain.loiseau@wanadoo.fr>> wrote:
>
>     Can I say that? 
>
>
> Reflection for SQL?
> http://en.wikipedia.org/wiki/Reflection_(computer_science) 
> <http://en.wikipedia.org/wiki/Reflection_%28computer_science%29>
>
> SQL is a query language, is designed to describe a information 
> request, you have a prior knowledge about structure. 
> You will ask about "SELECT Name FROM Horses WHERE Type=1", because you 
> know the structure.
>
> SQL has not been designed for reflection, but there are extensions, so 
> you can do that. But will feel like OOP  with C, the languaje support 
> for it will suck.
>
>
>
>
>
>