M. David,
This is indeed very bad news. I also have been a very strong supporter of Microsoft for years, but after the current fiasco with JavaScript 2 I also have lost faith.

@Ric,

I know we both feel that MSFT has made some significants steps forward in the right direction in *MANY* areas. Unfortunately nobody on the XML team seems to have gotten the memo.

Did you ever consider that Microsoft may not be aiming for "best XML processing and development tools" but what the market will bear at any point in time? After all, no one can argue that the Camry is better than a Mazerati, but most people would opt for the former over the latter. That doesn't make Toyota or Mazerati are either good or bad. You and a lot of the readers of your blog are on the far right of the bell curve of XML developers. I'm glad your are there. But, to mix metaphors, you are by definition not the center of the world. Every business does not have to cater to your interests. I think in the near future much more XML will we moving around the web and intranets as the result of Microsoft than niche companies or even more formidable competitors. Microsofts' XML and XSLT capabilites in the browser far outshine those of its real competitors. I haven't seen anyone critisizing Mozilla for being behind the power curve on XSLT implementation. Criticism is fine. Just be balanced.

> But, to mix metaphors, you are by definition not
> the center of the world. Every business does not
> have to cater to your interests. I think in the
> near future much more XML will we moving around
> the web and intranets as the result of Microsoft
> than niche companies or even more formidable
> competitors.
> Microsofts' XML and XSLT capabilites in the
> browser far outshine those of its real
> competitors. I haven't seen anyone critisizing
> Mozilla for being behind the power curve on XSLT
> implementation. Criticism is fine. Just be
> balanced.

Mark,
You completely don't understand what M.D. Peterson is talking about. He does not attempt at all to persuade Microsoft to implement XSLT 2.0.

On the contrary, M.D. is expressing his great disappointment in the inability of Microsoft to plan and keep its promises.

We have to agree with the facts that a year and a half after Microsoft announced they were planning to implement XSLT 2.0, they have not even started and Chris Lovett has now officially confirmed Microsoft do not even plan to do any such implementation.

The conclusion is that it is not safe to believe what Microsoft are saying. They do not keep their word, show no planning or managerial ability.

M.D. is concerned that in this way Microsoft is misleading even its most loyal customers. So, who are Microsoft? Liers and cowards? More and more people will now say that Microsoft indeed are liers. More and more people will now say that the the true reason Microsoft does not proceed with the promised XSLT 2.0 implementation is that Microsoft are simply too incompetent to do this successfully. Their "concern" about markets and "profitability" is just a convenient excuse to hide the fact that Microsoft have turned into incompetents.

This is a fresh example how Microsoft hinders the acceptance of new technoloies and how it takes its customers as hostages while doing so.

As for Microsofts' XML and XSLT capabilites in the browser far outshining those of its real competitors, such a statement only shows how isolated Microsoft are from the real world. Microsoft's XML technology in the browser dominated its competitors seven or five years ago, today this is no longer true.

The reality is that Microsoft has put itself very far behind the competition, in a sad and hopeless situation.

M.D's post is a awakening signal to the last, very few still loyal Microsoft customers. Incompetence, lack of imagination, inability to take any risk,absolute lack of planning have led to the current results in the area of XML and XSLT.

It would be a great pity if MS didn't support XSLT2. LINQ has "loser" written all over it. Who cares?

XSLT 2 works, is a nice step up from XSLT 1, and has a really low learning curve.

@Mark,

While I think "anonymous" summed things up quite nicely, let me respond to a few of your questions/points,

>> Did you ever consider that Microsoft may not be aiming for "best XML processing and development tools" but what the market will bear at any point in time?

So you're suggesting that the market can't bear the best XML processing and development tools? That doesn't even make any sense!

Maybe your point is that you believe that the market isn't interested in what I might think are the best XML processing and development tools? If yes, please show me your evidence as such.

Oh, and before you do, please take the following statement from Chris LoveNothingMoreThanMyOwnDamnOpinion into consideration,

but right now we’re in the middle of a big strategic investment in LINQ and EDM for the future of the data programming platform which we think will create major improvements in programming against all types of data.

emphasis mine.

>> After all, no one can argue that the Camry is better than a Mazerati, but most people would opt for the former over the latter.

