[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Fwd: War of Attrition (was: Underwhelmed (WAS:

• To: 'Jonathan Robie' <jonathan.robie@d...>, Dare Obasanjo <dareo@m...>, xml-dev@l...
• Subject: RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Wed, 25 Sep 2002 15:21:40 -0500

From: Jonathan Robie [mailto:jonathan.robie@d...]

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

• Follow-Ups:
  • RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
    • From: Jonathan Robie <jonathan.robie@d...>

• Prev by Date: RE: Fwd: War of Attrition (was: Underwhelmed(WAS: XOM micro tutorial))
• Next by Date: RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
• Previous by thread: RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
• Next by thread: RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
• Index(es):
  • Date
  • Thread