Re: Xquery might have some things right

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c2komr$oae$1_at_news.netins.net...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:7_k3c.22216$Fa7.8002_at_newssvr31.news.prodigy.com...
> > [SNIP]
> > 2. Constraints
>
> Unnecessary given it is only a query language, right?

Well... in relational, the predicate for your query results is computable from the predicates of your base relations and/or views - so there is still meaning, and preservation of constraints, which makes things like updatable views possible. I'm uncomfortable not so much with read-only query results being updatable, but the fact that there are no constraints, and only very limited typing, anywhere in the query / document / schema stack. Your ability to express meaning is severely limited, unlike relational, which is quite expressive as to what your data means.

> > 3. Types (domains) - with real operators and everything
>
> Agreed-ish. The .xsd does have typing of sorts. XQuery does have
functions
> (operators) that work with the .xsd typing, as best I can tell (but, of
> course, I'm not a relational zealot).

Are the functions associated with types, or just with an XML string as a whole?

> There is definitely a part of me that sympathizes with your perspective on
> this.

This has been quite an agreeable exchange... :-)

> > Regarding the above (and ending my rant), the question becomes why would
> you
> > bother with an XSD when any relational language (or even SQL) can
express
> > the structure of relations better?
>
> Because I really don't care about expressing all data as relations. I'm
> quite content to model children with their moms and not "normalize" them
> into their own tables, for example.

I mispoke. I should have written "...can express the structure of data better." But we've already disagreed on that, so...

> > Information systems are seldom trees or graphs - that's just the
> > way we're used to thinking, thanks to O-O languages and now XML.
>
> Not to mention English, other languages; paper-based filing systems; and
the
> human brain. I have not done a lot of research on how the brain stores
and
> retrieves data, but I'm pretty sure it isn't in relations with relational
> operators!

Probably true, but what is it? In any event, I don't care whether my automated systems resemble the human brain. Our pattern-matching facilities are impressive, but we're poorly-equipped for logic, which is why symbolic logic is important and mechanizable. Why would I want my systems to necessarily mirror the human brain? Obviously we can't cope with something completely orthogonal to how we think, but on the other hand direct alignment with HOW our brains process is irrelevant. Anyway, are you sure the human brain "processes hierarchies"?

> > What precisely needed to change? I thought X* was already
> > "document-oriented", whatever that really means.
>
> XPath functions on a single XML document -- if you have data in more than
> one document, you need something else. I think there are also other
scaling
> issues (or suspect such).

Unfortunately it will be difficult to incorporate "multi-document thinking" (gasp - do you mean SETS?) into XML, as the entire thing is based on root nodes. The basic structure can't be hacked after the fact without consequences.

What amuses me is the number of W3C standards that define the semantics of XML - differently. There are an amazing number of standards - just pick one!

> I couldn't put my finger on what I was reading immediately, so I'll try to
> come up with something later. It will still look like navigation to you, I
> suspect, since the data are still in graphs.

Even in a graph, though, I should be able to specify patterns.

> > It wouldn't surprise me to find anything easier to read than XQuery.
>
> Yes, it was so disturbing for me to look at that I didn't want to learn
it.
> Such a shame, in my opinion.

Agreed.

> After determining on my own from direct experience that SQL was a very
> impaired language, I started reading relational theorists again to see if
I
> could tap into the SQL way of thinking. I found that many relational
> theorists have as much love for SQL as I.

True!

> Since SQL is the industry
> standard still, it needs to be replaced.

True!

> From a non-theory perspective, but
> using a reality check, it appears that XQuery is best situated for this
> replacement.

By "reality check", do you mean from sheer "market mindshare" (that must be an oxymoron), and commercial viability?

> > > XQuery is not salvation by any means, but it does appear to be
> contending
> > > with many of SQL's weaknesses.
> >
> > Which ones specifically? I still don't understand the alleged benefits.
> Not
> > trying to make you repeat yourself, but...
>
> 1. 2 valued logic

You mean no nulls?

> 2. functions for supporting queries on data modeled as
> graphs/di-graphs/trees without having to perceive such data as relations;

I'm not sure why not perceiving such as relations is an advantage, but keep in mind that XPath is a perfectly valid operator on an XML type - even in relational! Doing a project (SELECT) or restrict (WHERE) using an XPath operation on an attribute (column) is perfectly valid.

> in particular, support for data in non-1NF

A LIST type is also valid, though we've argued ad nauseum about its value.

> These are significant, not trivial, advantages, methinks. --dawn

I'd disagree, but thanks again for a good discussion. My, this is a veritable lovefest - group hug, Bob? :-)

• Eric