Windows Now

A posting in the channel 9 wiki on getting stated with xaml led me to clarify how xaml pages load in IE and why you sometimes need to compile them.

XAML Loading in IE

Currently, if you have a xaml page and it doesn't have any code embedded (or in a code behind file) you can just double click it and it will load in IE.

What happens when you do that.

1) Windows Explorer realizes that .xaml files should be loaded in IE.
2) IE loads and realizes for that mime type PresentationHost.exe should be loaded into IE as the DocObject that knows how to render xaml content.
3) PresentationHost.exe passes the .xaml file to the xaml parser, it creates the tree of objects and it renders.

This is the same technology that allows word documents to be loaded inside of IE.

Sometimes Compilation is Necessary

If you want to start adding code to a xaml file, we currently require a compile step.  There are a few ways to do this:
1) run XamlC.exe (installed with the LHSDK)
>xamlc foo.xaml

2) create a Longhorn project in VS, it will create the msbuild project file for you (.csproj, .vbproj) and a few .xaml files.  You can then compile this in VS or via the command line.
Command Line: 1) cd to the directory of the project. 2) >msbuild

3) you could create a msbuild project file by hand and then use command line as stated in #2

Should We Autocompile When Running in IE

On developer machines, perhaps we should.  I'm hesitant to do it on end user machines.

HTML + script + browser security hole is sometimes a dangerous weapon.  We need to be careful about making .xaml files themselves have autocompile behavior for this reason.

That said, I'm not happy with the barrier to entry that we currently have...we're continuing to think about it...

Update:  Jason Nadal has a post/comments that have some additional info: http://weblogs.asp.net/jnadal/archive/2003/11/17/38124.aspx

A user asked:

Is there a generic way of assigning a property a value, somewhat like you could do through XAML?

For example, if I specify the following code:

<Glyphs Fill=”#000000”>

How would I create a Fill property with value “#000000” through code? Note that I don’t want to create a new Glyphs object, but simply a Fill property.

The way that XAML works for that element is the following:

1)       Creates a Glyphs object.

2)       Determines the type of Fill is Brush.

3)       Looks at the Brush type for the appropriate TypeConverter.

4)       Uses the BrushConverter to convert to a Brush from the “#000000“ string.

BAML details

When you have compiled Xaml, we build a Baml file.  When storing the attribute value in the Baml file, we check to see if the Brush type support IBamlSerialize.  If so, it can store a more compact representation of the value than a string.  At runtime, while loading the Baml, we use IBamlSerialize to convert the persisted version into an object.  Some more XAML/BAML details are in my January post.

So how do you do this in Code:

Generally, you don’t want to use a TypeConverter if you are writing code for this.

<Update2>

Here is the code to use the TypeConverter, if you wanted to do that:

At first I had the totally generic code in here (see my first comment for it...)

Should have shown:

g1.Fill = BrushConverter.ConvertFromString(“Black“);  //code isn't bad, but perf isn't optimal

</Update2>

This would be most efficient:

Glyphs g1 = new Glyphs();

g1.Fill = Brushes.Black;  //Black is a static field on Brushes that is a SolidColorBrush with a Color of black, I believe…

Since you said you didn’t want to create a Glyphs object, you could do this:

<Glyphs ID=”g1”>

And in code (perhaps the Loaded event on the root element), you could then

g1.Fill = Brushes.Black; 

Is there a Generic way of doing this?

No.  Sorry, not yet.

I think this will be a common theme that we hear from “markup-oriented” developers.  We could add a method to support the ability to use a string more easily in code.  However, it would be nicer if CLR languages could provide Tool or Tool & Language support for people who think in strings, but don’t want to pay the cost for it at runtime.

HTML is:

• easier to figure out how to set values in code, since you just use a string.
• more troublesome to figure out if you have the right value...since bad values are often ignored.
• when it does error, it waits until runtime (often on your users machine.)

What is on tap with WinFX?

I hope we can make development with WinFX friendlier to markup-oriented developers - like me.

