Don Demsak has a post entitled XSLT 2.0, Microsoft, and the future of System.Xml which has some insightful perspectives on the future of XML in the .NET Framework
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.
...
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 buried in 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.
The System.Xml team has tended to use the first methodology, where the
ASP.Net team tends to build their core stuff according to the second
methodology, and then have a sub-team create another library using the first
methodology, so developers have something to use right out of the box (think of
System.Web.UI.HtmlControls as the low level API and System.Web.UI.WebControls as
the higher level API). The ASP.Net team builds their API this way because, from
the beginning, they have always envisioned 3rd parties extending their library.
At the moment, this is not the case for the System.Xml library. But the
question is, should System.Xml be revamped and become a lower level API, and
then rely on 3rd parties (like the Mvp.Xml project) to create more specific and
easier to use APIs? Obviously this is not something to be taken lightly. It
will be more costly to expose more of the internals of System.Xml. But, if only
the lower level API was part of the core .Net framework, it may then be possible
to roll out newer, higher level, APIs on a release schedule different then the
.Net framework schedule. This way projects like XSLT 2.0 could be released
without having to what for the next version of the framework.
I’ve always been of the opinion that XSLT 2.0 does not need to be part of
the core .Net framework. Oleg doesn’t believe that the .Net open source
community is as passionate as some of the other communities, so he would like to
see Microsoft build XSLT 2.0. I’d rather see the transformation of the
System.Xml team into more of an ASP.Net like team. If .Net is the future of
development on the Windows platform, and XML is the future of Microsoft, then
the System.Xml team needs to grow beyond its legacy as just an offshoot of the
SQL Server team. The System.Xml team still resides in the SQL Server building.
Back before .Net, the System.Xml was known as the SQL Web Data team, and
unfortunately, still carries some of that mentality. Folks like Joshua Allen
and Dare (who are both not on the team anymore) fought to bring the team out
from the shadows of SQL Server. With new XML related groups, like XLinq and
Windows Communication Framework, popping up within the company the System.Xml
group is at a major crossroads. They will either grow (in status and budget)
and become more like the ASP.Net or they will get absorbed into one of the new
groups.
I’d prefer to see the System.Xml team grow and become full partners with
teams like ASP.Net and the CLR team. I’d like to see the XML based languages
become first class programming languages within the Visual Studio IDE. That
means not only using things like XSLT and XML Schema as dynamic languages, but
also be able to compile them down to IL and compiled with the other .Net
languages. I want to be able to create projects that contain not only VB or C#,
but also XSLT and XML Schema (to name a couple), and have them compile into one
executable. Then developers can use things like XSLT 2.0, or the next in vogue
XML based language, and take advantage of that language’s unique benefits,
without having to choose between a compiled procedural language (like C# or VB)
and dynamic functional languages like XSLT. Linq is starting to bring in more
of the functional programming style to the average procedural programmer, so I
can start to see the rise public awareness of functional programming. It is
only a matter of time before the average programmer feels as comfortable with
functional programming as they do with procedural programming, so we need to
look towards including these languages within the Visual Studio IDE (which then
leads into my discussion about evolving Visual Studio into more of an IDE
Framework, and extended with add-ins.)
There is a lot of stuff which I agree with in Don's post which is
why I forwarded it to some of the folks on the XML team. I'll be having
lunch over there today to talk about some of the topics it raised
Don does gloss over something when it comes to the decision between
whether Microsoft should implement a technology like XSLT 2.0 or
whether we should just make it easy for third parties to do so. The
truth is that Microsoft now has a large number of products which
utilize XML-related technologies. For example, implementing something
like XSLT 2.0 isn't just about providing a new version of the System.Xml.Xsl.XslCompiledTransform Class
in the .NET Framework. It's also about deciding whether to update the
XSLT engine used by Internet Explorer to support XSLT 2.0 (which is an
entirely different code base), it's about adding support to the XSLT
debugger in Visual Studio to support XSLT 2.0, and maybe even updating
the Biztalk Mapper.
Users of Microsoft products expect a cohesive and comprehensive
experience. In many cases, only Microsoft can provide that experience
(e.g. supporting XSLT 2.0 across our entire breadth of technologies and
products that use XSLT). It was a really tough balance deciding what we
should make extensible and what was too expensive to make extensible
since we'd probably be the only ones who could take proper advantage of
it when I was on the XML team. I'm glad to see that some of our MVPs
understand how delicate of a balancing act shipping platform
technologies can be.