Re: native xml processing vs what Postgres and Oracle offer

paul c wrote:

>rpost wrote:
>> paul c wrote:
>>
>>> patrick61z_at_yahoo.com wrote:
>>
>> [...]
>>
>>>> Actually, usenet is often displayed as being hierarchical, for
>>>> instance with so called "threaded" newsreaders, because within a list
>>>> of discussions, replies to replies are often more comprehensible when
>>>> you can follow the subthreads.
>>>> ...
>>> Nobody said there's anything wrong with hierarchical displays (or
>>> hierarchical physical storage for that matter).
>>
>> [...]
>>
>>> As the general level of literacy continues to decline more and more of
>>> those who fail to recognize the possibility of a logical model will have
>>> to put up with that dwindling breed.
>>
>> You're evading the question.
>> ...
>
>What question would that be? (The original question was to do with the
>best product to use to display hierarchical data. The OP planned to
>invent his own forum, presumably not Usenet-based. I pointed out that
>he was wrong to assume a forum is hierarchical.)

To which he replied: but a forum message is often a reply, and in that case, a reply to a specific other message; this is not a presentation feature but a basic structural property of his forum (and of USENET as well); not just of the implementation but at the functional requirement level. You seemed to be flat-out denying this, which raised the question: how would *you* model USENET or his forum?

>> Does your logical model for USENET include message ids?
>
>It's not always clear in this group what people mean by logical, whether
>they mean a formal logic or merely something that "makes sense" to them.

I suspect you're being evasive again. By 'your logical model' I meant an implementation independent relational model in terms of the technique you prefer to use yourself.

>So I'm not sure what "message id" means here, whether you mean it in a
>general sense or to stand for what some rfc's call "message-id" or "msg
>id" (which seem to have a tarnished history).

The latter, or I wouldn't have referred to the RFCs. You're evading a straight answer once again.

>However if I were to make
>a model for Usenet, it would try to be logical, ie., it would follow
>logical principals, like relational algebra does, where, courtesy of
>closure, one can always choose to validate results by comparing
>extensions as opposed to re-evaluating a program that is full of
>navigation verbs.

Exactly, and my question is: how would *you* deal, when describing USENET in this way, with the *functional* requirement that a message is usually a reply to a specific other message?

>If you are talking about keys, I would note the similarity with the RM
>and this from rfc 3977: "Each article MUST have a unique message-id; two
>articles offered by an NNTP server MUST NOT have the same message-id."

Exactly. I went into this in another reply in this thread, where I agree with you that this is probably not a good idea, but also give an argument in favor. My question to you is: what specific alternative would you prefer? You reject it because it smells bad, without providing an alternative, let alone proving its superiority. That isn't good enough.

>I don't want to disparage the original rfc authors as many of the rfc's
>date from the days when ignorance of data models was more innocent than
>today's willful arrogance but it looks to me as if some of them might
>have been confused about such a basic principle as keys, eg., in rfc
>2822: "Though optional, every message SHOULD have a "Message-ID:"
>field." (Rfc 977 is pretty vague.) Without some key, one never knows
>precisely what fact one is stating. I suppose all the optional "fields"
>in the various rfc's might admit a kind of irregular notion of key where
>some articles or messages might use different sets of fields as keys.

You can read it that way, but I think it's more reasonable to see it as an example of "be liberal in what you accept": *correct* implementations guarantee the present of a unique Message-ID on each postings and their use in the References: header to establish threads, but the NNTP protocol authors are in no position to guarantee correctness of all newsreaders used on USENET and therefore provide some workarounds to help coping with them. In a logical model I'd omit the workarounds and just say that USENET messages have Message-ID as their primary key.

>For sure, the rfc's I've seen are pre-occupied with syntax and other
>physical matters and the usual cursor operators of hierarchical stores,
>"Next" and so forth. Looks like they anticipated, in their own
>idiosyncratic way, the wild goose chase of the XML fans to find the
>mythical semantic web, ie., invent some pet syntax and blindly assume it
>can be a basis for fundamental transformations, ie., new information
>from a starting point that is as vacuous as the Emperor's New Clothes.

I share your sentiment but I don't see the connection. NNTP is an implementation-neutral network protocol, it *must* be all about detail.

-- 
Reinier