On Wed, Jun 02, 2010 at 06:44:30PM -0400, Mike Caron wrote: > On 02/06/2010 5:52 PM, James Paige wrote: >> Is this an accurate description of what Rpath is supposed to do? >> >> node = Reload.RPath(doc, "/party/slot[3]/stats/stat[0]/max") >> >> Which would look in the root node for a node named "party", >> then look in the party node for a node named "slot" with int value 3, >> then look in the slot node for a node named stats, >> then look in the stats node for a node named "stat" with int value 0, >> then look in the stat node for a node named "max" and return it >> >> If that is indeed what RPath is supposed to do, I feel up to the task of >> implementing it. >> >> And if that is NOT what RPath is supposed to mean, then I still feel up >> to implementing it, but I will call it something different :) > > Almost. RPath is intended to mimic XPath, which would interpret your > example as: > > Match the root node named "party", then > Match the third sub-node named "slot", then > Match the first node named "stats", then > Throw an error, because indicies are one-based, but if it was a one, > Match the first node named "stat", then > Match the first node named "max" > Return this node > > To do what you suggest, the expression would look like: > > party/slot[.="3"]/stats/stat[.="0"]/max > > And match it against the document root, whatever it may be. Explanation: > > 1. A leading slash matches the *document*, not the root node. (Actually, > in XML, there's a hidden node above the first tag. The leading slash > matches that) > 2. The dot represents the "current" node > 3. The expressions inside the brackets are like WHERE clauses in SQL > 4. A number by itself means the Xth node. > > You can do stuff like > > no...@foo="bar"] > > Which matches "node" who has an attribute "foo" whose value is "bar", > and is the intended way to match nodes (Incidentally, this is why I > reserved the leading @ for attributes converted from XML). > > So, where does this leave RPath (which I have not been describing so > far)? I suggest we stick closer to XPath, but perhaps with some > limitations: > > 1. XPath allows a bunch of pseudo functions inside the brackets, things like > > node[next(.) == "foo"] > > Which would match "node", whose next sibling's value equalled "foo". We > don't need that. > > 2. Allow matching based on children alone, so we don't need . to mean > the current node. > > 3. Recommend that people don't use the content of the node itself to > distinguish between similar nodes. Use children for that. (Or, better, > give the nodes distinct names) > > If you need clarification, let me know (or pull me into IRC or something) >
Okay. Sounds like RPath is a lot heavier than what I have in mind I will continue with my simplified implementation, but I will call it something else to avoid confusion. Probably Reload.Ext.NodeByPath --- James Paige _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
