Re: Xquery might have some things right
Date: Thu, 04 Mar 2004 20:40:39 GMT
Message-ID: <bvM1c.21037$va.6147_at_newssvr31.news.prodigy.com>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c23ic9$usb$1_at_news.netins.net...
> My current interests related to software application development and the
> tools employed for such are aimed in two primary directions -- databases
and
> distributed computing.
Remember Fowler's First Law of Distributed Object Design: Don't distribute your objects! His quote: "Sell your favorite grandma first if you possibly can." I truly worry that we distribute too much, too soon, when a much simpler approach would have worked.
> XML plays in both of these categories.
Hmmm. XML plays in many categories, mostly because people keep dragging it out to play. It's like the rich kid everybody wants to play with because it has an aura and they have the vague feeling they might get something out of it.
> Marshall answered a recent post by indicating he is not a fan of XML, for
> example. I, too, have been know to state opinions about how it is not
> terribly important that persisted objects of any type (thought I'd toss in
> some OO terminology just to mess with a few of you) be human-readable in
> their persistent state. I don't have to be able to look directly at a CD
> and hear the music either.
Good analogy for some uses.
> BUT, XML does have some things going for it, not the least of which is
that
> it is our best bet yet for freeing ourselves of SQL -- a language with
which
> I have a love-hate relationship, but which is ready for retirement, in my
> opinion.
XML is a bet for freeing ourselves of SQL? XML isn't a language, isn't really declarative (well... never mind), and has little overlap that I can see. I'd be interested to know what XML does better than SQL, and in what area.
> XQuery, the emerging standard where Microsoft seems to be putting
> their money, is something I have referred to as a "dog-ugly language"
> (although many dogs are cute) but it has some significant advances over
SQL.
Such as?
You can do this in SQL too - it's not a good idea, but we've already beaten that dead straw horse up a tree (to badly combine three metaphors). Again, how is XQuery better? Every example query I've seen looks like the output of an horrendous acid trip.
> Additionally, along with the data modeling related to a UI, one of the big
> areas ripe for database theorists to join web folks is data modeling as it
> relates to data searching. We think of search engines for semi-structured
> data (such as text documents on the web), but our applications have often
> been so restrictive in making users get their search criteria exactly
right
> for database searches that we are going to need to adjust to more of a
> google approach at some point.
I don't think it's the same thing. Doing a Google search means you don't know exactly what you're looking for, and typically you're a little flexible in what you get (e.g. any of a hundred pages might have what you need). That's a different story than in business data, where presumably the users are professionals and understand something about what they're doing. If they don't, that's a different sort of problem.
Not that tools like Lucerne and such aren't useful, but we're not talking about the Google problem domain in most apps.
> We need to look at how a user will find a
> person, for example, when they recall that the word "green" is somewhere
in
> that person's demographic data (was it their eyes or the street they live
on
> or city they are from or one of their children or the company for which
they
> work?) We tend to force users to know the attribute (at least the type)
> they are searching along with any partial or full values for that type.
It's not exactly demanding to force the user to know they're searching for eye color, or street, or whatever... those are domains. Unless you mean "I'm looking for that green guy - dunno if it was green hair, green eyes, Mr. Green, or Green Avenue..." I don't think that brand of search is really that typical in business applications.
> I suspect that XML will play a role in the area of database search
engines.
XML is a data format. XPath/XQuery expressions might be useful to interrogate data of an XML type, but beyond that using XML just cripples your query (reasoning) capabilities.
> And ... XML is NOT based on relational data modeling theories (another
thank
> goodness from me ;-).
Why? Just the MV "thang"?
> There is one huge deficiency (OK, more than one, but one I'll point out)
I think its biggest problem is the hierarchical, procedural nature of its
queries. Say what you want about SQL, but at least you don't have to tell it
EXACTLY what order you want it to search in! XQuery is a huge burden for
developers, and gives precisely zero room for optimization.
> So, although XML is seen as an enemy "technology" to some database
> with XQuery compared to SQL -- XQuery is a read-only language at this
point,
> although update standards are being addressed.
> specialists and also to some distributed computing specialists, it is
> bringing with it some good news. [and, besides, for data exchange -- the
> best use of XML -- it was time to move on from comma-quote files anyway,
> right?]
Yes, data exchange is a decent use of XML. Text markup is what it was invented for, however, and it does that well - but keep in mind that marked-up text is a type, and that operations over that type (e.g. returning more marked-up text based on an XPath or XQuery "expression") are a reasonable use of a type (domain), even in a relational database! It's when you start envisioning all of your data as hierarchies that you run into massive, massive problems which will only compound as they worm their way to the heart of the enterprise (god help us all).
> Are there XQuery fans on this list? --dawn
Sorry - you've just referenced the empty set. :-)
- erk