Is our message:

     “strong typing is good for you“

or:

     “ok, we can make it easy and give you the benefits of strong typing“

Jon Udell compares Flex and Avalon.  He says:

It's interesting to consider these two admirably compact implementations side-by-side. Some points of comparison:

MXML	XAML
Here today	2006? 2007?
Runs anywhere Flash Player 7 runs	Runs only on Longhorn
Server required	Server not required
Uses ActionScript 2.0	Uses .NET languages
XPath support: no	XPath support: yes
CSS support: yes	CSS support: no

This mixed pattern of green (good) and red (bad) pretty much sums up my conclusion. I want all the green stuff in one column.

Let me comment on our red marks from Jon.

1) Yes, we aren't shipping yet...and that is good - we want to get this right!
2) Yes, Avalon is the presentation system for Windows.  XAML is about bringing declarative markup to that Windows API.
3) CSS support:
We originally had a CSS like syntax in Avalon for stylesheets.  Based on feedback (external and internal), we changed to what we had today.

Right after the PDC Chris wrote a good description of what we had and why we moved.

Do XAML users out there miss CSS syntax?

I did at first, because I was used to it.
Please read Chris' description.
If you still find our model lacking, please tell us why...

Update: I should mention that we just had some usability testing done on Resources and Styles.  We are analyzing the feedback and considering changes to the model.

Dino's Un-Programming post, brings up interesting feedback from the development community.

We want to make XAML somethings that developers can choose to use.  That being said, I hope tools like VS and other tools from the rest of the industry focus on persisiting Visual Designers to XAML, not code.  We'd see a world where developers can choose to use only their coding language of choice if they want, but I don't know if any Visual Designers would be built to work in that model.

Did some developers have the same reaction to defining dialogs in .rc files?

Clearly there are a few things with the XAML programming model that seem strange to some developers.  Some of it is becuase it is a bit of a paradigm shift, others are becuase we still have to tweak things to feel right.

One example that a developer customer told me was that he wanted to be able to create a default constructor in the .xaml.cs file.  That leads to a compile error because we need to use that same constructor in the other half of the partial class defined in the .g.cs file.  (See MarkupCompilation: XAML, BAML, .g.cs Details for a little background.)

We support adding code that runs in the constuctor via a <def:Constructor> tag, but I don't think that nails it yet.  Do we need to change how partial classes work to allow a main part of the class...perhaps any constructors created in the other pieces of the partial classes should be called by the default constructor?

Luckily, we can still change things about XAML, many developers are trying out XAML now, and we're listening to what you say.

I just saw Kenny Lim's (digitalnetbizz) posting calling out using a CLR object as a property in XAML.  Let me give people some background on the feature and some changes we are considering in the future.

Markup==ObjectModel

This is one of the Avalon programming model's key tenets.  We wanted our markup model to have a logical mapping between every Tag and Attribute in XAML and the .Net classes that implement that functionality.

In this example:

<Button Background="Red" Click="clickhandler">Ok</Button>

Avalon will do the following:

1)      Create an instance of the System.Windows.Controls.Button class

2)      Using the FromString capabilities of the Brush type converter to convert "Red" into a red brush object

3)      Set the Background property of button instance to the red brush object

4)      Add an event handler to the button's click event that calls the "clickhandler" routine that the user defines in C#/VB/or any language they choose.

5)      Call IAddChild.AddText("Ok") on the Button.  The Button is responsible for implementing this interface if it wants to handle text content.  We'd like to do this more declaratively, but we currently use IAddChild to get optimal runtime performance.  The system can't do it for the Button, because elements are not forced to store text or child elements in any particular place.

Values in Attributes aren't as Powerful as XML can be

I might want to create a gradient instead of a solid color.  While we could invent a syntax that works inside of the attribute syntax, this kind of thing is better described via our Compound Property syntax..

Is a Tag a Child Element or Compound Property Setting?

Since our Button sometimes want to have child elements:

            <Button>

                        <Image … />

            </Button>

