Re: XQuery (and XML) vs LISP
Date: Sat, 18 Feb 2006 11:44:45 GMT
Message-ID: <NMDJf.10999$yK1.2746_at_news-server.bigpond.net.au>
Mark Johnson wrote:
> 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.
You mean this ...
I really haven't time to iron the creases out of this spray. I'm not even sure what is is supposed to illustrate about the RM.
> And you defended the use of such with your -
> allegory. Remember?
I did indeed! Do you agree or disagree with the point?
>>>>>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?
Pyramids, structures, CDT, very strange - I guess you have led a protected life then?
I assume you haven't the heard about the Nazi's using Hollerith punch card technology from IBM to provide structure to the Holocaust? Whilst the Jews bore the worst there were other groups targeted as well and the punch cards made sure they were sent to the "right" camps. Then there was the Killing Fields where the victims were often photographed and catalogued. Enough.
> Perhaps I misunderstand what I thought Codd thought was an advantage
> of his scheme, decades ago. That could be. What about his rule #9?
What about it?
>>>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?
What's this fixation with the 'type' word? Is your normal head space OO?
>>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.
You mention "small projects" again - I thought you were interested in the hard ones?
>>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?
No - just work period and produce a practically 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.
Codd was talking about scalar values in #2 - not arbitary objects.
...but I don't see!
Cheers, Frank. Received on Sat Feb 18 2006 - 12:44:45 CET