This isn't about Camry's or Mazerati's. This is about building tools and processors based on top of industry standards instead of, once again, redesigning the wheel in a way *they* feel is best, not what's in the best interests of their customers. Now I'm not suggesting that Microsoft shouldn't be innovative. They absolutely should. But not by replacing a standard with a "standard" of their own and instead by providing support for baseline standards and then offering a choice -- an upgrade if you will -- to the technology they feel might be a better fit. If it is, *GREAT*, but taking away the choice of sticking with a standard doesn't encourage choice -- it results in vendor lock in.

>> You and a lot of the readers of your blog are on the far right of the bell curve of XML developers.

And we're there because we placed our focus on building technologies on top of standards! That doesn't mean we can't take these standards and make better things with them. What it means is it's the standards that sit at the foundation which ensures a greater level of choice, enhancing these standards in ways that helps differentiate ourselves from the competition.

Don't get me wrong: I think LINQ, and in particular, LINQ to XML is *GREAT*! But not as a replacement for XSLT, and instead as an enhancement to my overall choices of tools and technologies.

>> Microsofts' XML and XSLT capabilites in the browser far outshine those of its real competitors.

No they don't. They used to. But not anymore.

>> I haven't seen anyone critisizing Mozilla for being behind the power curve on XSLT implementation.

You need to look a little bit harder then, because that criticism is everywhere.

>> Criticism is fine. Just be balanced.

This is obviously the first time you have read anything I have written, isn't it? I criticize *EVERYONE* who deserves the criticism, and praise *EVERYONE* who deserves the praise. If there is one thing that I can say is balanced in my life, for better or for worse, this would be that balance.

@anonymous,

Whomever you are, thanks for making things absolutely crystal clear as to the reasoning for my frustration. To everyone else: What anonymous said.

@Rick,

>> It would be a great pity if MS didn't support XSLT2.

Oh I think at this stage it's a done deal. There putting their money on LINQ, and until such time as their bet doesn't pay off, they're not going to be putting any resources into any other alternatives.

Of course I could be proven wrong. And in fact, hope that I am. But I think they've made their point crystal clear: We're betting the farm on LINQ.

>> LINQ has "loser" written all over it. Who cares?

There are certainly sime nice features of LINQ that I have found useful. And given that it's compiled, it's pretty damn fast. But it's not intuitive to write, so the learning curve argument is bullshit when attempting to compare the learning curve to XSLT. And XSLT has a significant developer base of people that already have gotten through the learning curve. XSLT 2.0 just builds upon that knowledge, so there nothing to overcome, where as with LINQ there most certainly is.

>> XSLT 2 works, is a nice step up from XSLT 1, and has a really low learning curve.

Absolutely 100% agree!

Is it just me, or has Microsoft been channeling Sony? This has Betamax written all over it.

@Edmond,

>> Is it just me, or has Microsoft been channeling Sony? This has Betamax written all over it.

:D :D :D No, it's *DEFINITELY* not you.

thanks for the laugh! :D

@whomever

>>> After all, no one can argue that the Camry is better than a Mazerati, but most people would opt for the former over the latter.

> This isn't about Camry's or Mazerati's. This is about building tools and processors based on top of industry standards instead of, once again, redesigning the wheel in a way *they* feel is best, not what's in the best interests of their customers. Now I'm not suggesting that Microsoft shouldn't be innovative. They absolutely should. But not by replacing a standard with a "standard" of their own and instead by providing support for baseline standards and then offering a choice -- an upgrade if you will -- to the technology they feel might be a better fit. If it is, *GREAT*, but taking away the choice of sticking with a standard doesn't encourage choice -- it results in vendor lock in.

>>> You and a lot of the readers of your blog are on the far right of the bell curve of XML developers.

>> And we're there because we placed our focus on building technologies on top of standards! That doesn't mean we can't take these standards and make better things with them. What it means is it's the standards that sit at the foundation which ensures a greater level of choice, enhancing these standards in ways that helps differentiate ourselves from the competition.

-------

I take all your points but I would like to say that developers are not the ultimate Microsoft customers -- they certainly don't pay all those licensing fees. From what I've seen Microsoft products are demanded by the end users in many cases. Try to take Word away from an office worker. I've seen several major projects fail trying to do that. And Microsoft also answers to their investors, who can force management change.

What successful company does not try vendor lock-in? I'm not defending Microsoft, but they will do what they think makes the most money for them. Sun, or Oracle or Google will do the same if they can.

>>The conclusion is that it is not safe to believe what Microsoft are saying. They do not keep their word, show no planning or managerial ability.