We need a way to differentiate if a Tag inside of an element should create an object, or should it be treated as a "I'm about to set a value" tag.

We currently interpret any Tag with a period in it as a Compound Property tag.  The example below shows that we can put arbitrary CLR objects (LinearGradientBrush) inside of a CompoundProperty tag.  As long as the type is compatible with the property being set, it works.

Modifying digitalnetbizz's example into this Button, you'd get:

<Button Click="clickhandler">

  Ok

  <Button.Background>

        <LinearGradientBrush>
          <LinearGradientBrush.GradientStops>
            <GradientStopCollection>
              <GradientStop Color="red" Offset="0"/>
              <GradientStop Color="yellow" Offset="1" />
              <GradientStop Color="blue" Offset="0.5"/>
              <GradientStop Color="white" Offset="0.2"/>
            </GradientStopCollection>
          </LinearGradientBrush.GradientStops>
        </LinearGradientBrush>

      </Button.Background>

    </Button>

Avalon will do the following:

6)      Create an instance of the System.Windows.Controls.Button class

7)      Using the FromString capabilities of the Brush type converter to convert "Red" into a red brush object

8)      Set the Background property of button instance to the red brush object

9)      Add an event handler to the button's click event that calls the "clickhandler" routine that the user defines in C#/VB/or any language they choose.

10)  Call IAddChild.AddText("Ok") on the Button.  The Button is responsible for implementing this interface if it wants to handle text content.  We'd like to do this more declaratively, but we currently use IAddChild to get optimal runtime performance.  The system can't do it for the Button, because elements are not forced to store text or child elements in any particular place.

11)  Create a LinearGradientBrush object

12)  Create a GradientStopCollection object

13)  Create 4 GradientStop objects, add them to the GradientStopCollection

14)  Set the GradientStopCollection as the LinearGradientBrush's GradientStops property

15)  Set the LinearGradientBrush as the Button's Background property

Naming History

We originally called this use of Tags to set Properties "Complex Properties".

Before the PDC, we decided to start calling them "Compound Properties", but not everybody got the message, so you may still see references to "Complex Properties".

Considering Changing the Syntax

We are debating whether we should change the syntax we use for Compound Propertis.  Here are some of the choices that we are discussing:

1)      <Class.PropertyName>: Keep what we have: <Button.Background>

a.       Pros: it works today.  It is consistent with our attached property syntax (DockPanel.Dock).  Fairly writable

b.      Cons: dots in tagnames are weird.  Not as readable as <Attributes>

2)      <Attributes>: Require all Compound Property settings to be grouped inside an <Attributes> tag.

<Button>

            <Image … />

            <Attributes>

                        <Background>

                                    <LinearGradientBrush>

                                                …

                                    </LinearGradientBrush>

                        </Background>

            </Attributes>

</Button>

a.       Pros: Readability. It is more clear which child tags are element and which are compound property settings.

b.      Cons: Syntax is much more verbose.  Writability suffers!  Creating a simple style now takes the following:

<DockPanel … >

            <Attributes>

                        <Resources>

                                    <Style>

                                                <Button Background="Green" />

                                    </Style>

                        </Resources>

            </Attributes>

</DockPanel>

3)      <_PropertyName>: Use a special character at the beginning of a tagname to denote that it is a property:

<Button>

            <Image … />

            <_Background>

                        <LinearGradientBrush>

                                    …

                        </LinearGradientBrush>

                        </_Background>

            </Button>

1. Pros: Just as clear as <Class.PropertyName>.
2. Cons: Not consistent with attached property syntax

4)      First Check for Property then, object.

Often elements will have properties named identically to a type.  We could choose to always assume that something is a property first, if it isn't found, then treat it as an object.

            <Button>

                        <Image … />

                        <Background>

                        <LinearGradientBrush>

                                    …

                        </LinearGradientBrush>

                        </Background>

            </Button>

