XmlNamespaceManager. Use a preconstructed manager or create a new one for each XmlDocument?
===

If you want to execute an XPath against an XmlDocument then the pattern is something like:

    XmlDocument xmlDoc = GetDoc();
    XmlNamespaceManager nsMgr = new XmlNamespaceManager(xmlDoc.NameTable);
    nsMgr.Add("foo","foo.bar.com");
    xmlDoc.SelectNodes("/foo:Orders/foo:Order", nsMgr);

As I understand it the re-use of the XmlNameTable here isn't mandatory, alternatively we could create a completely new XmlNameTable and pass that into the namespace manager instead. The re-use means that the namespace prefix and URI strings are atomised into the same XmlNameTable as the XmlDocument's string content such that when comparing the namespace URI on each element (when executing the XPath) a fast object compare can be used instead of a full string comparison (compare string length and characters) - presumably because the XPath execution code checks if the XmlDocument and the XmlNamespaceManager are using the same XmlNameTable or not

On the other hand to use this pattern we need to create an XmlNamespaceManager for each XmlDocument we want to execute XPaths against - and register the prefix URI pairs against each one. I suppose ideally we would create the XmlDocument objects using a shared XmlNameTable, perhaps that is the preferred approach if you have control over the construction of the XmlDocument objects(?)

A final concern though is that if we do re-use XmlNamespaceManager(s) then are they thread safe? If I make the assumption that no further prefix-URI pairs will be registered then it should be, but without the ability to lock down the XmlNamespaceManager to prevent modifications being made to it, re-using it on multiple threads would appear to be an unsafe pattern to use. Thus my instinct is to revert back to using a newly constructed XmlNamespaceManager as and when I need one, use the XmlNameTable from the XmlDocument being targeted thus avoiding the need to have any control on the name table used when the XmlDocument was created (which might involve some refactoring effort in existing projects).

