From: Wolfgang M. <wol...@ex...> - 2004-09-16 13:23:44
|
Hi, thanks for pointing us to these papers. I found Timo's article easier to read and understand, so I will refer to this. Though I don't overlook all the implications yet, the DLN approach clearly solves two major problems: 1) the document size and complexity limit is dropped, 2) frequent reindex runs after node insertions/removals are avoided in most cases > The second approach, ORDPATH, is in the end similar to our scheme. Here > the biggest disadvantage is the variable length of the ids. > However combining ORDPATH and Pre/Post won't give you any advantage > because ORDPATH (or in general hierarchical numbering schemes) are > semantically rich too. From a given node you can determine > preceding/following, ancestor/descendant, parent/child nodes. Is it really possible to determine the DLN of a child or sibling node from a given DLN? I can't see how. I guess you can only determine the relation between two given DLNs? However, this property of the current numbering scheme is used by eXist to implement a few features. We would thus need to store the DLN along with each node in dom.dbx, which adds a few bytes to every node. This is the major disadvantage I see. Nevertheless, I'm currently tempted to drop my previous plans and to vote for Timo's approach. > You mentioned on your web site the Pre/Post approach with its rich > semantic. However (as you also noted) inserting new nodes is practically > impossible because of the required renumbering of existing nodes. I also don't see the additional benefits you could get from combining pre-order ORDPATH with post-order ids? Are there any operations that could win from post-order ids? > The combination of a hierarchical numbering scheme (with variable id > length) and a fixed-length node id could be a viable solution. Currently > I use this in a prototype which manages XML data in RDBMS. That would require an additional index to map DLNs to fixed node id. Do we really need that? Isn't it sufficient to identify nodes by their virtual storage address? Wolfgang |