[
Lists Home |
Date Index |
Thread Index
]
From: Jonathan Robie [mailto:jonathan.robie@datadirect-technologies.com]
At 02:27 PM 9/25/2002 -0500, Bullard, Claude L (Len) wrote:
>>Good enough. It seems to confirm a document model paradigm. Is
>>that right?
>Yes.
That opens up a lot of possibilities. ;-)
>But that query sure is uglier than SQL. Maybe it is the beholder thing.
>Forest to forest transformations lead to uglier syntax than table oriented
>transformations. But if you compare it to SQL 99, maybe it starts to look a
>little better ;->
Fair enough. I've gotten used to typing in SELECT FROM WHERE syntax
and it quit feeling like COBOL awhile back. I can't imagine typing
in XQuery with all of the mixed syntactical devices. I have to hope
someone comes up with a good tool or a magical simplification. That's
one to keep the interface ghouls up late nights.
>>It will be interesting to see how one trains people for developing
>>these. In other words, it took years to get them to accept and
>>build tables and reports. Now it is as if they have to build
>>reports (documents) first, and code to the report structures instead
>>of the underlying tables. Somehow that doesn't feel like progress.
>>What am I missing?
>You are making the assumption that anything with a complex structure is a
>report. There's a lot of data out there with complex structure, and you
>don't have to turn it into rows and columns for it to be real data.
True enough, but I wasn't thinking everything is a report. I'm only
expressing myself in the terms current for a relational designer. Perhaps:
1. Relational designers are only part of the target user class, important,
but only part. As I said elsewhere, maybe this opens up some other
candidates for application design who come from non-traditional backgrounds.
2. X3D and VRML. With X3D, we get VRML in XML form (plus some other
stuff but essentially, redone VRML). One might be able to XQuery an
X3D scenegraph. That would be pretty awesome. Would one XQuery
an SVG scene? This may sound silly but I'm casting about for the
extremes of the document model to find that *compelling advantage*
that an integration vendor must have to convince customers and developers
that this is worth doing.
3. The Compound Document Holy Grail. Is this the true beginning of
actually gettting one of these? Common, queriable, and made up of
document components that are of different document types? IOW, a
data document that acts like a database but can also include text
blocks, spreadsheet blocks, X3D or SVG blocks, etc. So it presents
like the hypertext we have come to love or even a Word document, but
it is actually a front-ended database with all the queriability we
always wanted but couldn't have for all the hWNDs in the way.
len
|
