Discussions

News: XUL Outgrows Mozilla: Open XUL Alliance Site Goes Live

  1. The Open XUL Alliance site went live today.

    The goal is to promote all things XUL (XML UI Language) and also to provide free test suites to help ensure
    interoperability between different XUL motors/browsers/runtimes and free, open-source show-case examples (aka blue prints) to demo the power of XML for creating UIs.

    For now the Open XUL Alliance Site sports:

    * XUL News Wire - Breaking News About XUL; also known as the xul-announce Mailing List

    * The Richmond Post - Chronicle of the XUL Revolution; XUL News Weblog

    * xul-talk Mailing List - Beyond Mozilla; Talk about XUL issues touching more than one XUL motor/browser/runtime

    * XUL Lecture Series - Rich Clients, Rich Browser, Rich Portals and much more

    * XUL Link-opida - Articles, FAQs, Cheat Sheets and
    much more

    Use the XUL, XForms and SVG trio to build rich clients for web services today.

    Visit the Open XUL Alliance at:
    http://xul.sourceforge.net

    What is the future for XUL? Is it growing? Are many of you guys using it?

    Threaded Messages (45)

  2. I looked into a couple of XUL sites and it seemed interesting. I couldn't find any normative or formal descriptions of XUL though (admittedly I didn't look very hard). Mostly tutorials and references. Is it a standard? Which body defined it? Where can I find a spec?

    Gal
  3. Here we go again. To quote from my MozillaZine post:

    One of the first questions I always get is "Is XUL a standard?". My answer is that XUL repeats the HTML story where innovation happened before standardization. What use is the best spec such as XHTML 2.0 if there are no browsers for it?

    To discuss standards and interoperability I invite you to check out Jim Waldo's recent blog entry titled "Why Standards?" and his follow up "Why Standards, Part Deux" and join the discussion in The Server Side forum three threads below titled "Opinion: Standards fanaticism curtailing innovation?".

    I quote from my post:

    A good real-world case study of premature standardization is W3C XForms. [...] Another good real-world case study using the "build it first and standarize later" approach is XUL. Innovation using XML to build UIs is flourishing and slowly a XUL community is emerging. [...] See a replay of the original HTML story in the upcoming XUL browser wars and standardization drive and more.
  4. Thanks for the answer Gerald.

    I didn't say XUL has to be a standard or has to have a spec, I just asked. While it is not a standard, it is my understanding that it is also not licensed or owned by any particular company. Is this correct?

    Are the XUL engines that would allow Java programmers to open XUL windows inside an application (without the overhead of starting an entire browser in the application)?

    Gal
  5. jXUL[ Go to top ]

    Have a look at jxul.org.
  6. XUL origins[ Go to top ]

    I think it started as part of the Mozilla project, if you go to mozilla.org you'll find lots of info on it. Also if you snoop around the mozilla install directory you'll see files with XUL documents in them.
  7. Gerald, could you expand and what makes this initiative an 'Alliance'. What are the actual members of the Open XUL Alliance?

    Thanks,

    Bertrand Fontaine
    INSPIRE IT - www.inspireit.biz
    JavaShelf.com - Your Java bookstore on the Web!
  8. XUL Alliance - Who is Who[ Go to top ]

    could you expand and what makes this initiative an 'Alliance'.

    > What are the actual members of the Open XUL Alliance?

      It's just getting started. I invite you to check back in a month or two.

      - Gerald
  9. I suspect that they're refering to the list of applications that currently use XUL.

    Personally, I'm excited about two of the applications:

    * http://koalagml.sourceforge.net/ which allows you to code the GUI in XUL and have it render via Swing or SWT or Gtk+ or Win32. In time it may even be possible to integrate it with JSP and applets. It's basically trying to achieve the golden grail of being portable yet native looking when possible.

    * http://jazilla.sourceforge.net/ which is using XUL to reimplement Mozilla (and eventually Phoenix/Firebird) in Java. The importance of this project is that it creates several Java components that are extremely useful in project like Java IDEs. For instance, it may be possible to extend Eclipse or Netbeans so become as good at HTML rendering/editing as Dreamweaver.
  10. If you have ever doubted that XUL is the future, check out the latest "leaks" about Microsoft's next Windows version codenamed Longhorn I just stumbled over in a blog.

    Hold your breath - Longhorn Betas will ship with a built-in XUL motor this fall. Microsoft calls its new UI engine "Desktop Composition Engine" and the UI markup "XML Application Markup Language (XAML)". Microsoft will even throw in an XAML Visual Designer for Visual Studio. Read more in the latest XUL News Wire posting.
  11. XAML[ Go to top ]

    Gerald,

    I see no mention of XUL whatsoever in the post you quote. Longhorn will ship with Microsoft's own implementation of a technology that lets you define GUI's in an XML effort. No XUL there as far as I can tell.

    It's actually a pretty bad news for XUL, because XAML will probably become a de facto standard on Windows the very day Longhorn will ship.

    Or did I miss something?

    --
    Cedric
    http://beust.com/weblog
  12. Longhorn will ship with Microsoft's own implementation of a technology

    > that lets you define GUI's in an XML effort. No XUL there as far as I can tell.

    I'm not sure if we are on the same page. If you define your UI using XML you might call it XAML, UIX, XUI, or whatever it's still XUL, that is, XML UI Language.

    I can't wait to see what Microsoft is going to call their <window> tag. Any guesses?
  13. XAML[ Go to top ]

    <quote>
    I'm not sure if we are on the same page.
    </quote>

    I guess not.

    The point was just that regardless of the name Microsoft will choose, this technology will not be compatible with Mozilla's XUL. Which doesn't bode well for XUL's future.

    --
    Cedric
    http://beust.com/weblog
  14. XAML[ Go to top ]

    The point was just that regardless of the name Microsoft will choose, this technology will not be compatible with Mozilla's XUL. Which doesn't bode well for XUL's future.

    Every dialect's just a stylesheet away. Skinnability to a whole new level.
  15. This acronym is already used and it stands for the Transaction Authority Markup Language. Does anyone know if this is still alive?


    http://www.xml.com/pub/r/811

    http://www.oasis-open.org/cover/xaml.html
  16. XAML[ Go to top ]

    The point was just that regardless of the name Microsoft will choose, this technology will not be compatible with Mozilla's XUL. Which doesn't bode well for XUL's future.

    >
    > Every dialect's just a stylesheet away. Skinnability to a whole new level.

    Yes and no. If you look at the XUL examples, you'll see that they contain Java code in them that refer to the XUL XML controls. You might be able to transform the XML part of XAML into XUL, but the script code most likely couldn't be converted.
  17. It's actually a pretty bad news for XUL,

    > because XAML will probably become a de facto standard
    > on Windows the very day Longhorn will ship.

    That might be true, but in 2006 no one will care about Windows anymore. Why dish out US$200 for something you can get for free? Ever heard of Linux? It ain't gonna stop. It's getting better as I write.

    > The point was just that regardless of the name Microsoft will choose,
    > this technology will not be compatible with Mozilla's XUL. Which doesn't
    > bode well for XUL's future.

    I would say it doesn't bode well for Microsoft's future. If it doesn't run on Linux, noone will use it.

    Now back to 2003.
  18. <quote>
    Now back to 2003.
    </quote>

    No, let's just get back to the initial point, which was that your statement:

    <quote>
    Hold your breath - Longhorn Betas will ship with a built-in XUL motor this fall.
    </quote>

    is just plain misinformation.

    As for the rest of your comments, I am not interested in engaging in a "MS sucks Linux rules" argument.

    If you want to promote XUL, I suggest you stick to facts.

    --
    Cedric
    http://beust.com/weblog
  19. Longhorn Betas will ship with a built-in XUL motor this fall.


    > is just plain misinformation.

    Again, XUL stands for XML UI Language and that's excatly what XAML is. Just to clear it up, XUL is like HTML it's independent of the browser and has outgrown Mozilla. To give you an example, there's classic Mozilla XUL, and than there is Luxor XUL, Swix XUL, Thinlet XUL, and so on. Soon there will be Microsoft XUL.

    Using different acronyms such as XAML, UIML, UIX, XUI and so on isn't going to help anyone.

    > I am not interested in engaging in a "MS sucks Linux rules" argument.

     I guess you can't handle change. You might wonna join the Microsoft task force trying to figure out how to underprice free, but I guess, assuming you work at BEA you might start your own inhouse.
  20. Gerald,

    If your point is that using markup as a way to describe UI is going to become a common practice, then your point is well taken. However, when you say "XUL" most people think of a specific language. If I read a "XUL" tutorial it explains a specific language. There might be several versions of the language, but still, XUL refers to something specific, not a general concept. So when you say "Microsoft will ship a built-in XUL motor" you are misleading most of the people who read your post. I believe that was Cedric's point, and I couldn't agree more.

    As for the Linux argument, I think MS Windows is going to be the strongest platform by far even in 2006. I may be wrong, we'll just have to wait and see. But I don't know a single project manager who would bet all his marbles on Linux over-taking the workstation by 2006, or on Mozilla over IE.

    Gal
  21. All the projects in the XUL alliance are to create UI using XML definitions. They are not compatible with XUL from mozilla right now ( hope they consolidate into single package ). So I wonder how its going to gain support from developers in real projects.

    what is netUI from weblogic. If anyone used how is it?
  22. Ok, this may be flaimbait, but here I go:

    I wont spend any money or time on a technology/product that is likely to get 'locked in' or killed by some predatory company. It is funny to watch ppl/companies getting involved with the beast, going down on command, just to get wiped out later. Haven't they learned anything from the history?? UNBELIVEBLE!!

    Well, to be fair, it is the company/technology that gets wiped out. The ppl (Some of the then) get new jobs (and a fair amount of shares). The shareholders of the extinct company...Bless their harts.

    So coming back to the subject, sure looks like this is a technology to use. :)
  23. Seems unlikely that Microsoft will pick up on a Mozilla initiative which is not even standartized. They would more likely make up their own markup language, implement it, and maybe then standartized it once they've allready made all the key choices, hence giving the stanard body little room to move. Do you know for a fact that this XAML language is actually XUL? I didn't see anything about it in the news item or the linked article...

    Gal
  24. Do you know for a fact that this XAML language is actually XUL?

    > I didn't see anything about it in the news item or the linked article...

      Again, if you define your UI using XML you might call it XAML, UIX, XUI, or whatever it's still XUL, that is, XML UI Language.

      I can't wait to see what Microsoft is going to call their <button> tag or how about their <dialog>, <wizard>, <textbox>, <checkbox>, <label>, <menubar>, or <toolbar> tag. Any guesses?
  25. Do you know for a fact that this XAML language is actually XUL?

    > > I didn't see anything about it in the news item or the linked article...
    >
    > Again, if you define your UI using XML you might call it XAML, UIX, XUI, or whatever it's still XUL, that is, XML UI Language.
    >
    > I can't wait to see what Microsoft is going to call their <button> tag or how about their <dialog>, <wizard>, <textbox>, <checkbox>, <label>, <menubar>, or <toolbar> tag. Any guesses?

    What about <msdialog>, <xpdialog>, <tdialog>, <dotdialog>, <burnmozzilaburndialog>?

    The possibilities are endless and I'm sure microsoft will pick one that is incompatible with xul. Having different tag names is not a hard thing to workaround but they'll probably use different parameter names and value interpretation, have different layout managers, etc.

    Leonardo Bueno
  26. All Hail XSLT![ Go to top ]

    The possibilities are endless and I'm sure microsoft will pick one that is >incompatible with xul. Having different tag names is not a hard thing to >workaround but they'll probably use different parameter names and value >interpretation, have different layout managers, etc.


    As long as the differences aren't completely mind-boggling, it's nothing on or more XSLT stylesheets shouldn't be able to fix. XAML > XUL or to whatever your markup happens to be
  27. All Hail XSLT![ Go to top ]

    The possibilities are endless and I'm sure microsoft will pick one that is >incompatible with xul. Having different tag names is not a hard thing to >workaround but they'll probably use different parameter names and value >interpretation, have different layout managers, etc.

    >
    > As long as the differences aren't completely mind-boggling, it's nothing on or more XSLT stylesheets shouldn't be able to fix. XAML > XUL or to whatever your markup happens to be

    Yep, yep, yep... as long as...

    I'm pretty sure MS have some creative guys who will find a way to make it hard to write such stylesheet.

    Btw... Can someone point me a XSLT stylesheet that can transform MS HTML to W3C HTML? Oh! I need a transformation for CSS and JS too.

    Regards,

    Leonardo Bueno
  28. I'm pretty sure MS have some creative guys

    > who will find a way to make it hard to write such stylesheet.

     I'm not sure why you want to perpetuate the myth that Micro Willy and his Yes-Man Brigade are invicible.
     
      The point of XUL (XML UI Language) is simplicity. If it's not simple it won't catch on and if it's simple it won't be hard to use as target format.

      Here's a puzzle for the creative Micro boys to solve: Why should I pay a US $200 licensing fee for a US $400 PC if I can't get Linux for free, say, in 2005?
  29. Sorry for the typos. Here's the puzzle again:

    Why should I pay a US $200 licensing fee for a US $400 PC if I can get Linux for free, say, in 2005?

    As an add-on: The city council in Munich asked why should we pay for upgrading 14.000 PCs to XP if we can get Linux for free and help our local economy too?

    All Pinkie came up with was a 15 % discount. How creative.
  30. Why should I pay a US $200 licensing fee for a US $400 PC if I can get Linux for free, say, in 2005?

    >
    > As an add-on: The city council in Munich asked why should we pay for upgrading 14.000 PCs to XP if we can get Linux for free and help our local economy too?
    >
    > All Pinkie came up with was a 15 % discount. How creative.

    I think you've missed my point. I'm just saying that XSLT won't magically make Mozilla XUL compatible with MS XUL or vice-versa. I'm yet to see a something that can make any webpage look and behave in IE and NS the same way.

    Who will win, who will lose it's another story.

    Regards,

    Leonardo Bueno
  31. I think you've missed my point.


    I guess so.

    > I'm yet to see a something that can make any webpage look and behave in
    > IE and NS the same way.

    Now that's hilarious. Have you ever heard about HTML?

    The computer I currently use has both Internet Exploder and Mozilla installed. As far as I can tell there's no difference when I browse the Server Side with Exploder or Mozilla.

    Can help me to find some differences?

  32. > > I'm yet to see a something that can make any webpage look and behave in
    > > IE and NS the same way.
    >
    > Now that's hilarious. Have you ever heard about HTML?
    >

    Yep, it's this markup language defined by W3C that is implemented differently by every single browser out there. (Ok, NS tries to stick with the standard but there are bugs, which will be eventually fixed).

    > The computer I currently use has both Internet Exploder and Mozilla installed. As far as I can tell there's no difference when I browse the Server Side with Exploder or Mozilla.

    To find the differences you'll need to look a little bit closer. It may look the same to you but it's not the same code. Using mozilla, try right clicking this page, go to the privacy tab and take a look at the scripts this page loads. Guess what? There's a browser.js that is used by this page to load different script files depending on the browser version.

    Btw... this different versions of scripts were probably not created autommaticaly and most probably the guys who wrote tss had to put some effort on making this site look almost the same on IE and NS.

    >
    > Can help me to find some differences?

    Well... if you don't already know them I guess you never had to write a complex html page that uses DOM, DHTML, CSS. Just to get started, you may want to do a google search on differences between NS and IE implementation of HTML, CSS and JavaScript/JScript.
  33. if you don't already know them I guess you never had to write a

    > complex html page that uses DOM, DHTML, CSS. Just to get started, you may
    > want to do a google search on differences between NS and IE implementation
    > of HTML, CSS and JavaScript/JScript.

      Guess what? The point of XUL is to replace the Javascript and W3C DOM hairballs with clean markup such as <window>, <tabbox>, <menubar> and many more.

      You might wonna read up on XUL. A good place to start is the XUL Alliance Link-opida.
  34. Guess what? The point of XUL is to replace the Javascript and W3C DOM hairballs with clean markup such as <window>, <tabbox>, <menubar> and many more.


    I'm currently using XUL on a project and belive me, it has lots of JavaScript and DOM stuff in it. As all users will run Mozilla/Linux I don't have to care if my code will be compatitle or if there will be a way to easily transform it to XAML.

    Now what if XAML uses a different DOM and uses VBScript (Or C#Script :)) instead of ECMAScript? What about the XPCOM components? Do you think microsoft will ever replace COM with XPCOM? XUL markup is just one piece of a complete application.
  35. (1) So, it seems we could end up with multiple different XML UI dialects, and presumably tools that understand each of them. Our experience with HTML/browsers indicates we will have the same problems obtaining consistent interpretation in the tools and renderers.

    (2) XML is a fine way for a framework to persist JavaBeans. This leads to what we _should_ be talking about: how JavaBeans have succeeded/failed and how upcoming language features, such as class meta-data and XML persistence, can be used to make creating JavaBeans (even graphical ones) easier. Think @customizer: foo.bar.MyEditor. You shouldn't have to manually create a BeanInfo or FeatureDescriptor. You shouldn't have to write XML persistence code. JavaBeans needs to step into the 21st Century.

    (3) So, this XUL discussion reminds me of the TV commercial Adobe is showing here in the US, wherein they tout their Portable Document Format (PDF). Why should customers care about the persistent form of the documents created by their productivity software? Are they going to drop MS Word because it creates RTF? Not bloody likely. The tool's the thing.

    (4) I guess the Swing-based framework I'm creating is also XUL since its components read/write themselves as DOM Elements and the document content is XML. I call it a Swing framework. My target users don't need to know anything about XML, or even programming. The tool comes first, the persistent format is an implementation detail. If XUL works out and its language can express the concepts in my framework, or it has a capable extension mechanism, the tool will write XUL "compliant" output.
  36. The XUL News Wire reports: Chris McLaren from IBM Canada filed a "bug report" for Eclipse titled: Consider a UI markup language for SWT.

    Chris is not all talk to quote: "All this being said, the actual code to implement XSWT in eclipse (along with the viewer) is quite simple, and took only a few hours to write."

    Chris lists the following pros for XSWT compared to
    hard-coding your UI in Java:

    1. Reduce code significantly. [..] It is 377 lines long, of which 226 lines (line 46 to line 272). These 226 lines can be
    replaced by approximately 30 lines of XSWT code.

    2. Laying out controls can be tedious and time
    consuming for the developer. XSWT allows this work to be split - a UI designer, product manager, etc. could provide XSWT markup to the developer. XSWT markup could be passed around easily via email and anyone with the XSWT plugin could instantly view, compare, modify, make a copy of, etc, without having to be in a java development context.

    3. Even for developers that master complex layouts, they are still often affected by 'clerical' errors, and they usually require a iterative code-run cycle to look at and tweak their composite in its context. [..]

    4. Increase maintainability [..]

    Bingo! Let's give IBM a warm welcome to the world of XUL.
  37. Chris lists the following pros for XSWT compared to hard-coding your UI in Java: ...

    I'd add that the indenting of XUL source explicates the widget containment heirarchy. Java source indentation doesn't.
  38. Most stupid reasons[ Go to top ]

    1. Reduce code significantly. [..]


    I haven't seen the precise code, but in my opionion, this is just in the way XUL is defined. What it actually says is, you can encapsulate language dependent and very flexible layout and components in a number of objects that require less lines of code but are less flexible. This is trivial. XUL is one such way. The interesting question is: How many XUL lines will you need for *complex* layout of *complex* components?

    > 2. Laying out controls can be tedious and time
    > consuming for the developer. XSWT allows this work to be split - a UI
    > designer, product manager,

    Phew, this is like the old designers do the design and developers do the programming stuff. Unfortunately, most of the time, it does not work that way. Requirements include UI feature that need a lot of twisting and tweaking by developers. Twist and Tweak the XUL Motor? Good luck!

    > 3. Even for developers that master complex layouts, they are still often
    > affected by 'clerical' errors, and they usually require a iterative code-run > cycle to look at and tweak their composite in its context. [..]

    Usually it is the *developers* that master complex layout! It is almost never designers and UI experts. These people master Power Point, Photoshop and - if you are lucky - Macromedia director. Anyway. This all comes down to tools, motors etc. And anyone who releases anything without "iterative code-run" cycles should be fired in the first place.

    > 4. Increase maintainability [..]

    No, it actually decreases maintainability, because you have separate tiers for user interface and user interface logic. What you increase is "change the font on that button and swap it with another one" type of stuff. What you decrease is actual software maintainability because of separated responsibility inside tightly coupled components.
  39. Most stupid reasons[ Go to top ]

    Agree with you Karl ;-)
  40. Doesn't matter[ Go to top ]

    Seems unlikely that Microsoft will pick up on a Mozilla initiative which is not even standartized. They would more likely make up their own markup language, implement it, and maybe then standartized it once they've allready made all the key choices, hence giving the stanard body little room to move. Do you know for a fact that this XAML language is actually XUL? I didn't see anything about it in the news item or the linked article...

    >
    > Gal

    It doesn't really matter if the XAML is not the same as XUL. When Microsoft releases the XAML they will provide a schema for using the XAML, then we use a XMLC and convert a XAML UI to a XUL UI and port the screen to Mozilla. And vise versa (but who would do it the other way around???)
  41. Why does Microsoft need to win[ Go to top ]

    Why does everybody believe that Microsoft will win by default.

    Who cares if it only runs in Mozilla, if people wrote applications in XUL and made using Mozilla a requirement, people would - surprise, surprise - download Mozilla, how many people run windows because you need windows to run your applications.

    Secondly if the Vendors got together and supported XUL and pushed it XUL could win over XAML, remember CORBA?.

    Methiks the problem is not Microsoft, the problem is that Vendors are their own worst Enemy for a start they...
    1. Never listen to the people who use their technologies
    2. Squabble over a dwindling slice of Pie (proprietary unix comes to mind)
    3. Sit high on thier pedestals while they watch as Microsoft blows them away from the bottom up and then whine and squeal and moan about it, the only reason Microsoft is where it is today is because the HPs, the IBMs, the Netscapes, the Oracles and Suns of this world where fast asleep and bickering among themselves.

    If we want XUL to succeed the vendors need to start supporting it now, and the community needs to start supporting it as well.
  42. Using Mozilla[ Go to top ]

    I am working for a company that has selected Mozilla as a client for a web based application. We explain to the customers that we have selected this framework because of its rich UI capabilities, and so far there were no objections, some are even exited to use it. As of today, there are more than 50 computers at 4 locations that have Mozilla installed and happy users are using the first version of the product. BTW, I used exactly the same excuse 3 years ago to drop Netscape Navigator support for a different product, and we didn't have any objections from customers, even where Netscape was the standard. When there is an application that provides high value to the user, IT will go an extra mile.
  43. I don't understand why all of you guys talking about some "XML" UI language.
    Why don't you like HTML/XHTML as evolution?
    I'm already can write ANY desktop UI(and beyoud) on IE6 with little trouble.
    In real, all talking about object model itself and automation possibilities
    (if I can deal with .NET classes same as IE BOM/DOM objects I don't need anything else ;-).
    If Microsoft can provide quality implementation of emerging XML standards
    in IE7(not InfoPath) I will be quite happy with it...

    Any thoughts?
  44. I don't understand why all of you guys talking about some "XML" UI language.

    > Why don't you like W3C HTML/XHTML as evolution?

      Remember what HTML stands for? Hyper Text Markup Language

      HTML is great for rich (styled) text but fails for rich UIs. Using Javascript, DOM, ActiveX, .Net Components or whatever is exactly what Microsofts wants you to do to lock you into Internet Exploder.

      If I want to create a toolbar why not use simply a <toolbar> tag? If I want to create a menu why not use simply a <menu> tag? If I want to create a data grid why not use simply a <datagrid> tag? If I want to create a tree why not use simply a <tree> tag? I guess you get the picture. Here are some more tags for you to excercise: <wizard>, <tabbox>, <stack>, <deck>, <dialog>, <groupbox>, <browser>, <editor>, <popup> and so on.
      Now something completly different: Politics

    Ask yourself why does the W3C show no interest in XUL (XML UI Language)? Answer: It's a political hot potatoe like universal health care or raising taxes in the US. Any chance to get anything into Internet Exploder will be nil, zero, nada.
  45. What about html behaviors that Microsoft push as W3C standard long time ago?
    Look at msdn.microsoft.com/ie(behaviors section) tabstrip/treeview
    etc. components implementation-it's exactly <toolbar>...
    and you can make any of standard HTML tags to have some original "flavor".
    By the way Microsoft herself hardly use html variations on desktop
    (why IE is core of most windows services?)

    Regards.
  46. I am arguing that there needs to be a universally agreed-upon

    > definition of "XUL".

    If have started a discussion thread in the xul-talk mailing list @ the Open XUL Alliance site titled "XUL and Standards" and I invite you to join in.

    Here's a teaser:

    As it looks now most people still think XUL is bound to Mozilla and worse to W3C DOM or Javascript and haven't realized that it has outgrown its root and is a stand-alone markup language like HTML independent of any browser brand.

    Also using different acronyms such as XAML (XML Application Markup Language) by Microsoft, UIML (User Interface Markup Language) by Harmonia, UIX (User Interface XML) by Oracle, XUI (XML User Interface) by Xeotrope or my favorite AAIML (Alternate Abstract Interface Markup Language) by the International Committee for Information Technology Standards (INCITS) isn't going to help anyone.

    Why not stick with XUL, that is, XML UI Language and then call they dialects Mozilla XUL, Luxor XUL, Thinlet XUL, Microsoft XUL, Oracle XUL, BEA XUL, INCITS XUL and so on.