Hi Don,

Great to see these issues debated!

You said in response to Alastair (in relation to SPARK):
> XAML does not provide UI Controls. Avalon (the new GUI API)
> provides the UI Controls, and XAML can be used to express
> them XML form, rather then procedural code (via constructos
> and set properties).

But the model is still procedural...create object A, set property B to X,
and so on. (More on this below.)


> XAML does not have a schema, since it is open ended. Any
> .Net object can be expressed using XAML. IMHO, that is one
> of the major drawbacks of SPARK and XUL. They only
> understand a predefined set of controls, and provide the very
> limited ability to create custom controls.

Yes, agreed. Although another solution would be to create a schema on the
fly, once you know what any particular environment can support. We're
working on this with Sidewinder--I've created a version of the XHTML 1.1
modularisation schemas that can use other schemas as 'plug-ins'. Provided
these other schemas 'export' a couple of clearly specified things, then they
can be bound in at run-time to the controlling schema. It means you can get
the best of both worlds--extensibility and validation. It takes only a few
hours to convert schemas like SVG and MathML to use this more modular
approach, and the idea would be that when you install a plug-in, part of the
installation process would be to place the schema in a known location so
that the web application viewer can find it.


> The old SVG-RSS
> part of the SVG 1.2 spec was a step in the right direction to
> give SVG the ability to create custom controls, but I've been
> out of the loop, and don't know what happened with that in
> the SVG 1.2 spec.

Yes, you're right. It's now become sXBL though, which is the little brother
to XBL.


> XAML is the natural evolution of the Microsoft Element and
> Binary behaviors, and anyone who was around this board back
> in the 2000/2001 time frame knows how much I loved using
> element/binary behaviors with SVG. Element/Binary behaviors
> had a lot of flaws, but was a good proof of concept
> (definately not really ready for prime time though).

I agree on the power and the architecture--we use binary behaviours
extensively, and have created a very powerful UI just by bringing together
other people's binary behaviours.

But the binding language--be it XBL or XAML--is not the programming
language. It's a glue. That's why I say it's not 'declarative programming',
at least in any sense that makes the term useful. Conventionally,
'declarative programming' means that we are authoring our 'intent', rather
than any specific way of doing things. In XForms we can say:

<bind nodeset="x" relevant="../y &gt; 10" />

This means "when y > 10, make x relevant". That's a lot of functionality in
simple statement, particularly when the state of x is reflected in any
controls that make use of it.

XAML is very different; it says bring in this (specific) object, initialise
it, set some values, make it available to other objects, and so on. I'm not
saying this isn't useful, and certainly XBL does exactly the same. But
neither of these languages is 'declarative programming' in any real sense.
What seems to have happened is that the term has been greatly watered-down
in recent years, to the point that simply using angle brackets is defined as
being 'declarative'.

Here's another example from XForms, which shows what we mean by capturing
the author's 'intent'. In Sidewinder you can use the following new feature
from XForms 1.1, the specification of a mediatype:

<xf:output
value="'http://sv04msmedia1.dot.ca.gov/N101at580JCT'"
mediatype="video/mpeg"
style="width: 100px; height: 100px;"
/>

Note that this does *not* simply use @mediatype to create a video player
object--the process is more elaborate than that. Instead, this declaration
binds an XBL object to the xf:output in the same way that any other XBL
object is plumbed in--any part of the element can be used to specify the
conditions under which an object should be bound, including the schema type
of the instance data in the XForms model. It just so happens in this case
that the 'selector' for choosing which object to bind in, makes use of
@mediatype, but it could just as easily have said:

<xf:output
value="'http://sv04msmedia1.dot.ca.gov/N101at580JCT'"
class="a-video-please"
/>

As an interesting comparison to this way of binding in objects, look at
Ron's pie-chart example, which binds in a custom control using XAML:

> <?Mapping XmlNamespace="AuroraPieChart_SmartControl_1ns"
> ClrNamespace="SmartControl" Assembly="AuroraPieChart" ?>

Note that in our XForms example the actual object being bound, and *the
binding mechanism itself* are 'deferred'.

You could say that the presence or absence in a language of an explicit
binding mechanism is a pretty good indicator of whether you are looking at a
declarative language or not (it is not explicit in the declarative
language).


So, whilst you are exactly right that we need an easy way to bridge the gap
between our objects and a mark-up language, I disagree that the binding
language itself is the 'author' language. As my friend T. V. Raman often
feels the need to say to me, "your problem Mark is that you always want one
more level of indirection"...but in this case it is surely justified!
Whether the binding language is XAML or XBL, whether the implementation
languages are ECMAScript or C#, I really could care less--the real
revolution of the next generation of programming languages must be one more
level up...and we ain't there yet.


> A lot of the XAML team at MSFT were part of the team that
> created element behaviors.

I see...that has certainly helped me to understand where XAML is heading.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@...
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/