Additional functionality for searching by path?

[aleph1]

Would you be willing to consider a pull request that enhances the functionality of xmldoc to allows for finding all descendants by a path? What I am thinking is that it will function like descendantWithPath, but with some additional substrings that are useful:

What I am thinking is that it will function like descendantWithPath, but with some additional substrings that are useful:

. = direct child
.. = anywhere in tree

This could be useful for extracting things like all items from a navigation tree, such as:

<items>
  <item id="1" />
  <item id="2">
    <item id="2.1">
      <item id="2.1.1" />
      <item id="2.1.2" />
    </item>
    <item id="2.2" />
    <item id="2.3" />
  </item>
<items>

var itemNodes = itemsNode.descendantsWithPath("..item") would return an array of all <item> nodes.

This would allow other types of nested paths as well:

<inventory>
  <books>
    <book>
      <name>My First Book</name>
      <author>John Smith</author>
      <editions>
        <edition>
          <publisher>Big Type Press</publisher>
          <year>2021</year>
        </edition>
        <edition>
          <publisher>Big Type Press UK</publisher>
          <year>2022</year>
        </edition>
      </editions>
    </book>
  </books>
  <posters>
    …
  </posters>
  <records>
    …
  </records>
</inventory>

var bookPublisherNodes = inventoryNode.descendantsWithPath("books.book..publisher") would return an array of all <publisher> nodes.

[nfarina]

I love this! It feels very "glob" like and natural, and doesn't change any existing semantics. Would definitely merge this!

[aleph1]

The only issue I can see with my original approach and how descendant paths are implemented at present is that the “.” (period) is allowed in XML tag names. Would it make more sense for me to follow the XPath convention of using "/' and "//"? Sadly, this would be a breaking change from your current implementation, and a better solution might be to add a method to XmlDocument called "query" and implement this portion of XPath with the hopes of adding other XPath query features after.

I think the latter approach is probably the better one.

[nfarina]

Hm, well I wouldn't want to optimize for cases that should be pretty rare (been a while since XAML 😂 ) - perhaps we could allow escaping periods somehow in the search string? But this is already a problem with the current implementation so I don't think supporting ".." would be a breaking change.

I'm not sure supporting a small amount of Actual XPath would be better than not supporting it at all. Like, if you knew XPath syntax already you'd likely run into a wall pretty quick, so your existing knowledge won't be all that useful. Better I think to just have a tiny language of our own.

[aleph1]

Sounds good. I will stick with . (child) and .. (descendant) as query contexts. Since the backslash isn’t an acceptable in an element name, I could add backslash support to the existing descendantWithPath method. For example: ``` // historic paths that would already be in use with this lib bookNode.descendantWithPath(‘author.name’); // escaped paths in cases where a node name includes one or more periods // for example: // // <styles> // <component.checkbox color="white" borderColor="black" /> // </styles> stylesNode.descendantWithPath('component\.checkbox');

[nfarina]

I like the backslash character idea but note that it would require two of them, like "component\\.checkbox". Otherwise it just gets erased when the string is built.