BizTalk mapper is horrible

Question

Hello. I want to know if MS plans any improvements in BizTalk mapping? Changes they made in 2010 are laughable.
My experience with BizTalk mapping starts with 2004 version. But nothing really has changed since that time. And working with maps in BizTalk drives me crazy.
The problems are:
1. No reuse at all.
I don't need to say it's boring to copy paste something from one map into another. But it's more than a boredom - it's against any coding rules. And what if I have 20 maps with copy-pasted block and need to change it?
Wanna sample? Let's take new CRM (2011). The task is to sync 30 custom dictionaries with other systems. All you can use is late binding (thx MS ;(). Simple drag and drop doesn't work cos u need to map xsi:type attributes on xs:Any elements. The only choice
is to duplicate xslt scripting functoids over 30 maps..
2. Bad xslt support.
Xslt editor in scripting functoid is joke. Every time I want to edit a script I do it in another window of VS..
3. Custom functoids..
Why would you create such thing and sandbox it at the same time making it impossible to write anything useful? BaseFunctoid is completely sandboxed. Even with reflection you can't do nothing -it has no references to outworld. If only MS passed there compile-time
information such as node links and etc, you could do some cool things, but no they didn't.
And that's only mapping.. Does MS care of BizTalk?

Answer 1

Thanks for answers. But I can't agree fully agree with your points.
Although XSLT is great by itself, biztalk puts its own restrictions. xls:import and xls:include don't work in biztalk xslt maps thus leaving you with still no reuse. Using xslt in code with custom resolver gives other challenges like storing and
resolving xslt in resources, scaleability and other issues.
I wouldn't be so optimistic about 99% transformations fitting awsome in mapper capabilities. I did no research on that matter, but I feel it's not true. Mapper can do it's job in simple scenarios, being "awesome" in very simple ones (that microsoft love
to show in demos). But first time you insert inline xslt in your map means you're out of mapper capabilities.
I agree that if schemas designed well there are less problems. But it's not always the case. Take for instance a good schema reusing a complex type in many elements. What you wanna do is make xslt template for filling such complex type and invoke it
in your map instead of linking lots of funcdouds and duplicating them all over your map. It's only one example.
The idea of deriving schemas by replacing those xs:any is interesting. If only it would end with few extra schemas. But making dozens of them is not the kind of job I commited for.
The thing that makes me angry is that it's not THAT hard to improve mapper. All needed is to make few little changes in right direction. But instead there are interface tweaks.