[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: are native XML databases needed?
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@x...] 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|