Re: XQuery (and XML) vs LISP

FrankHamersley <FrankHamersleyZat_at_hotmail.com> wrote:

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

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

I mentioned, already. And you defended the use of such with your - allegory. Remember?

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

>> Because that was the idea behind it.

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

"Human history"? You lost me, here. What do you mean? The pyramids?

Perhaps I misunderstand what I thought Codd thought was an advantage of his scheme, decades ago. That could be. What about his rule #9?

>> 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 don't know. Look at his rules, again.

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

In other words, the idea of this 'type' is so vague that it simply doesn't matter? See below.

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

>> I'm not sure that means anything. Improved compared to what,
>> precisely? And why irrationally in parentheses, etc? Could you
>> elaborate?

>Sure. Improved compared to the mess of enmeshed programmes and data that
>arose during the 60's and 70's.

That's how _I_ understood it. That's why I mentioned this idea that breaking out parts of processes has sort of defined developments over the decades. Again, such might seem overkill for a small project. But . . . etc., as I wrote, before.

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

Work with what you have, in other words, and still produce a theoretically sound solution? Actually, my question went more to what perhaps you regard as a sort of pointless definitional confusion over just how things are grouped, labelled, typed. I thought much had been made about rule #2, and the lack of ambiguity, of like 'things' in relations. But what is a like thing? That's all. Received on Sat Feb 18 2006 - 01:19:30 CET