[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:46:21 -0500

I've actually seen the parts diagram example done 
several times in my career, and most recently, with 
an XML source using SVG.  So yeah, that one is 
very practical.  All the ancient IETMHeads know 
it not only from querying schematics, but keeping 
up with relationships among parts in assemblies 
for modeling (sure, it can become the defacto 
model for simulation, but the density of information 
is overwhelming for a technical manual model, so 
prudence to the wild eyed...), fast refdes navigation, 
and so on.  I wrote a lot on this topic during my 
days serving Carderock and MICOM.   Some refer to 
it as the "tail number problem:  the tail number 
identifies the aircraft and everything beneath 
that unique key varies even if it looks the same 
on the surface (avionics for example)".   System 
guys love this stuff, and system guys were the 
true origins for CALS.  Hmm... so twenty years 
later, a solution for the original CALS problems 
emerges.

I like the direction.  Old dreams coming true.

len

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

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

• Prev by Date: Re: Underwhelmed (WAS: XOM micro tutorial)
• Next by Date: RE: W3C Schema Question
• Previous by thread: RE: Fwd: War of Attrition (was: Underwhelmed (WAS: XOM micro tutorial))
• Next by thread: Integration Models (WAS RE: parser models)
• Index(es):
  • Date
  • Thread