Re: XQuery (and XML) vs LISP

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Sun, 19 Feb 2006 02:15:18 GMT
Message-ID: <WwQJf.11319$yK1.1565_at_news-server.bigpond.net.au>


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

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

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

>
>>I really haven't time to iron the creases out of this spray. 

>
> You think that perhaps such things don't matter? Such questions seems
> perhaps pointlessly trivial?

Yes and No. On the first point you need to convince me of the rationale to actually perform an analysis. On the second we agree, it is not a trivial problem, but it is quite soluble. What remains important is to appreciate the requirement so the design is appropriate.

>>>And you defended the use of such with your -
>>>allegory. Remember?

>
>>I did indeed! Do you agree or disagree with the point?

>
> I've repeatedly said, to a couple of people now, that I disagree with
> any attempt to justify that approach. I simply pointed out that it's a
> common complaint with academic papers.

Text books using simple examples - yes, papers no - most of the ones I have read presume substantial prior knowledge and deal with non trivial questions.

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

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

>
> It wasn't just about camps. Millions were simply gunned down on the
> spot, or in fields being made to walk out to mass graves. The entire
> Nazi regime was the quick and steady corruption of a German society
> reeling from the straights into which the victors of the Great War
> forced them, as sort of a punishment. It was a society so organized,
> structured, advanced, in the center of European history before it was
> even thought of as, Europe, that the Manhattan Project was essentially
> justified as a race to get the bomb - a race with Hiesenberg and
> Germany's effort (which was a dead duck given Hiesenberg's fortunate
> miscalculations). Hitler's Final Solution to the Jewish Problem, as
> they termed it, his secret police and assault upon suspected traitors
> to his regime, his eyes and ears, his rumormongers, his round-up of
> the feeble and infirmed, of separating the 'races' even by something
> like phrenology, as insane as it was, the whole thing was very
> well-documented and methodical, though they also were quite methodical
> in destroying documents and physical evidence (thus the contradictions
> found, and exploited, by 'Holocaust deniers'). It wasn't merely punch
> cards. It was also that the trains ran on time. But that's not
> comparable to this, and any mention of Codd.

Simply illustrating my point that tyranny and structure can co-exist. What is more interesting to appreciate is that structure does not mandate tyranny especially as the term was used in respect of the RM in a previous post.

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

>
> Wasn't this supposed to be a key advance over what he believed had
> been the case?

All 12 rules were and remain a key advance.

>>The rules do not make the task of structural modification 
>>difficult for the RM.  It isn't even difficult to do anyway!

>
> Well, take the example:
>
>>>>>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?

Lets get to first base first and come up with the inaugural design before we start modifying it - as you mention yourself below.

>>What's this fixation with the 'type' word?

>
> Thing, then, if you prefer that. What's the structure, here? And then
> imagine I find a second book. Does it also fit? You can put a binding
> on many things, speaking of which. Can the structure be changed? How
> difficult is it "to do anyway"? But you have to have an idea of the
> first, before attempting to change it.

OK - but remember Codd limited the scope to scalar types - arrangements of which can describe the "things" you mention.

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

>
>>I'm looking, I'm looking...

>
> Perhaps it just seems a rather pointlessly trivial question? I don't
> know. Just slap some stuff together, call it a 'relation'?

There is no slapping of any stuff together - it is a much more organised and repeatable process.

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

>
> I mentioned both, and the difference between the two. It might seem
> overkill - it thankfully might not. That's both.
>
>>>>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.

>
> I'm sure you still aim at some theoretical goal in producing whatever
> temporized "solution". Where the theory presents some insight into or
> just distillation of practice, a practioner can benefit from applying
> theory, just as any theorist can often greatly benefit from being a
> practioner.

That's true at a simple macro level - at the coal face the mixture of practice and theory has to be carefully managed.

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

>
> Date's rewrite, perhaps.

Perhaps - I was depending on Wikipedia - is it not reliable?

> "To access any data-item you specify which column within which table
> it exists, there is no reading of characters 10 to 20 of a 255 byte
> string."
>
> Punch card - not punch card. But anything can go in 10-20. So again, I
> just get the sense that you think it sort of pointless to consider
> differences and what might appropriately fit one set of relations, and
> not another?

No - it depends what the requirements are. However is is unlikely I would retain a design like your 10-20 one unless there was a compelling reason.

Cheers, Frank. Received on Sun Feb 19 2006 - 03:15:18 CET

Original text of this message