| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: XQuery (and XML) vs LISP
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.
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?
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.
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?
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!
>>>>>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?
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...
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?
>>>>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.
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.
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 Sat Feb 18 2006 - 20:15:18 CST
![]() |
![]() |