Scaring the Natives with XML

What a big difference Don

The percentage of people who actually creates and edit XUL using a domain-specific visual editor is statistically 0%.

OTOH, the percentage of people who creates and edit XUL using a text editor is statistically 100%

Can you comment on why such a difference between similar technologies?

What's the benefit of having both WWF and WPF use the same XAML file format? What happened to XOML?

George,

I'm the wrong guy to ask about the XUL user base.

On the XAML side, my prediction is that most people will just design workflows and visuals using the visual designer tools and be blissfully ignorant of the underlying transfer syntax.

The Sparkle and Acrylic folks are certainly counting on this, as are the folks who work on Cider (VS's forthcoming WPF designer) and WWF (which ships with its own designer already).

The fact that we have a documented and easily manipulated format that enables this domain-specific designer ecosystem.

DB

Dan,

XAML is (and always has been) just an idiomatic use of XML that could be used in any domain.

ChrisAn and I started making this point back in 2003 (see http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20031218xamldb/manifest.xml).

WWF snapped to an early draft of XAML and coined the term XOML for that version of XAML.

By WWF beta 2, we plan to snap to the "final" version of XAML that will be used by both WPF and WWF (and anyone else who jumps on the XAML bandwagon).

The upside of using XAML's idioms are simple.

There's power in sameness.

Having a single set of idioms allows us to build less parser/deserializer machinery, which improves the quality of the platform not to mention reduces the surface area of the programming surface.

Having a single set of idioms allows our users to learn one set of "meta-constructs" that apply in a variety of domains that they may encounter as a modern Windows programmer.

If you're a text editor kind of guy, this means that if you know how to author XAML for WPF, you're most of the way there to knowing how to author XAML for WWF (or whatever W*F comes next).

More importantly, if you're designing an new framework for use by your team or your customers, you can leverage the same infrastructure that WPF and WWF use.

DB

Don (now I'm answering my own comments in comments),

You mentioned that "if you know how to author XAML for WPF, you're most of the way there to knowing how to author XAML for WWF (or whatever W*F comes next). "

I believe what you meant to say was this:

"once you know how to read/write XAML for WPF, if/when you decide to start read/write XAML for WWF (or whatever W*F comes next), you don't have to reinvent the XML-specific machinery but rather can focus on the new concepts of that domain."

Did I get it right?

DB

Don,

Except for omitting the grammar mistakes, I couldn't have said it better.

Thanks for cleaning up my mess.

Cheers,
DB

So am I the only one awaiting Rocky's response to this post? :-)

[Solid Quality ASP.NET] Bits and pieces of your
viewstate [Via: DinoE ]
ASP.NET 2.0, SQL Server 2005,...

Why is Microsoft trying to encode the entire world into XML? I dont get this. It like there is a team of people in redmond just sitting around going "hmmm, what else can we turn into an XML structure? Wait, I know...the color palate, or the unicode table...or bitmaps, YES BITMAPS. That'll be slow, huge, and anaying...YES!". Another example of microsoft trying to find and force upon the entire world the next "Silver Bullet".

John - did you read Don's post? That's kind of what he was trying to explain.

It's worth noting that even though XAML is an XML based language, this doesn't mean it can't be compiled away to something lean and fast. XML happens to be a great base for declarative languages like XAML, but it's still just a language all the same.

It seems to me that XAML is just another language that can be understood by the CLR. What makes it nice is that now any DSL (or model) can be excesselteed into XAML and be run by the CLR to give a user an application built on W*F. Since there really is only one application anyway this takes configuration to a whole new level.

From newly converted ARC MVP Sam Gentile, I found this interesting post from Drew Marsh about how XAML...

A really cool side effect of what is planned for VB9, is you will never have to code in XSLT ever again...

..."More importantly, if you're designing an new framework for use by your team or your customers, you can leverage the same infrastructure that WPF and WWF use."

It been difficult to determine exactly how the WPF and WF teams leveraged this infrastructure since it appears to be implemented very differently for each technology. The XAML/XOML syntax may be the same but the designer support and code generation appears to be very different. The design time support in the RTM Workflow designer appears to be implemented in a fairly standard way while WPF is completely different (no Designer Attributes, etc). Also classes such as MarkupExtension in the System.Windows.Markup namespace also show up in System.Workflow.ComponentModel and these classes share no common heritage.

Guidance is needed on how to leverage xaml/xoml for custom frameworks. Does anyone have any?