What is the ROI to MS of adding XSLT 2.0 support? MS now has Oracle in its sites and it is hard to say that overall they are pursuing a losing strategy.

People have been predicting the demise of Microsoft since day 1 and they have always been proven wrong. I know that all of you know much more about the industry than I, but I would like to see a more sophisticated, "big-picture" discussion. Get real. If Microsoft has no planning or managerial ability I guess they just have lucked out for the last few decades. Your statement is silly hyperbole. I would like to see you write a Ph.D. thesis on how Microsoft lacks plannning or managerial ability. It would be very interesting. But this is blog-land so say whatever you like.

>>Maybe your point is that you believe that the market isn't interested in what I might think are the best XML processing and development tools? If yes, please show me your evidence as such.

I live in a world in which many, many developers still do not understand, like or use XML or its plethora of related standards, vocabularies, etc. I wish that were not the case. I wonder what perentage of dbs that have XML capabilities are using those capabilities. I would be interested to know if anyonw has statistics on this (I'm sure MS isn't telling).

I raise all these points as a "devil's advocate" to gain greater understanding and invite your corrections to all of my factual and logical errors.

@Mark,

>> I take all your points but I would like to say that developers are not the ultimate Microsoft customers -- they certainly don't pay all those licensing fees.

I used to work on the Visual Studio team (VC++ and VS for Windows CE). I assure you > VS and MSDN generates significant revenue for MSFT. It doesn't generate the same type of revenue that Office generates, but the thing about MSFT is that for all intents and purposes, each product and division is it's own separate company. Just because one division generates most of Microsoft's profit doesn't mean all of the other divisions are off the hook. If you run a product or division @ MSFT, your a$$ is on the line to generate profit. The only division @ MSFT that isn't required to generate a profit (well it used to be this way back in the '90's. I assume it still is.) is MCS (Microsoft Consulting Services) as their primary task is to sell more product licenses for the products that all of the other divisions create (and therefore the profits hit their balance sheets, not MCS)

>> From what I've seen Microsoft products are demanded by the end users in many cases. Try to take Word away from an office worker. I've seen several major projects fail trying to do that.

But we're talking about developer tools here. Office obviously makes MSFT a good portion of their profit each quarter, but while developers may not be MSFT's most profitable customers, they're certainly not going to start using Word and VBA to develop the next killer-app, so I'm not really sure I understand your point.

>> And Microsoft also answers to their investors, who can force management change.

My problem isn't with MSFT generating a profit. God bless them for making a profit in fact, as it gives a lot of good people a lot of good jobs. I'm not a MSFT basher by any stretch of the imagination. I think they're a great company that does a lot of great things, and most definitely get a lot of flack just because they're MSFT, not because they deserve it. However, this time they do deserve it: They announced they were actively working on and would be providing an XSLT 2.0 processor, suggested the CTP's for the XSLT 2.0 processor would be made available around the Orcas time frame, and then said nothing to suggest there plans had changed.

To make a long story that much more painfully longer, the Orcas time frame has come and gone, and when queried about when the first CTP would be available they went silent. No response for almost two months until just last week when they published a carefully crafted interview with Chris LovettOrLeaveIt-ItsMyWayOrTheHighway in which stated nothing about "We know we announced we were working on an XSLT 2.0 processor, but based on Func<Reason,Reason,Reason,LameExcuse> justify = (X,Y,Z) => X+Y+Z we've decided that now is just not the time. We suck, we're sorry, we recognize you have every reason and justification in the world to hate us, and promise to never, ever, ever do it again. Oh, an no take backs, either!" and instead answering their own self imposed question "Will support for XQuery 1.0 and XSLT 2.0 become part of Microsoft’s offering?" with "We've heard about how XSLT 2.0 *ROCKS* the casba over XSLT 1.0, but we really don't give a damn because we think we've got all the customer will ever want or need in LINQ to XML" to then try and weasel their way out of it with "But we're always listening, so if you're about to blow a gasket right now because we suck so bad, drop us a line so we can feed you the same old bullshit we've always been feeding you, and then try to sell you on just how great LINQ to XML is and everything else suckz rockz!"

