RCC moves out of SVG 1.2 2

In the exisiting working draft for SVG 1.2 the W3C adds something called RCC. RCC is a way to define custom elements in SVG. It is very similar to XBL and tries to solve the same issues as both XBL and Microsoft’s behaviors has tried to solve before this.

I’ve previously commented about the duplicate effort of RCC and that I thought RCC should be taken out of SVG and coordinated with XBL and related efforts. In the latest update of the SVG 1.2 WD there is a note saying just this.

The RCC feature set is expected to be moved to a separate specification from the next publication of this document. Discussions are already under way to merge the functionality with the XML Binding Language (XBL) that has been implemented in some HTML browsers. This will not delay the SVG 1.2 specification, and will allow the features to be used in multiple document formats (including both SVG and XHTML). A new XBL specification is being developed by the SVG Working Group with liaison with other W3C Working Groups. It is highly likely that the first official W3C version of XBL will address the requirements of SVG 1.2, where future versions add some features needed by other document languages.

On the same topic, Alex Fritze of Mozilla SVG fame is adding another variant trying to solve the same thing, called XTF (eXtensible Tag Framework). XTF is much more similar to Spice (submitted to the W3C by HP even before Microsoft proposed the HTML Components. XTF uses JS, C++ or any other XPCOM language to implement a specific interface describing how to render the element. This is much more similar to binary behaviors and IE and the way custom components are implemented in Avalon. The good tihng with this is that it is more powerful but the downside is that it is harder to learn.

This leaves us with 3 implemented variants (and a half for XTF) and one more proposal submitted to the W3C (Action Sheets totall ignored).

Name W3C Status Implementaions
Spice W3C Submission None
HTML Components W3C Submission IE5+ Win32
XBL Draft Proposal (Adobe, Opera & Apple) Mozilla
RCC Part of SVG 1.2 WD Adobe SVG Viewer v6
XTF None Mozilla branch

At the moment it seems like XBL will be the final solution. I’m not sure I’m totally satisfied with this. I have several issues with XBL that you will most likely notice by looking at the XBL Marquee at WebFX.

I hope I can get back to this topic because this topic is something that lies close to my heart. I would like to disguss what kind of features I see as essential for something like this (and where existing solutions fall short).

  • Jim

    Hi Erik,
    I tested out your Bindows and it is truly interesting and very attractive. However, one thing I couldn’t exactly see is why someone should use it? That is, it is definitely a useful tool, but you see there are many other solutions, like java applets, .net web forms, xul etc…

    This framework seems to be inappropriate for the web sites, because web sites has to work with various number of browsers. It seems to be it is way more expensive to use bindows for web sites (not the bindows license, but the amount of time you put into the development, cause you have to develop for two sets of browsers at least). If the web site owner targets the Internet Explorer, then I do believe it is a good solution, however I can not think of many web sites that require this much of complexity on the client side. That is if they develop something that works, it is still good for them. And also it seems that you have a more steep learning curve with Bindows and somewhat restricted by what you can do with it, cause there are not too much free articles for it. For example, if I choose to use normal HTML I can check out what other people do and quickly solve my problem, but if I choose Bindows I have to learn how to use it and restricted by what I have there. Also with normal HTML/DHTML I can extend or modify it anyway I want.

    If the Bindows target the internal networks, then I am wondering why not use java, .net web forms and so on. They seem to be more attractive for intranets.

    Finally, I wonder how can someone or a third party supply its own widgets for your framework. Is there a plan for it? Say can I produce one and sell as a third party?

    I think it is an excellent piece of work. In fact, nobody would believe that it is all done with dhtml. However, I couldn’t figure out where is the true value of this solution, cause it seems to be a world in its own, rather than part of DHTML itself. That is it uses DHTML, but nobody who is expert on DHTML claim to be an expert in Bindows, cause it has its own set of rules and logic.

    If you can bring some light to these concerns/questions I would be really happy. Cause I am puzzled on exactly how this excellent framework bring value. It is an excellent piece of work, there is no doubt about it, but why should someone use it. The only logical answer I was able to come up with is when someone wants to target IE 5.5 or later and they want to be as responsive as possible on the client side.

    Great inspiring work btw.

    I copied my post here, in case you didn’t notice it before.

  • http://jibbering.com/ Jim Ley

    Hi Erik,

    I’m interested in what you think the problems with XBL are? from reading your marquee implementation I seem to see your biggest complaint being scripting scope of your components?

    I believe the XBL spec will say something like:

    This implies that scripts from different bindings in the same binding source bound to different elements in the same top-level document share the same scripting scope.

    Which means we can scope js to within the document scope, indeed it’s communication across script scopes that become difficult.

    (responses via email would be appreciated)