Re: Xquery might have some things right

"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
2. Constraints
3. Types (domains) - with real operators and everything

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

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

> They took XPath and added to it

Pearls on a pig?

> (for handling multiple documents or large
> documents)

What precisely needed to change? I thought X* was already "document-oriented", whatever that really means.

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

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

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

• erk