Microsoft has LINQ, which is intended to be the uber-XML language that will replace XQuery, XSLT, XML Schema, e4x and the kitchen sink. We've been here before - promise the moon, but rather than dealing with open standards create a proprietary technology that shows Microsoft's obvious superiority in this arena while working to make the Microsoft walled community just that much more opaque to the outside world.

Ten years ago, I was an ardent Microsoft advocate, but I watched this pattern occur time and time again, and with each such broken promise (always driven by the mantra "The customer doesn't want those features, without ever really defining who that customer may be.") I became ever more disillusioned with the company. I don't think that Microsoft is evil. I do think that Microsoft is embarked on a poor strategy to protect what they perceive of as a god-given monopoly rather than adapting to the needs and flows of the twenty first centuries.

Microsoft is too big to fail, but in the end it will likely become another AOL - a company that tried to create a walled "web-like" partition and failed, and that is now becoming increasingly irrelevant as a consequence.

If they were to turn those resources towards building a more open, web-friendly, standards compliant base of technologies, they could become dominant very quickly, but there are few indications that this is in fact happening. Instead, they're pushing to become the best application software company in an age where software itself is simplifying and componentizing, and the definition of "applications" is increasingly becoming problematic.

BTW, ping me when you can for a time to record that works for you.

-- Kurt

@Kurt,

Of course I can only agree. It would be unfortunate to see Yet Another Broken Promise from MSFT, but if they have no immediate plans to deliver an XSLT 2.0 engine, the right thing to do is to come out and let people know such that other companies that have interest in this marketplace but are afraid that a MSFT XSLT 2.0 would weaken any chance of making a profit can move forward with a bit more confidence that they won't be squashed if they do.

>> BTW, ping me when you can for a time to record that works for you.

Check your email. :)

Kurt,

The entire industry is looking beyond pure XML technologies such as XSLT for building the next generation of applications. XML still has a vital role to play in exchanging data across applications and platforms, but I think we long-time XML geeks have to admit that putting XML at the center of business logic, display, *and* data interchange has not been well received. The reality that "the customer doesn't want those features" became extremely clear to me after 2 1/2 years on the XML team at MS. They want things like an easier API for working with XML, an cleaner way to build rich internet applications that work across browsers, a better ways of bridging the object - relational - XML type systems mismatches, and all sorts of other things that aren't addressed by XSLT2.

This isn't about standards vs non-standards, it's about a) supporting the standards that are critical for interoperability; b) balancing investment in new standards such as XSLT2 with investment in improving the productivity of those using the existing standards (e.g. the XSLT debugging and performance improvements in Visual Studio 2008); and c) investing in innovation to address the pain points that developers feel when they work with the XML standards. All the companies in this part of the industry are rapidly inventing new ways of building applications that best exploit both the web and the client platform. The successful innovations will presumably become the basis for the next generation of standards, just as the Web standards displaced the previous generation of CORBA, SGML, etc. standards.

There are no broken promises from the MS XML team, there are shifting realities and priorities. The quote from the team weblog in the original post made it clear that ship dates depended on such things as customer demand. The demand for XSLT2 is non-negligible and AFAIK the work *is* in progress, if not at the priority envisioned a year ago. For example, the apparent (and unmet) demand for a typed LINQ to XML capability exceeds demand for XSLT2 by a considerable margin, and I don't think any actual customers who have used the XML capabilities built into VB9 have come back and said "nice, but what we really wanted was XSLT2."

You're right that "the definition of applications is increasingly becoming problematic" and that a closed, web-unfriendly approach to addressing that challenge is doomed to fail. You're wrong if you think that Microsoft is addressing that challenge by ignoring the Web standards and building and old-fashioned walled garden. For example the Astoria project (from the Data Programmability group that also owns XML) is all about exposing databases via XML, JSON, and RESTful HTTP. Likewise LINQ is about making it easier to program against all types of data, which could increase the use of interoperable XML by reducing the pain of working with it. Silverlight is all about making Web based applications good looking, portable, and buildable by mainstream developers. XSLT has many virtues, but easy usability by mainstream developers is not one of them.

@Mike,

Thanks for taking the time to follow-up. Of course I know you are fully aware of my feelings on the matter, but I also know that you know I recognize your final point,

>> XSLT has many virtues, but easy usability by mainstream developers is not one of them.