See here's the thing: By announcing they were creating an XSLT 2.0 processor, any potential vendor interested in doing just that would have been pushed off. Why invest in developing an XSLT 2.0 processor if MSFT is just going to give one away for free? And while there's always Saxon on .NET, 100's upon 1000's of MSFT shops have a MSFT only policy due to the fact that they know MSFT will always be around and they can count gaining support for that product for an expected period of time. On the flip side, by announcing they were developing an XSLT 2.0 processor any company who was considering using Saxon on .NET would have simply stated "Well MSFT is developing one, so lets hold off writing any XSLT 2.0 code until they release their processor so we can ensure the code we write won't have to rewritten if MSFT's implementation/interpretation of the XSLT 2.0 spec is different."

The result?

Chilling innovation centered around XSLT 2.0. They have a name for this practice > It's called VaporwareTM, and no one is better at creating VaporwareTM than MSFT.

Step 1) Announce a feature or product.
Step 2) Wait until the competition has been bled dry.
Step 3) If/when pressed for information on when the feature or product will be released, come up with a nice form letter explaining that they're just not sure when that feature/product will be ready.
Step 4) If never pressed for info, say nothing.
Step 5) Repeat.

>> What successful company does not try vendor lock-in? I'm not defending Microsoft, but they will do what they think makes the most money for them. Sun, or Oracle or Google will do the same if they can.

Oh, I'm not suggesting they shouldn't attempt to retain their customer base by providing reasons for people to stick with MSFT specific technologies. But if LINQ to XML is all that and a bag of chips, then why be overly concerned with providing an XSLT 2.0 processor as well? But regardless of whether or not they are concerned with whether an XSLT 2.0 processor is good or bad for business, my problem is that they used their standard VaporwareTM monopolistic business practice to -- yet again -- ensure they were the only player in any given game.

>> What is the ROI to MS of adding XSLT 2.0 support?

What's the cost?

>> MS now has Oracle in its sites and it is hard to say that overall they are pursuing a losing strategy.

This isn't about pursuing a winning or losing strategy. This is about using the VaporwareTM strategy to ensure they are the only player in any given space

>> People have been predicting the demise of Microsoft since day 1 and they have always been proven wrong.

I've never predicted the demise of MSFT. Overall they are a great company. I'm just pissed off they took the XML development community for a ride and plan to make sure that this process has been well documented for future generations to give heed to. Nothing more. Nothing less.

>> I live in a world in which many, many developers still do not understand, like or use XML or its plethora of related standards, vocabularies, etc. I wish that were not the case. I wonder what perentage of dbs that have XML capabilities are using those capabilities. I would be interested to know if anyonw has statistics on this (I'm sure MS isn't telling).

Microsoft's entire platform is built on top of XML. WS-*? XML. Want to pass your object from one node to the next. Serialize it to XML, pass it over, serialize it back into an object, continue. Want to work with the raw XML of data contained in a SQL Server database? No problem. Just ask and you shall receive. Hell, they even have an XML data type in SQL Server now. In short, this isn't about whether or not people use and/or understand and/or etc. XML. This is about -- you guessed it -- using VaporwareTM to chill innovation.

Okay, I will not say "I told you so." too loudly.

