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 > 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: [EMAIL PROTECTED] 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/ ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
