[
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
matters.
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.
len
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.
|