Fair enough and agreed. XSLT 1.0 *AND/OR* 2.0 is not for everyone. It's one of the more powerful languages we XML-Devs have in our tool bags, but it requires you to think outside the typical confines of a typical CS degree to fully grok how to use it properly. I think LINQ-to-XML is going to help change this tendency quite a bit, but I certainly don't believe it needs or even will be at the expense of gaining access to a native .NET XSLT 2.0 processor (AKA an XSLT 2.0 processor written in a native managed language such as C# (though F# has always struck me as the language best suited to write a data processing intensive functional languages in, though C#/LINQ is also a good choice. Given that XSLT is a dynamic language as well, the DLR also seems like a good choice to extend from. Combining the two together, to me anyway, seems ideal.)

As specified in my follow-up to Kurt, I think the best possible thing that could happen at this stage is for MSFT to lay the cards on the table and let the XML community as a whole decide how they want to react. If the release of an XSLT 2.0 processor CTP is delayed past the release of Orcas and it makes sense for MSFT to put the task of writing a native .NET XSLT 2.0 processor in the hands of the open source XML community and/or the hands of the retail tools vendors, then publicly encouraging just such a thing I believe would go a long ways in highlighting the fact that while priorities might change, maintaining professional integrity is still at the forefront of MSFT's business model.

On the flip side, assuming that yes, in fact, priorities have changed the absolute worst thing MSFT could do at this point is to say nothing, as for MSFT to say nothing translates to the perception that MSFT is attempting to kill any potential competing technologies, chilling innovation using fear, uncertainty, and doubt to ensure that nobody dares take on the task of building a technology that could be seen as competition to LINQ-to-XML using "yes, we're working on that" but never actually releasing anything to silently drive fear and, once again, chill any potential innovation from the competition.

At least that's the way I would look at it. I'm sure others would look at it in the same manner, regardless of whether or not it's actually the case.

I'll have to be turn on the anonymous cloak for this one:
"Oops! I did it again."

I think she's an unappreciated genius btw, for crystallizing such ethos.

@Cloaked "I, Anonymous",

>> "Oops! I did it again."

Yeah, I would have turned on the anonymous cloak too! ;-) :D

>> I think she's an unappreciated genius btw, for crystallizing such ethos.

Now if she could just quit smoking the crystal and huffin' the ether, maybe that genius could make itself known (again?). ;-)

I have had greater success creating a MVC solution using XML / XSLT technologies than MS ASP.NET webforms. My client has seen firsthand the places where ASP.NET's RAD capabilities has led to unmaintainable solutions compared to a well-designed MVC framework. Furthermore, with their developers trained on building apps the MVC was they are *inherently* cross-trained to support each others applications.