1. Pros: understandable.  Writable.
2. Cons: you have to walk the parent chain to understand if a tag is an object or not.  Compile time perf is slower, but runtime wouldn't need to be hurt since you can encode into baml whether it is a property or an object.

Final Naming

 Once we finalize our choice here, we'll figure out what to call it...Compound Property may not be the best name.

WinFX allows you use XAML to declaratively define your UI, interactive media, or document.  XAML is a great way to define these things.  However, XAML isn't what we'd prefer to use at runtime.

With HTML, parsing of the .html file is done at runtime.  This leads to the following problems:

1) the runtime spends a lot of energy to convert markup into objects

2) often errors are caught by the user, not the developer/author

Avalon allows runtime parsing of XAML, however we think you'll see the benefits of compiling most of your markup.

XAML Naming History

XAML originally meant "eXtensible Avalon Markup Language".  Before one of our first design previews we didn't think the "Avalon" code name would be public at all, so it morphed into "eXtensible Application Markup Language".  (To my surprise, we still did use the “Avalon” name.)  We eventually learned that we had a technology that wouldn't only work with Avalon, but would be more generally useful as well, confirming that name change was a good one.  What we will end up calling it, I don't know.  Whatever we call it, I want it to be a nice pronouncable acronym.  We pronounce XAML like "zammel".  (See Kevin Dente's funny post.)

Markup Compilation Details

During the build of a Longhorn application, before we let the appropriate language compiler (C#, VB, C++, etc...) compile the appropriate code, we compile the markup.

Given a sample file (foo.xaml):

<DockPanel xmlns="http://schemas.microsoft.com/xaml/2003"

    xmlns:def="Definition" def:Class="MyNS.MyClass">

    <Button ID="b1" Click="foo">click here</Button>

    <TextBox ID="tb1" />

</DockPanel>

When foo.xaml is compiled, the following happens:

1) Our markup compiler parses foo.xaml (using our parser - which uses System.Xml.XmlTextReader)

2) Our markup compiler calls a BAMLWriter to create foo.baml in obj\release\.  (more details on what is in the BAML file later...)

3) Our markup compiler creates a CodeDom representation of a new partial class (more details on what that class does later...) and we ask the code to be saved into foo.g.cs in obj\release\. (if your language of choice is C#.)

Foo.baml - What is it?

The B in BAML stands for Binary, because BAML is not meant for human reading or writing.  You may ask why call something "Binary Application Markup Language" - aren't Binary and Markup contradictory.  BAML is a binary representation of the object hierarchy and properties defined in the source XAML file.  It has been pre-tokenize, so at runtime, loading of a BAML file should be much faster than loading a XAML file.

Foo.g.cs - What is it?

The .g stands for "Generated".  Before we get into more detail about this file, you need to understand that every XAML file is actually defining a new class.  In the foo.xaml example from above, the XAML file is declaring that it is building a new class like this:

namespace MyNS

{

    class MyClass : DockPanel

    {

    }

}

In fact, that is the beginning of the code put into foo.g.cs.  We also

add the "partial" keyword:

    partial class MyClass : DockPanel

The partial keyword in C# (and a related Extends keyword in VB) means that this class is also defined elsewhere, generally in another code file.  We use this so that foo.xaml.cs (the code-beside file) can define the other part of the same class.

MyClass in .g.cs defines:

A field for every element with an ID attribute.

    public Button b1;

    public TextBox tb1;

A constructor that creates the tree of objects by calling LoadBaml("foo.baml").

A routine which gets called back whenever an element is created with an ID.  The field b1 will get set to the value of the Button that was created for it at that time.  Event hookup also happens in this routine.

CAML vs BAML

At one point we thought we would have 2 different settings for markup compilation: Optimization="Speed" and Optimization="Download".  In a future milestone, we'll be removing Optimization="Speed" or what some people internally call CAML - for for Compiled.  Optimized for download maps to generating .baml & .g.cs as described above.  Optimized for speed only generates .g.cs file and does all tree creation in code in that file.

BAML Only!

We think we are going to cut CAML because:

1) BAML is just as fast as CAML today and can probably be made faster.

