Oleg accidentally restarted the XSLT 2.0 on .Net firestorm by trying to startup an informal survey. Dare chimed in with his view of how to get XSLT 2.0 in .Net. M. David (the guy behind Saxon.Net which let .Net developers use Saxon on .Net) jumped in with his opinion.
But in the end, what does all this mean. From the outsider viewpoint, it could look like the .Net XML guys are fighting publicly, but let me assure you, that isn’t the case. Visual Studio 2005 and .Net has finally shipped, and now is the time to start looking at what should make it into the next version. The System.Xml team is hard a work compiling a list of things that may or may not make it into future releases, and Oleg is taking advantage of this, and is trying to help come up with support for things that he would like to see in the future of System.Xml. The System.Xml team has previously asked for feedback on various ideas (XML Projects being one of them), so now is your chance to get your voice heard.
One of the things that I’ve struggled with in System.Xml is how hard it is sometimes to extend the core library. The XML MVPs have done a good job with some things, but other things (like implementing XSLT 2.0 on top of the XSLT 1.0 stuff) are impossible because so much of the library is internal classes. When building a complex library like System.Xml, there are 2 competing schools of thought:
- Make the library easy to use and create a very small public facing surface area.
- Make the library more of a core library with most classes and attributes public, and let others build easy (and very specific) object models on top of it.
The upside of the first methodology is that it is much easier to test, and the library just works out of the box. The downside is that it very hard to extend the library, so it can only be used in very specific ways.
The upside of the second methodology is that you don’t have to trying to envision all the ways the library should be used. Over time others will extend it to accomplish things that the original developers never thought of. The downside is that you have a much larger surface area to test, and you are totally reliant on other projects to make your library useful. This goes for both projects internal to Microsoft and external projects like the Mvp.Xml lib.
Program with ASP.NET - Create richer apps with ASP.NET 2.0 Get free online training.
Deploy secure Smart Client apps. Learn how on MSDN's Smart Client Virtual Labs.
Preview the new Visual Studio 2005. Step into the Visual Studio 2005 Virtual Labs for Free.