Re: Xquery might have some things right
Date: Tue, 9 Mar 2004 09:43:17 -0600
Message-ID: <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...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c2je9a$ne$1_at_news.netins.net...
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> > news:Kt%2c.21999$Ao4.10506_at_newssvr31.news.prodigy.com...
> > > Here's the key word in the entire argument: "publication." This is
where
> > the
> > > XML / text publishing camp and relational camp diverege greatly.
Perhaps
> > > there are different needs that favor the different camps, but I think
> the
> > > relational camp simply subsumes the others because of its ability to
> > > represent hierarchies simply and cleanly, whereas the converse is not
> > true.
> >
> > Definitely a point of disagreement. Simply force XML data to conform to
> an
> > .xsd and have the xsd require a cardinality no greater than 1 for any
> > element and have no attriburtes (by XML terminology) and you are pretty
> > close to a relational model, right? What's missing?
>
> 1. A suitable notation
Agreed.
> 2. Constraints
Unnecessary given it is only a query language, right?
> 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).
> I read an article on modeling the "semantic web" (an undead abortion
doomed
> to walk the earth) using Alloy. For every example, every mapping they
> showed, the Alloy syntax was shorter, easier to read, and from my
knowledge
> of Alloy, capable of expressing much more. The lingering question was:
"why
> are we bothering with this XML-ish syntax"?
There is definitely a part of me that sympathizes with your perspective on this.
> I fear we're going to have to deal with XML syntax for years to come, and
it
> stinks on ice. XML is hardly the last word in "declarative," though it's
> discussed as if it invented the notion.
> 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?
> > It is much easier for
> > a system modeled on graphs, di-graphs, or trees to pretend to be
> relational
> > than the other way around, right?
>
> I'm not sure that's a foregone conclusion, and the word "pretend" isn't
> relevant.
> 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!
> Besides,
> trees say nothing about constraints - it's the lowest form of structure,
> necessary but not sufficient for expressing what the data means, much less
> what operations are valid over it.
>
> > For the most part, you can do what you
> > need to do with either model, it is just a matter of how difficult it is
> to
> > build and maintain.
>
> Exactly.
>
> > Don Chamberlin and other relational folks are part of XQuery
development.
>
> Ah, committees... besides, with Microsoft hiring every decent researcher
> around (and then apparantly ignoring their results), I can't say I have a
> great deal of faith in past credentials anymore. Have to look at what
> they're doing, not what they've done.
Agreed.
> > They took XPath and added to it
>
> Pearls on a pig?
Yes, I suspect I agree a bit with that.
> > (for handling multiple documents or large
> > documents)
>
> 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).
> > and then also, for no reason other than their relational
> > heritage, they lopped off navigational functions found in XPath, forcing
> > more complex query statements for some of the navigation.
>
> All the examples I've seen have been "very navigational," so I'd
appreciate
> an example showing this.
> > But when doing
> > Xquery you are not doing only relational queries -- you are doing
> something
> > much more like PICK queries, but without the ease of reading them that
you
> > get with PICK (bz extending the vocabulary hides code from users). I
> > suspect that "doomed" is too strong a word. Stay tuned.
>
> 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.
> > > You're assuming a remote DB access that works the same way as existing
> > JDBC
> > > and ODBC libraries: creating a connection, sending various queries,
> > closing
> > > the connection. The query could easily work like an HTTP request, for
> > which
> > > there are many varied "scalable" solutions. Or using Jabber protocols.
> Or
> > an
> > > asynchronous one. There are many options. The point is this: when
client
> > > needs vary widely, trying to "push" to each of them involves a lot of
> > extra
> > > complexity on the server side, plus you have to reinvent a
> > pseudo-relational
> > > query mechanism anyway. Another wheel!
> >
> > But the SQL wheel is beyond squeaky -- it needs to be replaced.
>
> You're right, for different reasons than you probably recognize, but the
> above wasn't talking about SQL at all, just that a remote query mechanism
> that's actually flexible.
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. Since SQL is the industry standard still, it needs to be replaced. From a non-theory perspective, but using a reality check, it appears that XQuery is best situated for this replacement.
> > From
> > "XQuery from the Experts" 2004 Chamberlin et al, p385 "either the SQL
> model
> > itself must be extended to deal with the nonrelational aspects of order
> and
> > heterogeneity...or the SQL model will eventually be subsumed under the
XML
> > and XQuery model" I'm not saying that SQL is dead yet (just like COBOL
> > isn't dead) but if anyone has a choice of databases and/or data access
> > languages might think twice before jumping into SQL if you don't have
to.
> > 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...
- 2 valued logic
- functions for supporting queries on data modeled as graphs/di-graphs/trees without having to perceive such data as relations; in particular, support for data in non-1NF
These are significant, not trivial, advantages, methinks. --dawn Received on Tue Mar 09 2004 - 16:43:17 CET