A decade ago, I was solidly in the Microsoft camp ... hell, two of the books that I wrote were specifically for Microsoft products (Visual Basic). After ten years, I am working solidly in Linux, do most of my programming in Java (the bits that I don't do in XML or PHP or occasionally Ruby), and find that I'd be hard pressed to even tell you the last time I even powered up Windows, except for those rare situations where I needed to test code that I otherwise wrote on Linux.

I didn't wake up one day and say "I think I'm going to hate Microsoft today". My disillusion came in slow, steady disappointments - the freeze on IE6, the abandonment of CSS behaviors, the big push towards ActiveDirectory, the consistently "almost" standards that usually included some proprietary hook, the effort by Microsoft to push RAND licenses into the W3C charter, the lack of follow-through on their XML technologies, the consistent move away from openness even as the rest of the world was embracing it, the repeated endorsements on XSLT2 and the subsequent abandonment of same.

What's more, every time this happened, the stock answer was "the customers didn't want it, the customers didn't demand it, this is a very much out of the mainstream opinion".

There's a word that describes people who "play with themselves" - in essence, pleasuring themselves and otherwise accomplishing absolutely nothing. There are times that I wonder if Microsoft hasn't succumbed to the intellectual equivalent, creating new technology not because the demand is there for the tech, but because they need to prove to themselves that they can do things better than the rest of the world, that they were somehow superior to everyone else and utilizing others' technology was somehow unclean and made them look weak.

LINQ is a prime example of this - it is an interesting idea, and for the perhaps few thousand people on the planet who grok functional languages, its kind of cool. Is LINQ going to end up becoming a part of the C++ developer's repertoire? No, of course not. C#? Only in those parts of the code where its practically forced on the developer. VB - um, how many people still actually code in VB.NET anymore? Most of them scrambled to other technologies when they realized that they would have to, yet again, relearn a language that they had only just begun to master, all so that another brilliant idea, the all powerful CLI, could be made to support everything so Microsoft wouldn't need to build true language editors that were completely focused on the language at hand. This had the additional advantage of letting Microsoft create pseudo-languages that were 90% compatible with the real thing, but contained enough hook code to insure that developers would be hard pressed to jump to the more established variant.

There's an intellectual laziness that has pervaded Microsoft - automate everything, so that creating a new product is as simple as changing a few files and pressing the compile button. People do not hate Microsoft because they are successful. Programmers are disgusted with what they see as shoddy code, intellectual laziness, marketing-driven development, and an indifference to extend themselves for any activity that doesn't provide a quantifiable dollar sign.

Programmers require honesty in their lives, because so much of what they are dealing with must either work or be predictable in understanding why it fails to. If you don't deliver in this industry, but make a big show of telling the world how great you are, after a while, you will lose the trust of developers. Microsoft is finding increasingly that it has lost that trust, and no ad campaign, no matter how tear jerking, is going to regain it for them.

Considering the reliance on XSLT in InfoPath (in a big way) and in SharePoint (in a smaller, oft overlooked way with the DataFormWebPart), it surprises me that there is such a lack of priority on XSLT 2.0. Anyone tried to do date differencing in InfoPath? Not fun. Adding XSLT 2.0 to the MSXML stack would IMMEDIATELY make InfoPath tons more powerful.

@Kurt,

>> Okay, I will not say "I told you so." too loudly.

Thanks! *MUCH* appreciated ;-)

>> A decade ago, I was solidly in the Microsoft camp ... hell, two of the books that I wrote were specifically for Microsoft products (Visual Basic). After ten years, I am working solidly in Linux, do most of my programming in Java (the bits that I don't do in XML or PHP or occasionally Ruby), and find that I'd be hard pressed to even tell you the last time I even powered up Windows, except for those rare situations where I needed to test code that I otherwise wrote on Linux.

I'm in a slightly different camp as I have Windows XP powered up all the time... In a VMware Fusion window on my Mac which I switched full time to about 8 months ago with no plans to return back to a standard PC anytime soon. I won't say never, but at this stage of the game I have no compelling reasons to switch back.

>> I didn't wake up one day and say "I think I'm going to hate Microsoft today". My disillusion came in slow, steady disappointments - the freeze on IE6, the abandonment of CSS behaviors, the big push towards ActiveDirectory, the consistently "almost" standards that usually included some proprietary hook, the effort by Microsoft to push RAND licenses into the W3C charter, the lack of follow-through on their XML technologies, the consistent move away from openness even as the rest of the world was embracing it, the repeated endorsements on XSLT2 and the subsequent abandonment of same.

The thing that drives me nutts with all of this is that there are good people @MSFT -- people in whom I know and know well -- who are good, active, and well versed activists of standards. They understand the benefits and understand that building software against a foundation of standards provides more benefits to your customers and more reasons to use your product(s), while at the same time doesn't hold you back from making those products better through proprietary extensions and/or by adding new layers of new technologies based on the notion that you feel there is something you can do better.

In fact, anyone who understands the XSLT 2.0 spec understands that it practically screams "make me proprietary!" given that it provides hooks into the underlying system via extension functions. At this point I would venture to state that 60-70% of my code is written in C# and then accessed via an XSLT 2.0 extension function, using an XML-based sequence file that describes an operation to take place based on some basic structured logic (think XProc with teeth ;-). What makes the above such a wonderful process is that I still gain the benefits of compiled code while making the process of building new processes that much more simple and efficient.

But what makes it even better is that due to the type-aware XPath 2.0 spec, and due to the fact that there are a plethora of schema languages that I can use to validate my XML "code", I'm suddenly now enabled to easily and efficiently enforce all sorts of rules (e.g. "you don't have permission to perform that operation", "this output type is incorrect", etc.) while at the same time enable the ability to use a *HUGE* base of XML tools to edit these files using an easily verifiable declarative syntax. So while I will continue to use whatever *text* editor is made available to me at any given time (VS.NET, jEdit, OxygenXML, vi, Emacs, and -- if necessary -- Notepad ;-)), no one else is required to be bound and gagged to my way of doing things > Just pick your favorite XML editor of *choice* and get on with your work.

>> What's more, every time this happened, the stock answer was "the customers didn't want it, the customers didn't demand it, this is a very much out of the mainstream opinion".

Yeah, I *DESPISE* that canned response.

>> There's a word that describes people who "play with themselves" - in essence, pleasuring themselves and otherwise accomplishing absolutely nothing.

What word would that be, I wonder. ;-) :D

