Hello Jim, I think the algorithm is a decent one. But there is a lot of issues with using XPath to guide modification of documents.
You have to cope with non-uniqueness. If your algorithm at some stage strips enough of the original XPath that it produces some matches on the instance document, what do you do if that's more than one node? Do you want to expand the document in all these locations? Ask the user to interactively pick up the right place? Throw an exception? All of these can be meaningful in some situations. Some XPath expressions are not good enough to be used for your "mutable navigation". Your //*[@name='Jim'] is a good example of these, others could be node() or processing-instruction::pi. Basically, that's because XPath is a query language in the first place. If you want to do something else, you're on your own. All you can do (and many actually do this, incl. W3C) is: borrow as much of the syntax as you can, but construct another language with its own rules (which will probably be more strict than those of XPath). I'd suggest that you have a look at the XUpdate language, http://www.xmldb.org/xupdate/ . They are trying to solve the same kind of problems you describe, and are aware of the issues this brings up. Albeit the project looks like it has been abandoned, it may have some inspiration in it. Jan Jim Wissner wrote: > Hello, > > I don't know if you guys remember or not, but a while back I was looking > into making a "mutable navigator" interface that could be used in order to > write code that was independent of object model. I've finally got around to > working on this, with a fair degree of success so far I think, but I'm > stuck with at least one problem that I would like to ask about. This is, is > there any existing library (or even just an accepted algorithm) documented > somewhere, that allows nodes to be created based on an xpath? > > Here is one example. If I have the following document: > > <properties xmlns="urn:myPropsSchema"> > <project name="alpha"> > <frame id="001"/> > </project> > <project name="bravo"> > </project> > <project name="charlie"> > </project> > <properties> > > Then, I would like for this following xpath: > > (with 'p' mapped to "urn:myPropsSchema") > /p:properties/p:project[@name='bravo']/p:frame[@id='001']/@bounds > > to add and return the new node (the bounds attribute) like this: > > <properties xmlns="urn:myPropsSchema"> > <project name="alpha"> > <frame id="001"/> > </project> > <project name="bravo"> > <frame id="001" bounds=""/> <--- bounds attribute node > returned > </project> > <project name="charlie"> > </project> > <properties> > > So far I've got what I *think* is a reasonable (though likely not optimal) > algorithm that repeatedly pulls off the last component (using '/' as a > delimiter of course) and repeats the evaluation, until it finds at least > one matching node. So in this case, it would be: > > try 1: /p:properties/p:project[@name='bravo']/p:frame[@id='001']/@bounds > - nope > try 2: /p:properties/p:project[@name='bravo']/p:frame[@id='001'] - nope > try 3: /p:properties/p:project[@name='bravo'] - yep! > > Found a hit on try 3. Then I take the remainder (in this case > p:frame[@id='001']/@bounds) and begin adding the nodes relative to the > match we found, additionally adding any qualification as necessary along > the way (for example, we add the id attribute with a value of '001' to the > frame element that we add to the bravo project). > > So. My question is: is this a decent algorithm? I'm not quite as concerned > about performance as I am about robustness across the range of potential > xpaths that could be encountered. The primary use at this point is targeted > towards generating a reasonably small number of requests from a graphical > application - in the order of perhaps dozens at a time - not hundreds or > thousands in a transform server or anything (at least not yet! :). > > The question is how to reasonably handle all of the weird and ambiguous > cases that can be described in an xpath? For example, //*[@name='Jim'] - > what the heck do you do with that? > > Anyway thanks for any advice, or pointers to existing implementations of > this kind of functionality. > > Jim > > > -- > [EMAIL PROTECTED] > > Visit www.jbrix.org for: > + SpeedJAVA jEdit Code Completion Plugin > + Xybrix XML Application Framework > + other great Open Source Software _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ dom4j-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dom4j-dev