2) Having one code path is better than two.  In the PDC bits (that everybody is using now) we had spotty quality in the 2 different code paths.  Some features only worked with one or the other.  We'll be able to optimize, security threat analyze, and test BAML much better than we could have done with CAML and BAML.

3) Localization in an optimal way is easier with BAML.  You don't want localizable strings embedded in your .exe, but instead, you want those to be stored in a sattelite assembly.  (Perhaps this will be a future topic.)

4) Download size is smaller with an embedded BAML vs compiled IL into the Exe.

5) Incremental rendering is possible with BAML.  HTML allows you to see parts of a document before the entire document is downloaded.  BAML has the same capability.  CAML doesn't - you need to download the entire definition of a class and the assembly it is in before you can instantiate the first element of a page.

6) I'll modify this list if I remember more reasons...

Where does the BAML go?

By default, we put all items of Type="Resources" into .net resources and embed them in an assembly.  You can play with project file settings in msbuild to individually control each file if you like.  When somebody drills into localization, we'll cover the details of that.

In Summary:

Our compilation model allows people to get the benefit of XML during authoring/development time, without having to pay for it at runtime.

Hey, I'm Posting Again

Ok, well I'm back after my first blog "pause".  I went to Japan to do some Avalon talks in mid-December (my 49 hours in Tokyo- did 3 talks, slept a total of 7 hours in 2 nights there, i'm glad i did it, but next time I want to spend more time there...).  When I returned to the airport in Seattle my family met me there and we flew to the East Coast for a friend's wedding.  I worked about half-time during the holidays.  Since the new year, I've been cranking on:

• XAML2004 design
• avalon api review (almost done with a pmvt walk through of MSAvalon.Windows in PF.dll, PC.dll and WB.dll)
• improving xaml.xsd
• VS integration issues
• interviewing several PM candidates for our team
• a spec for allowing you to invent your own xmlns uri for use in xaml
• and a few more things.

  It has been a great month - a great start to the year.

Yesterday Chris, Don, Martin (a coworker of Don's) and I met to discuss XAML.  We're going to be thinking hard about possible improvements to it.

Now when I say XAML in this context - i mean the markup format, not the Avalon elements or animations, etc....  We're asking questions like:

1) should compact syntax (*Bind(...)) be patched to fix some known problems or swapped into some other similar syntax.
2) should compound property tags and children of an element continue to be mixed together
3) should there be a mandatory root element? (<Xaml> for example)
4) is it ok if we require that every XAML file has 2 xmlns namespaces?
5) how do we fix the mapping pi for custom components now
and a few others...

Anyway, if you have other issues or requests on this level, please leave a comment.

If you have comments about those 5 issues, please leave a comment.

I'll probably do more airing of the issues in future posts.

I'm not sure how Avalon is going to go on the ID vs Id issue.

Thanks to Brad and Steven for raising the issue with the community.

I've read every reason, tallied the results, took out the repeat votes (but left their first vote in), took out Microsoft employees, etc...  We're talking pivot table here!

By my tally, the vote is currently 20 to 19 for Id.  Clearly a contentious issue and not a slam dunk either way.

I'm travelling for a little while, but when I return I will do the following homework:
1) talk with BradA/Michael Murray about several guideline issues and questions i have that are related to this.
2) talk to some asp.net folks to understand how much ASP.NET developers really deal with ID (in case sensitive scenarios)
3) discuss with a few PMVTers -- a virtual team “Programming Model Virtual Team“, mostly of Avalon dev leads, architects, and a couple PMs.  This team reviews all Avalon apis.

I could cave and just say - ok Guidelines are it.  Id is the one.

IS this a democracy?

But I'd rather understand the strength of all the reasons why people prefer one over the other:

• Some people say PascalCasing should be everywhere...Well it isn't - and we're not changing that guideline (are we Brad)...so should that vote count 100%?
• Some people say it should be Id because Id is an abbreviation for Identification.  It doesn't seem like the dictionary agrees with them.
• Some people say it should match ASP.NET.  I have been in that camp because I think consistency between ASP.NET and Avalon is a good thing.  But then Michael Murray pointed out that in the typical tool experience, most asp.net tags are lower case.  That is why I listed #2 as homework above.

IS this a democracy?

NO.  A strict count of hands isn't the thing to do.

Decisions need to be well thought through.  The owner needs to weigh the arguments and make a call.  This is what makes Program Management at Microsoft fun!

Thanks for all the opinions and thought on this important issue.

Daniel raises the issue of attached properties and shows how WXS could be used for validation.  That looks like it is one way to solve the problem of attached properties.  But could it work in all XML Editors?

We currently provide:
a schema - xaml.xsd (the Longhorn SDK installs it)
a set of rules/constraints that we can't easily describe in schema (not adequately documented yet)
a set of assemblies - using reflection tools could understand what elements exist, their properties, events, etc...

Xml Editing using Schema - Good

I assume there are going to be xml editors that just know how to validate and help based on a schema.  I want that experience to be as good as possible.

Xml Editing using Schema and/or other info - Great

But if people want to make emacs, XmlSpy, VS' xml editor or other code & XML editors all work great as XAML editors - it sounds like they are going to need to work on more than just schema.

Weiqi says that emacs can use Relax NG.

So do we need rules for Relax NG, WXS, and others?

For those of you who do want to be able to hand author or edit XAML, what tools do you want to use?  How can we make that tool better for XAML?  What can we do to help?

In the comments of Steven's posting about the SideBar usability study, Frank says:

“It is good that usability is being tested for Avalon. Looking at the docs online, I have the feeling it is one of the least-usable APIs I have ever seen. The xml looks easy but the API is very complex and over-engineered.“

Frank is correct, we are too complex now in many areas.  We think we have good reasons for the things we have done, but things are still early - we do have a ton of room for simplification and polish.

When Steven asks for more details, he follows up with another comment questioning 4 things: typing of our properties, Decorators, Changeable, and Length.

Changeable & Length

Greg Schechter, a new Avalon blogger, responds to the changeable and length comments.

Weak Typing & Decorators

We'll follow up with discussions on these later.

Frank ends his comments with:

“I think I could write a whole book here. Looking at how many abstractions the user has to juggle in their head just to understand simple buttons and shapes... it is incredible. Just count the number of classes involved, the number of complicated concepts. Well, maybe I will post more later, write something up in more detail. I don't mean to disrespect the hard work in that API, but this is supposed to last a long, long time. I think the "less expert" users will just cry when they try to use it, outside of the xml. Plus, exposing all this low-level detail will make it harder to change later.“

We constantly need to question why every class is needed, why new conventions are necessary, etc...  We still have a lot of simplification work to do! 

We have tons of internal debates about all of these things.  I'm excited that we can now have you involved.  Please ask us the questions.  Make your comments.  Tell us what needs work. 

Please write more feedback!  Point to concrete samples of what you are trying to do - show us your code/markup. 

What about the Button is hard to understand?  How to build one or how to use one?  What were you trying to do with it.

Yes, Frank, we have a lot of work to do - we are trying to enable many powerful new things.  Yet we need to keep it approachable.

Thanks for the help.

We just posted a patch to make intellisense in xaml better.

The problem was that the XML editor in VS has some things hard coded.  It thought that if a file didn't have .xml as an extension, it must not be XML.  No matter how much we told it that our <style> tag could have content inside of it, it wouldn't listen - it was still trying to format the content as CSS. So this patch fixes that.

Please let me know how people are enjoying (or not) the VS development experience for Longhorn Applications.

What are the top 5 things you'd change? What do you like? What else do you want?

(yes, we know you want a visual designer.)

What I want to know is when will the first 3rd party tool be available (to the developer community) with some knowledge of XAML, MsBuild, etc...