>> There are times that I wonder if Microsoft hasn't succumbed to the intellectual equivalent, creating new technology not because the demand is there for the tech, but because they need to prove to themselves that they can do things better than the rest of the world, that they were somehow superior to everyone else and utilizing others' technology was somehow unclean and made them look weak.

It's an adolescent mindset for sure *when* that mindset is based on building completely new technologies that compete directly with standards-based technologies. It almost like MSFT forgot that a standard is designed to act as a foundation -- not the entire house -- or in other words, a standard is a beginning, not an end.

Of course, there's nothing wrong with creating proprietary technologies as long as they are not at the expense of providing support for standards as well. But support the standards *first* -- then fill in the holes once you know what holes need filling in.

>> LINQ is a prime example of this - it is an interesting idea, and for the perhaps few thousand people on the planet who grok functional languages, its kind of cool. Is LINQ going to end up becoming a part of the C++ developer's repertoire? No, of course not.

What's C++? ;-) :D

>> C#? Only in those parts of the code where its practically forced on the developer.

I don't know... To me, anyway, C# 3.0 is just Haskell and LISP dressed up to look like a C-family language via removing a few parenthesis and throwing in a few semi-colons and curly-braces to convince the C-family developer to "Come on in. The water's nice!" to then hold their head under the water until such time as they realize "That's not water! That's placenta!" vowing never to return back to "plain ol' oxygen" ever again!

(Kurt, sometimes I wonder if I should have taken that referral for the shrink you gave me a while back ;-))

>> VB - um, how many people still actually code in VB.NET anymore?

7.

>> Most of them scrambled to other technologies when they realized that they would have to, yet again, relearn a language that they had only just begun to master, all so that another brilliant idea, the all powerful CLI, could be made to support everything so Microsoft wouldn't need to build true language editors that were completely focused on the language at hand.

And now with VB9 and the future VBx they're coming back the other direction, which is an interesting process to watch, but not interesting enough to begin writing any code in it. XML literals are cool, but I get XML literals in -- you know -- XML-based languages such as XSLT, and with XSLT 2.0 I get all the power I could possibly want so the fact that I can write,

var foo = <bar><baz>Hello, E4X et. Al!</baz></bar>;

... just isn't all that compelling, though no doubt it is to plenty of other folks which is fine: Build your XML literal-like languages. Just don't do it at the expense of pure XML literal languages such as XSLT.

>> There's an intellectual laziness that has pervaded Microsoft - automate everything, so that creating a new product is as simple as changing a few files and pressing the compile button. People do not hate Microsoft because they are successful. Programmers are disgusted with what they see as shoddy code, intellectual laziness, marketing-driven development, and an indifference to extend themselves for any activity that doesn't provide a quantifiable dollar sign.

What's funny to me is that they could have their cake and eat it too and yet they seemingly choose to bypass the road less traveled *AND* the road more traveled by bringing in a Bull Dozer and building their "... own damn roads!"

>> Programmers require honesty in their lives, because so much of what they are dealing with must either work or be predictable in understanding why it fails to. If you don't deliver in this industry, but make a big show of telling the world how great you are, after a while, you will lose the trust of developers. Microsoft is finding increasingly that it has lost that trust, and no ad campaign, no matter how tear jerking, is going to regain it for them.

Absolutey 100% agree ("Wow" had about as much *POW* as a week-old bowl of milk soaked Rice Krispies. Half the actors looked like they were on Crystal Meth, and the other half looked like they wanted to cry for selling their souls to this lame a$$ advertising agency. WTF?)

@Jason,

>> Considering the reliance on XSLT in InfoPath (in a big way) and in SharePoint (in a smaller, oft overlooked way with the DataFormWebPart), it surprises me that there is such a lack of priority on XSLT 2.0. Anyone tried to do date differencing in InfoPath? Not fun. Adding XSLT 2.0 to the MSXML stack would IMMEDIATELY make InfoPath tons more powerful.

Absolutely!!!