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)
--
Mike
_______________________________________________
Ohrrpgce mailing list
[email protected]
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
