Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: After XQuery, are we done?
 Bullard, Claude L (Len) <len.bullard@i...> writes: > > That's the solution I've used and has been used since > time immemorial in yeOldeDocumentDatabases. Locally, > we call it a joins table. Sounds similar, probably a little different in the details: we normalized out references to the tree structure leaving "naked" tree structures in the tree table and reusing them as needed. (We have different "views" of the same tree, I'm not attempting to reuse structure across different trees, I don't think that would make sense.) It took a lot of performance testing to convince us that was worth the extra work, but it is both space efficient and performant. > I once implemented a > treeview object for such and it was the one time > that namespace URIs really came in handy. When we > have to create ERDs and document tables, pulling all > of the relationships into a simple meta-table is > useful and avoids sparseness. The other thing is that once they are in the same table it becomes really easy to build out the graph structures: new cross cutting views add a new tree, but hardly any additional logic is required to exploit it. At most you end up adding a new reference table that normalizes out the indexes for a particular set of trees, but that's mostly to partition the indexes for performance purposes (I've posted about this before). Having said that, it also helps the developers by giving them a focus for organizing the stuff that deals with a particular context: adding yet another set of type tables to an already abstract structure isn't very human friendly after a while... > The external pointers approach comes in handy when > one has multiple endpoints in files/entities/things > of different formats. That is why Hytime originally > required notation declarations and there was a concept > of link types. The local anchor identifies the > link which identifies the notation which identifies > the target type handler. So the function/dll is named > and is passed the link type and the identifier for > the target. The target might be read-only and might > not be markup and might not have locally stored > names for location purposes. So Hytime had types > such as nameloc (where a name can be used), treeloc > (what got into XPointer and XPath), and so on. One > could use byte offsets for links, and so on. There > is set of constructs for using dimensions so it was > easy to do what HTML later did with maps. > > Most use namelocs and treelocs and the dimensional > locators that I've encountered. It sounds like you are saying that you think adding some external pointer structures would suffice for moving XML to XML++ (or whatever) ??? > len > > > From: Hunsberger, Peter [mailto:Peter.Hunsberger@S...] > > Hmm, we set out to implement a tree management database and > ended up building some limited forms of graphs out of it. > You end up cross referencing the nodes in the trees via > another table. Sounds like the same thing attacked backwards. > > > graphs > > can easily represent very complex sets of relationships - something > > trees will never do. to me this means xml must struggle as > > application > > or document complexity increases, > > I've been trying to say exactly this throughout this thread, > thank you for the succinct way of putting it. > > > so there will be a > > requirement for a > > meta-xml (MXML?). > > > > I'm still wondering if something like Gavin's external pointers on top > of XML wouldn't suffice? > > 
|
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
|
|||||||||