Don was showing how XAML was not just about building trees of Avalon Elements with his K&R flashback.  That's true: XAML can be used to build (a) element trees, (b) element trees with logic, or (c) class definition.

I don't want people to become too focused on the programming model for building console applications.  That is not our focus!  Markup won't add much value there.  Don showed a good example of the flexibility for defining new classes with XAML, but that will much less common than the other uses of XAML.

Given that, let's start with a simple Hello World and show where we'd like you to be able to take it.

HelloWorld.xaml

    Hello World!

What are the next few interesting things you are going to do with Hello World and how easy can we make that?

FadeInWorld.xaml [1]

            Begin="0" Duration="3"

            Fill="Hold" />

    Hello World!

You can animate most properties in Avalon.  Here we use a CompoundProperty tag - .  Inside we put a DoubleAnimation.  Opacity is of type Double.  Most properties in Avalon aren't strings, but instead real types like Double, enums, Uri, etc...

This animation will change the Opacity from 0 (hidden) to 1 (fully visible) in 3 seconds.  At the end, it will hold the final value.

CircleWorld.xaml [2]

    Hello World

Avalon allows you to mix UI, Documents & Media.  Here we are mixing in Vector graphics (Ellipse).

RichTextWorld.xaml

    FontSize="36pt">

    Hello World!

Avalon allows you to have rich text.

InteractiveWorld.xaml [3]

    xmlns:def="Definition">

    Click for Greeting

        void SayIt(Object sender, ClickEventArgs e)

        {

            b1.Content = "Hello World!";

        }

    ]]>

