In between re-writing and updating the chapters for the beta version of the my book A First Look at ADO.NET and System.Xml V2.0, I found some time to write an article on Building Custom XmlResolvers for MSDN. What’s so great about this class is that it enables you to redirect the location of the XML that you want to load, as well as allowing you to define your own schemes, if necessary (e.g. db:// to load from a database). There are all sorts of great things that you can do with an XmlResolver and you can come up with some fairly intelligent caching solutions if your applications needs this. One aspect that I did not cover in this article is the use of the credentials property of the XmlResolver which there is a good KB article about here
As this went to press I was talking to a PM on the Frontpage team who complained that one problem they were having is that they did multiple round trips to a SQL Server data base in order to load <xsl:include> stylesheets i.e. one trip per include and this was obviously having a impact on stylesheet compile time in some scenarios. No problem I said, simply write your own XmlResolver that batches up all the <xsl:include> requests into a single batch call to the database and caches them in-memory. You will need to parse the <xsl:include>s in advance is order to know which stylesheets to load, but a quick read with an XmlTextReader on the XSLT stylesheet can tell you the list, which you can then give to the XmlResolver.
It would be good to hear of any uses that you have for custom XmlResolvers in your applications.