OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] are native XML databases needed?

[ Lists Home | Date Index | Thread Index ]

Sure you can.  Are you saying the dinosaurs 
could dance more flexibly than the mammals?
Au contraire, Michael.  You are right.  Granularity 

For the readers too young to share what Michael 
and I shared in the Good Old Daze:

An IETM was not one kind of document element. 
Again, we XMLers tend to think about elements 
and attributes but everyone else is thinking 
about what's between them:  the text nodes. 
So shred the parts data because you will have 
to dynamically assemble that, add callouts, 
bind page numbers etc.

Where it gets hard is in the information designed 
expressly for the mammal, say, the disassembly 
or repair and replace procedure.  These step driven 
guys using LSAR records are cumbersome in relational 
formats, particularly where one has to support 
dinosaur formats such as 38784.   So again, 
no size fits all.  It comes down to the cost 
of reuse.  Do you ever or often reuse a step 
in a procedure?  No.  Do you ever reuse the 
procedure?  Yes.  Does the markup matter much 
in the procedure?  Not as much as in the parts 
base?  What matters?  As Mary points out, the 
ID matters a lot.

Is it easier to do with an XML DB?  Dunno.  
Never had the pleasure.  But as pointed out 
elsewhere, what the heck is that anyway but 
some internal format optimized to represent 
ANY XML?  In an object oriented db design, 
picking the abstraction for the objects 
makes all the difference, yes?  Is it an 
InfosetObject?  Is it a PartObject?  Is 
it a PartObject derived from an InfoSetObject?

Questions like that are usually near the heart 
of the problem of why object systems don't 
get standardized.  Yet with hierarchical 
data objects, that isn't a problem.

Data objects scale.  Semantics don't.


From: Michael Champion [mailto:mc@xegesis.org]

On Aug 25, 2004, at 3:26 PM, Bullard, Claude L (Len) wrote:

> Lockheed Martin (texas) did it for IETMs using SGML.  It
> was a favored design for IETMs.  It wasn't efficient
> for real time use, but for dynamic assembly of a
> deliverable, it worked great.  IOW:
> 1.  Author parts in a parts system, typically
>     relational.
> 2.  Bind that into an interactive deliverable.

With everything normalized (aka "shredded") down to the level of 1 
element/attribute per column?  Back when I was dodging SGML dinosaurs 
and doing this kind of thing, the granularity was much higher.  If 
we're talking about the relational model, as opposed to pragmatic use 
of an RDBMS, I think we have to talk about normalized data.  But I 
don't want to get into this particular religious debate, shudder.  My 
point isn't that  you can't use an RDBMS as a nice metadata and CLOB 
repository for SGML/XML and write code to dynamically generate IETMs, 
but for what it's worth  I had a real epiphany when I discovered how 
much easier it was to do this with XML DBs.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS