[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: "Bullard, Claude L (Len)" <clbullar@i...>,Dare Obasanjo <dareo@m...>,xml-dev@l...
• Subject: RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
• From: Jonathan Robie <jonathan.robie@d...>
• Date: Wed, 25 Sep 2002 16:32:09 -0400
• In-reply-to: <15725CF6AFE2F34DB8A5B4770B7334EE0DF724@h...>

At 03:21 PM 9/25/2002 -0500, Bullard, Claude L (Len) wrote:

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

There are basically three syntactical devices - XML syntax (element 
constructors), XPath, and SQL-like expressions (FLWR expressions are 
probably the most important of these). In my workshops, people seem to 
catch on quickly. They have to, because I make them do a lot of exercises ;->

It's not a pure syntax, but I'd be interested in your reaction after you've 
written a couple of dozen XQueries. You might get used to it quickly.

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

This is clearly the case. If all of your data is SQL, and all of your 
queries are a natural fit for SQL, then SQL is a pretty good solution, and 
there isn't any need to go to anything else.

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

Consider a parts diagram that contains both diagrams of the parts and 
comments embedded in individual parts. That can be practically useful.

Of course a simpler example is querying web messages, like my earlier 
example. Web messages are important source data.

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

This is absolutely an intentional direction of XQuery. It can all be 
represented as XML data or XML views of data, and that makes it possible to 
query it with XQuery.

Jonathan

• References:
  • RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
    • From: "Bullard, Claude L (Len)" <clbullar@i...>

• Prev by Date: RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
• Next by Date: Re: 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