Shine on Silverlight and Windows with XAML

Ryanair unusable for me

I think Ryanair used Silverlight on their website for the destinations map, they are already as expensive as other airlines, but with more restrictions, it was enough to cause me to walk away from the purchase.

Ah well, their choice, but I don't even have silverlight on my Windows PCs so it looks kind of dumb to me.

Not everyone wants to write web-apps!

I'm inclined to agree that Silverlight is derivative/me-too/not really the web/etc... However WPF for desktop applications is really quite compelling, assuming you're in a position to learn it and take advantage of it.

Ah the good old days..

So this is what javascript would have been doing 10 years ago if Adobe and Microsoft hadnt got involved in 'developing the standard' ??

Only using a lot less bandwidth....

Ambiguity in XAML

@nobby

You're right, you could set a property twice, once as an attribute and once as a property element.

If you do, you get an error:

(in your example) "The property Fill is set more than once"

This is messy. On the other hand, if the spec did not allow the shortcut attribute properties, XAML would be considerably more verbose.

Tim

Breaking XML deliberately

> Microsoft calls it "a system for representing structured information," which is about as generic as you can get,

That's what XML is for.

>reveals [...] that although XML is "a common format for XAML... any physical representation may be used." [1]

Indeed, that's true of XML too. But this makes me suspicious...

> It turns out that XAML has an uneasy relationship with XML. [...] but validating them as XAML is not easy. Microsoft explained back in 2006 why it could not develop a satisfactory XML schema for WPF. [2]

My suspicion grows. The fact that their example with Rectangle/Rectangle.Fill/SolidColorBrush/etc. can be expressed in multiple different ways, and that makes things tough to validate, just enhances my suspicion. [3]

And then we've got this example

> <Rectangle Height="20" Width="50" Fill="{StaticResource MyGradientBrush}" />

where the attribute Fill ain't what XML is for, so it makes validation harder [4]

[1] + [2] + [3] + [4] = the conclusion that MS, have carefully broken so many browsing standards, are trying to break XML. They've probably got their own 'physical representation' somewhere ready to produce when XML starts cracking.

I don't like XML so much, but this is not pretty.

XUL...

...will rule.

From the article this XAML sounds like the usual unworkable MS bloatware - and it sounds like they are getting worse and worse.

I mean - c'mon - how can *anyone* break XML.

<quote>

It turns out that XAML has an uneasy relationship with XML. All the XAML documents you are likely to see are valid XML, but validating them as XAML is not easy. Microsoft explained back in 2006 why it could not develop a satisfactory XML schema for WPF.

</quote>

This level of incompetence would be almost heroic if it wasn't so sad.

I predict that the FireFox XUL stuff will be far superior. To look at it just add the FireFTP add-on to FireFox and see how great it looks.

And you can just load XUL files straight into the browser to get widgets and stuff. And it all works from Javascript.

Check out:

http://en.wikipedia.org/wiki/XUL

At least we know that it will work properly.

@BlueGreen

I generally share your suspicion towards MS trying to break other things here. Whether it is XML they are after i don't know, but i tend to think not.

Why i reply is, your point [4] about attribute content is IMHO not valid from that example. Please have a look at XPath and SVG and you will see attributes are more than simple one-word identifiers even in W3C bred languages.

eg XPath: id("foo")/child::para[position()=5] (can go into an attribute in its entirety, provided proper quotes escaping)

more related, svg: <rect fill="url(#MyGradient)" />

At first the SVG way to locate a "Static Resource" looks more proper than that XAML example, but fact remains it uses a function call which returns a complex object. Like this, it's locating a static object, but you could as well have your own functions called in attributes doing mad things.

The other point about allowing "properties" declared by XML element subtree and/or XML attribute - Well, not nice, but it weren't too bad if there was one clear, simple and +/-set-in-stone spec defining which takes priority. Having it cause an error is just silly.

@F Seiler

re XPath you're quite right. I'd completely forgotten about that usage. But, why bother? XPath/XSLT was designed to be readable and writable by people, so it had to be reasonably legible (I understand that earlier versions of these (or just xpath??) tried to express it all in XML but abandoned that approach for readability). How much of XAML as XML are we going to be directly interacting with - probably little at first, none when the tools mature. I may be wrong in this, if so please correct me, but assuming I'm not then where is XML used? Storing it? Space doesn't matter, and compress it if it does. Processing it? Use an appropriate format, whatever you wish. Writing it if we actually need to? Again, use an appropriate format - like a proper language and *not* XML (how hard is it to write some lex/yacc [*] anyway to do the necessary translation. Trivial).

And claiming that twisting XML was done for readability - I don't believe it. I can't find the ref but MS admitted that it tried to make SOAP XML syntax so unwieldy that you had to use their tools instead.

And as for the dot syntax <Rectangle.Fill>, that's deliberate abuse of XML. It has to be.

Just as a thought, and please note that I became familiar with XML before namespaces were introduced properly and I've not had cause to use them, could this not have been done with namespaces, eg.

<root xmlns:XAML_FILL="..."> ... <XAML_FILL:Rectangle> ...

Could this be made to work? If so it would preserve XML behaviour and give MS what they want.

And by the way, this is going to be a problem in general:

<Button Content="Click me" Grid.Row="1" Grid.Column="0" />

That's because the Content bit is an attribute and is thus subject to attribute normalisation, so all leading and trailing whitespaces are stripped, and any whitespaces within are collapsed to a single whitespace. Could this be part of the plan? Well, MSXML has this bug whereby whitespace normalisation is *not* done. Thus breaking the standard. Maybe it's been fixed in the last 2 years, I doubt it.

I still am suspicious.

[*] probably lex.net and yacc# these days.