Re: XQuery (and XML) vs LISP

Mark Johnson wrote:
> Frank Hamersley <terabitemightbe_at_bigpond.com> wrote:

>>Mark Johnson wrote:

>>>The thing that has bothered me is that those promoting the relational
>>>model typically provide worthless examples, typically employee and
>>>department, and seem to almost religiously avoid non-trivial working
>>>examples, particularly those that might seem problematic for the
>>>scheme.

>>Its the same reason that babies get fed milk first, mashed food later 
>>and finally solids!

Errr - its allegory, at least it was intended to be such!

> And there's that "particularly . . . problematic', bit. That
> sort of explained it, for me. I don't know if you differ.

Neither do I. Can you point one of these "problematic" working examples out to me?

>>>For example, what is a type? What goes in the 'set', as you express
>>>it, never mind any particular domain? Why is a book a 'type', when
>>>there are various sorts of books? Why is a chapter a 'type', when the
>>>chapters in the same book might be of a very different sort? Is the
>>>appendix which is more an index a type to itself? And so on. Are the
>>>paragraphs a 'type', and is the paragraph in chapter 4 different than
>>>the paragraph entities in relation chapter 5? To normalize things does
>>>it require literally hundreds and hundreds of 'relations'/tables to
>>>represent the structure?

>>Have you seen "hundreds and hundreds" first hand?  What were they 
>>responsible for expressing?

I'm on record as having big doubts about de D proposal. Joins are not a drama (to moi at least), but the TTM is another kettle of fish.

>>>Just think of the 'joins'. And wasn't the RM
>>>intended to free people from the 'tyranny of structure'?

>>Nope - where you get an idea like that?

Gee, and all this time I thought it was about common sense. Structure does _not_ imply or mandate tyranny even though they can co-exist as several sad periods in human history confirm.

> But the difference was that, if I
> recall, the structure and programming went together in the 50s and
> early 60s. They weren't separated out. Just generally, a lot of
> development has been had because parts of processes have been
> separated in a 'workflow' scheme. For a simple job, it seems
> excessive. For anything else, it simplifies, compartmentalizes and
> reduces error. And there have been a lot of decades between then and
> now. And the RM has been implemented to certain degrees. Now if you
> put such a hierarchy on an existing RM or pseudo-such, it seems as if
> it would be a different matter - even while violating the basic tenets
> of the RM to do so. But it's not necessarily tied to a structure, as
> the RM is so tied by joins and the relations themselves. And it makes
> structural modification difficult.

Does it? I must be dreaming then - silly me!

> Remember what I said: For example, what is a type? What goes in the
> 'set', as you express it, never mind any particular domain? Why is a
> book a 'type', when there are various sorts of books? Why is a chapter
> a 'type', when the chapters in the same book might be of a very
> different sort? Is the appendix which is more an index a type to
> itself? And so on. Are the paragraphs a 'type', and is the paragraph
> in chapter 4 different than the paragraph entities in relation chapter
> 5?

Choices, simply choices, make them, or don't - what is the fuss all about?

>>The aim is to "improve" the 
>>structure and still make sure that physical aspects don't (irrationally) 
>>impinge on the logical interests.

Sure. Improved compared to the mess of enmeshed programmes and data that arose during the 60's and 70's. Why did I use irrationally - because there are physical aspects that will impinge - such as the available storage on a system might impact quite reasonably on how you build a huge solution, but whether a system is big or little endian is of and should be of no interest to a business analyst wanting to record text for your books or chapters. Capiche?

Cheers, Frank. Received on Fri Feb 17 2006 - 14:14:51 CET