Peter, the XPath lib was rewritten not long ago to provide full XPath 1.0 support + extensions, so feel free to mail me with questions or bugs. The old lib didn't implement the whole spec and would crash or infinite loop on valid input, so I felt a rewrite was needed.
> myDocument xPath: #'entity/@name' I think treating Symbols as Strings is a bad idea. On GS, Symbols aren't Strings, and #foo = 'foo' is false, so in the XPath lib itself (which now supports GS), I NEVER use Symbols as Strings. But on Squeak/Pharo, this won't hurt you. if you don't need porting, do what you like. > myDocument / 'entity' @ 'name' This is the "DSL" syntax. There are binary messages for each XPath axis: // for "descendant", //~ for "descendant-or-self", ~ for "self" and more in the "enumerating - axis" category. The XPath compiler actually generates sends of these but with block arguments that don't need parsing (string arguments are treated as NameTests and can have wildcard or type tests like '*', '*:foo', or 'text()'). Because the string args are parsed every time, using xPath: can be faster if you save the compiled XPath (like in an inst/class var: "savedXPath := 'some/path' asXPath") and reuse it (with "aNode xPath: savedXPath"). There's also a global compiled XPath cache that's checked before compiling an expression, so xPath: can still be faster even if you don't bother saving. Remember the xPath: usage gives access to full XPath syntax (not just axis and nametests), including predicates, functions, and variables. XPath is really a different language so mapping it all to a ST DSL is tricky. For example, XPath 1.0 is weakly typed so "1" = 1 = "1.0" but clearly this is false in ST. Be aware of the differences when you go from one to the other.