It is unfortunate that XSLT continues to be considered a competitive technology for ASP.NET and will continue to be a second-thought to MS [http://msdn2.microsoft.com/en-us/library/ms950754.aspx].

I stand in the middle on this one.
I am a hard core Microsoft dev, MS is supporting JSON , AND it is hard to support a moving standard.
HOWEVER, I also am active in Open Source, I use XML a LOT, and I see other people that implment new technology faster gain more.
LINQ does NOT replace XML. It is more a compiler trick that you can do in .net 2.0 if you implment the IEnumerable delegate callback.
Mike is right: XML docs do not belong in a relational store. On the other hand, LINQ does not belong in the UI.
Mike: I am VERY excited about a restful web with Astoria and other great projects, but I would LOVE to see you implement XSLT2.

@HoyaSaxa93,

>> I have had greater success creating a MVC solution using XML / XSLT technologies than MS ASP.NET webforms.

Would it even be possible with ASP.NET to create an MVC framework? I guess you could kinda/sorta mimic something similar if you tried *REALLY* hard, but why would you want to try that hard when you can use XML/XSLT, MonoRail, and/or skip .NET all together and use RoR? I can't think of any good reasons. Anyone else?

>> My client has seen firsthand the places where ASP.NET's RAD capabilities has led to unmaintainable solutions compared to a well-designed MVC framework.

The problem, I believe, with typical RAD development environments is that they place the tool front and center, setting aside maintainable design outside of the confines of that tool. The problem, of course, comes when somebody dares to make an attempt at hacking at the code base outside of the confines of the given tool. The result, as you obviously are fully aware, is a disaster.

>> Furthermore, with their developers trained on building apps the MVC was they are *inherently* cross-trained to support each others applications.

MVC is a beautiful paradigm. I've been working on a client-side XSLT 1.0/Server-side 2.0 MVC application[1] now for the last year++ and can't imagine ever going back to anything else.

>> It is unfortunate that XSLT continues to be considered a competitive technology for ASP.NET and will continue to be a second-thought to MS [http://msdn2.microsoft.com/en-us/library/ms950754.aspx].

I'm not 100% convinced at this stage MSFT sees XSLT as a threat. They just can't generate any money off of XSLT. At least not in the way they can with ASP.NET as it relates to the tools and server technlogies (VS.NET and IIS/SQL Server respectively), and in this regard you can't really blame them. But what chaps my a$$ is the on again, off again "we're working on it but we're not going to tell you when it will be ready." game they continue to play. They need to either fess up to the fact that it isn't a priority and they have no clue if and/or when it will ever be, or they need to follow through with their perceived commitments.

As per Mike's comment above, I realize there were plenty of statements made that ensured they could back away from the "CTP around the Orcas time frame" and do so with confidence that they could make statement such as "see, we never really committed to anything, just suggested this as a possibility." but what seems to be overlooked is that people don't want to listen to the same old "we never committed to anything." They want an XSLT 2.0 processor, and to be quite frank are sick and tired of the bullshit that's being constantly fed our direction.

So MSFT: When does the bullshit stop and the deliveries begin? Or does it and do they? You folks do a damn re-org every 6 months, so are we forced into applying a "if it nots delivered in six months, forget about it" rule to everything that comes from your general direction?

Just a thought, but maybe you start writing some of these things down so that the next group that comes in 6 months from now knows what they're getting themselves into. Need to borrow some paper and pencil? God knows the tablet was a complete flop. Maybe its time you paid attention to the market and went back to the basics?

Again, just a thought...

[1] http://nuxleus.googlecode.com/svn/trunk/nuxleus/Web/Development/transform/

@Ric,

>> Mike: I am VERY excited about a restful web with Astoria and other great projects, but I would LOVE to see you implement XSLT2.

You and I both!

@M David-
Microsoft IS working on MVC:
http://damieng.com/blog/2007/10/09/observations-on-microsoft-mvc-for-aspnet
http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx

Also Model-View-Controller is great, but do not forget MVP, MVA, or other GoF patterns. Have you looked at the Web Client Software Factory ? :
This is NOT the old Microsoft. They are learning and making some really great software. But I agree that it is time to keep their promise. No weasel words about it: even if they did not 'legally' make a promise - the developer community believes they should deliver XSLT2 (and some other technologies as well)

@Mike: We can all stop arguing about this if you just DO it. We will blog about it on how you listened to the community and really understand the needs of (.Net) developers, (XML) developers, and (JSON) developers.

To blow my own horn, I am very happy that Microsoft has joined OpenAjax, BUT I am worried they they may not develop it further, and seek to push XAML instead. Can I get a reply on this? Kurt has done a recent (great) post on this, but I would love to hear your views as well

@Ric,

Didn't know about the MVC project. Thanks for the link! (/me now realizes that yes, in fact, it is possible to develop an MVC framework around ASP.NET)

>> This is NOT the old Microsoft. They are learning and making some really great software.

Well, Scott Guthrie certainly represents a shining example of what the NEW Microsoft is all about. But when Mike Champion and Alex Barnett left the Web Data team during the first part of this year, while I kept silent on the matter, my biggest concern was that all the goodness and sanity these two folks brought to the Web Data team would be lost.

It seems now my concerns were, in fact, legitimate. Of course I have no clue why either of them chose to leave, but if it had anything to do with spending their days beating their heads against the wall while dealing with this neandrethal way of thinking, I really can't blame either of them for leaving. I would have done the same thing.

In summary: MSFT is a *BIG* company. On one side you have the ScottGu's and the Mike Champion's (Alex Barnett is no longer w/ MSFT, otherwise he would be included in this list as well) who are doing everything they can to build MSFT into a better company, and on the other side you have the "We're MSFT, damn it! We can do no wrong and you're never right."-type which is what got MSFT the bad reputation in the first place.

Hey OLD MSFT: Don't you think it's time to start evolving like the rest of your family? Personally I *REALLY* like some of the work you're doing in the Web Data space. But building an XSLT 2.0 processor at a glacial pace w/o any sort of road map as to when it will be in the hands of your customers is simply unacceptable. And responding to the requests for information by saying nothing does nothing to help, and *EVERYTHING* to hurt.

I'm so over Executable XML, and onto DSLs not written in XML. Don't get me wrong, XSLT rocks. But forcing a domain specific language into angle brackets just because we are too lazy to write a parser is so 1999. Plus, it doesn't translate well into internal DSLs. Which is why LINQ is so cool. One syntax to query any data store, that works for me. I'm tired of trying to teach developers the nuisances of XPath, XML Namespaces, DOM, XSLT, XQuery. All great technologies on their own, but never really designed to work together well. The DOM just plain sucks. It was designed at a time when C++ was king. That API is just plain tired. New fluent interfaces and internal DSLs make it so much easier to understand and work with complex object models. It is time to archive these old technologies and move forward with better self describing object models. So, someone has to go out and experiment, and when something winds up working, a committee can be formed to standardize it. Right now, I want more options, not less, because what we have now isn't making it, and we are getting bogged down. Time for some innovation.