Avalon allows you to put interaction logic in the .xaml file or in a code behind file (.xaml.cs if you choose to use C#).  Because XAML is well-formed XML, you will sometimes need a CDATA section to make sure that characters in the code won't inadvertantly be treated like a close tag.

There are other concepts to show in XAML, but I’ll leave it at that for now…

FootNotes

==========================================================

[1] I've simplified our current animation syntax for this sample.  PDC bits require a DoubleAnimationCollection tag that contains the DoubleAnimation.

[2] I didn’t run this sample, as I don’t have a Longhorn machine at home.  I’ll update this sample if it doesn’t work…

[3] PDC bits require this to be compiled as part of an application/document.

Why does XAML need to be (well-formed) XML in the first place? XQuery is not XML and yet it’s way better than XSLT, since its syntax is more expressive, readable, and intuitive. XAML does need to be interoperable and interchangeable between platform-independent web services. It will most probably be consumed only on Windows and (most probably) MS will come up with a XAML parser. Why does XAML need to be XML then. Why not have an expressive, readable, and intuitive syntax for doing the things that XAML was designed to do – seamlessly mixing markup with code.

I’ll respond:

XAML is XML because

We believe that making XAML be XML is the right thing to do because:

1.      Without extra work from the vendors involved, we’d like all XML editors be able to work with XAML.

2.      We’d like transformations (XSLT, other) be able to move content to/from XAML.

3.      We didn’t want to write our own file parsing code, the parser code we do have is built on top of System.XML.XmlTextReader.  We are able to focus on our value add.

4.      I’m sure that there are several more reasons…

But XML isn’t Perfect

That all said, there are a number of things that we’d like to do in XAML, but XML isn’t a perfect fit.

1.      We want to enable setting the Background property on a Button (for example) in one of two ways:

a.       Using a normal attribute -<BUTTON Background="”Red”">Click Here</BUTTON>

b.      Using our compound property syntax –

<BUTTON>
    <BUTTON.BACKGROUND>
        <LINEARGRADIENTBRUSH …>
            <GRADIENTSTOP Color="”White”" Offset="”0”" />
            <GRADIENTSTOP Color="”LightBlue”" Offset="”1”" />
        </LINEARGRADIENTBRUSH …>
    </BUTTON.BACKGROUND>
    Click Here
</BUTTON>

c.       Ideally if somebody tried to use both syntaxes at the same time, we could error.  XML Schema – as far as I am aware – isn’t well equipped to describe that behavior.

2.      It is a bit strange, for designers or developers moving from HTML to XML.  HTML is forgiving.  XML isn’t.  Should we shy away from XML so that people don't have to quotes around things?  I think not.

3.      It is difficult to keep XAML as a human readable/writable markup, as that isn’t one of XML’s goals.  I think it needs to be one of XAML’s goals.  It is a continual balancing act.

     
Dare says I'm wrong on this last point.  XML's goals do say that:
6. XML documents should be human-legible and reasonably clear.
So, yes, they are meant to be readable.

The issue I wrestle with is:
10. Terseness in XML markup is of minimal importance.
That impacts the writability. One example is our compact syntax versus compoundproperty syntax. I'll do a post on that question at some point.

What do you think?

I’m interested in more detailed feedback about why XML isn’t an appropriate direction for us.  My brief look at XQuery after searching in the IE address bar for “XQuery Primer” brought me to this “What is XQuery?” page – it compared XQuery to ASP syntax – sounds like you are perhaps interested in mixing directives in the middle of the markup to generate content as appropriate.

We have purposely chosen not to support this concept (Response.Write in ASP, Document.Write in DHTML, etc…).  We do provide a number of ways to make the content of a element tree dynamic – the primary method being DataBinding.

Everyone – let us know the scenarios that being XML enables or prevents.  We’d love to hear your opinion here.

My demos have been posted for a while.  My slides must have gotten lost in the mail...

Now it all seems to be posted:
http://msdn.microsoft.com/events/pdc/agendaandsessions/sessions/default.aspx

My session was CLI300.  Let me know if you have any questions/comments.  I'll post a screenshot of my demo at some point, for those of you without Longhorn.

In the demo, the most interesing xaml files to take a look at:

Pane1.xaml - main page of the demo (see how to style RadioButtons radically, how to get started with DataBinding a listbox, see the basics of styles, etc...)

The following are in the Sessions subdirectory:

Cli300Description.xaml - see a flow document

Cli300Slides.xaml - see a fixed format document - i created this by printing my slide deck in powerpoint to the windows client print driver (i did have to trim the document down to just a few slides so my demo didn't go badly :-)  -- that'll get better.

CLI300DemoCanvas.xaml - a small sample of xaml using the Shapes

CLI300DemoDockPanel.xaml - a demo of the DockPanel in action

CLI300DemoFlowPanel.xaml - a demo of the FlowPanel in action

CLI300DemoGridPanel.xaml - a demo of the GridPanel in action

Sessions.xml - the xml file that Pane1.xaml databound to.

I'll (or others) will eventually post more about all this stuff...

I'm going to try to start posting my comments answers that others may find good info in on my blog, not just as comments on people's site.

Sam Gentile posted:

I just realized that the Longhorn SDK adds templates to VS.NET Whidbey so you can use it to create Longhorn applications. Using the C# Longhorn Application template/wizard generates a solution with the XAML file specifying a C# code-behind class (implemented as a partial class). I'm going to have to play with this some more although I don't prefer this route. Like 3 years ago with .NET, I believe the SDK, an editor and the command line are by far the best way to learn the technology.

I commented:

The current VS.Net Whidbey solution to build Longhorn Apps won't be hiding much from you. (PDC attendees received this...MSDN subscribers go here )

It will:
1) give you an easier start, as it will create several files for you, which you can them modify.
2) give you xml intellisense in your xaml.
3) give you c#, vb, or c++ intellisense in your code behind.
4) maintain the .csproj file for you -- although you can modify by hand as well.

If you plan on only using notepad and msbuild, that is workable, but tougher.
If you do, check out xamlc.exe - give a xaml page, it will hide the msbuild process (won't require a .proj file or MyApp.xaml).

That all being said, I'm excited that this is public now. We are looking forward to working with the community to make sure that WinFx, the new Windows API, and XAML, our Xml markup language, provide what developers need.