Linux Today Article Recommends Sun Adopt XUL for JavaFriday February 27th, 2004Tomas Marek (marek<AT>tipsport<DOT>cz) and guzzi333 pointed us towards a Linux Today article in which Ganesh Prasad argues that Sun should levarage the work of the open-source community to improve enterprise Java and fight back against Microsoft's .NET. The author singles out client-side rich user interfaces as an area in which Java is weak, and recommends that Sun adopt XUL to fill the gap. This would help to combat Microsoft's XAML technology, which is similar to XUL and designed to work well with .NET applications. Prasad also claims that Sun could give credibility to XUL and encourages the company to work with the Mozilla Foundation to get the language endorsed as a W3C standard. 1. Invent and keep on developing Java 2. Make it free 3. ??? 4. Profit Now add XUL to this equation. Exactly how does Sun make money with this? I don't know if anyone cares but their stock is like at 5 bucks. They need to do something that makes money instead of takes barbs at MS. "1. Invent and keep on developing Java 2. Make it free 3. ??? 4. Profit "Now add XUL to this equation. Exactly how does Sun make money with this?" The idea is that it would make Java a more compelling technology, allowing them to hold Microsoft's .NET back. Sun has a lot in invested in Java (as do other companies such as IBM), which would be damaged if it started losing out to .NET. Alex I like how the author criticizes Raymond's challenge to Sun. It annoys me when people have an attitude that all commercial software is evil or that unless you open source all your software you are no real friend to the open source movement. From what I read, .NET sounds like a fairly solid platform and some tough competition, and XAML is much larger than XUL. I fear that MS's XAML will become the de facto standard for XML user interface languages (at least on Windows) the moment Longhorn comes out. The possibility that Sun and Mozilla could help each other is exciting. But I'm not clear on what exactly Sun would do to advance XUL: get it adopted as a WC3 standard, expand on it (XUL 2?), have Java programs generate content in XUL and other web standards, have Java programs render GUIs described in XUL, any other ideas? Just to let you know that many free, open source XUL (XML UI Language) players/browsers/runtimes exist already e.g. SwiXML, Ibex, Luxor, Thinlet, Beryl and many more. See the XUL Alliance online @ http://xul.sourceforge.net or the XUL News Wire online @ http://news.gmane.org/gmane.comp.lang.xul.announce for details. Note, that Mozilla XUL is just one of many XUL (XML UI Language) dialects. Yet another clear violation of the XUL trademark (http://www.mozilla.org/foundation/licensing.html). Hopefully the mozilla org finally cracks down on this guy. Sorry to break the bubble but XML UI Language is a generic term that you can't trademark. Allow me to quote US trademark regulation: 1209 Refusal on Basis of Descriptiveness Extract from 15 U.S.C. §1052. No trademark by which the goods of the applicant may be distinguished from the goods of others shall be refused registration on the principal register on account of its nature unless it .... (e) Consists of a mark which, (1) when used on or in connection with the goods of the applicant is merely descriptive or deceptively misdescriptive of them.... Matter that “merely describes” the goods or services on or in connection with which it is used is not registrable on the Principal Register. As noted in In re Abcor Development Corp., 588 F.2d 811, 813, 200 USPQ 215, 217 (C.C.P.A. 1978): The major reasons for not protecting such marks are: (1) to prevent the owner of a mark from inhibiting competition in the sale of particular goods; and (2) to maintain freedom of the public to use the language involved, thus avoiding the possibility of harassing infringement suits by the registrant against others who use the mark when advertising or describing their own products. Anyway, in case you haven't realized it yet the world has moved on and nobody cares about the XUL hairsplitting debate any longer. If you want to reread the phony arguments from some Mozilla die-hards, please feel free to browse the xul-talk mailinglist archive. XML UI Language may be a generic term, XUL definitely not. Please note that XUL is a trademark of the Mozilla Foundation, not "XML UI Language", so your reasoning doesn't apply here. Stefan > XML UI Language may be a generic term, XUL definitely not. > Please note that XUL is a trademark of the Mozilla Foundation, not "XML UI Language", so your reasoning doesn't apply here. Sorry, I can't follow your reasoning. How do you abbreviate XML UI Language? Or in case you refuse to see the connection. What does XUL stand for? Also note that XML stands for vendor-independence. How can the Mozilla Foundation claim XML UI Language all for itself? Has the Mozilla Foundation licensed the XML acronym? Please stop fooling the world. mozilla.org developed the "Mozilla XUL", which was named XUL before any other "XML UI Language", and thus it's normal that they have the trademark on it. Don't see "XUL" only as an acronym, but also as a name that describes something directly. When we talk about XUL, we're talking about what you call "Mozilla XUL", and so your idea of XUL is not the discussed here. Sorry to post again, but I've found this in the article: Doesn't the non-Microsoft world have anything similar? Well, if Microsoft releases an "innovation", it's a safe bet that someone else thought of it first. Sure enough, the inspiration for XAML can be seen to be an Open Source rich client framework from the Mozilla Foundation, called XUL. --- They're talking of Mozilla's XUL, not of XUL as a generic name, which produces confussion, division of efforts and unnecesary incompatible variations of XML UI Languages. > Sure enough, the inspiration for XAML can be seen to be an Open Source rich client framework from the Mozilla Foundation, > called XUL. Well, let's dissect the article. Cleary XUL is not a rich client framework it's a XML-based UI language. I guess the author isn't aware that Mozilla calls its rich client framework XPFE (TM) and that Mozilla (R) XUL (TM) (XML UI Language) is just a tiny part. You can't use Mozilla (R) XUL (TM) without XPCOM (TM), XPInstall (TM), XPConnect (TM), XPIDL (TM), XBL (TM), and so on, can you? Also note that Microsoft (R) doesn't claim XAML (Extensible Application/Avalon Markup Language) as a trademark. XAML is just a code-named that Microsoft (R) is going to change later on to a real trademark/brand such as WindowsML (R) or similar. OK, so I have a business plan. I'm going to set up a company that sells big machines to international businesses. I plan to call my company International Business Machines, or IBM, since that's just a collection of words that describe what I'm doing. I don't expect the fact that there is another company with a trademark on the term IBM to be a problem because, according to Gerald, trademarking acronyms made up of descriptive terms is illegal. I was planning to expand my business by producing a proprietry XML based markup language for exhanging information between my machines. I was going to protect my language by strictly licensing the use of my (copyrighted!) schema. Except Gerald says I can't do that, because "XML stands for vendor independent". Well there I was thinking that XML was just an acronym for the name of a particular format for markup languages! Now I know better! >> XML UI Language may be a generic term, XUL definitely not. >> Please note that XUL is a trademark of the Mozilla Foundation, not "XML UI Language", >> so your reasoning doesn't apply here. > > Sorry, I can't follow your reasoning. How do you abbreviate XML UI Language? > Or in case you refuse to see the connection. What does XUL stand for? This is completely irrelevant. IBM is a registered trademark (see http://www.ibm.com/legal/copytrade.shtml), albeit the words "international" "business" and "machines" are all generic. IBM doesn't need to "own" these three words, because IBM is the trademark not the words this acronym stands for. The same is true for XUL and "XML UI Language". Please do us all a favour and stop talking about XUL when you really mean any XML UI language. I think everyone would be happy then, which can only be a good thing for your cause and would us all save some unnecessary discussions. ;-) Stefan The bit of trademark law you quote is designed to stop me selling my loaves of bread under the name 'Bread' and then suing anyone else who refers to their bread as 'bread'. It doesn't apply to XUL as the term was coined by the Mozilla project: nobody had used the term XUL to describe XML-based declarative user interface markup languages before. This is an example of people using the brand name of a market leader as a generic term, as has happened with Coke, Kleenex and Hoover. While this can lead to a trademark becoming generic over time, the trademark is still valid if the trademark owner defends it. Alex not trademarking purely descriptive names sounds perfectly reasonable. how did microsoft get away with 'windows' then? it has been bashing products that sound similar (i.e. lindows, wxWindows->wxWidgets, etc). "not trademarking purely descriptive names sounds perfectly reasonable. how did microsoft get away with 'windows' then?" That's an interesting issue that has been brought up in the Lindows trademark infringement case. Alex Everytime an article comes up about XUL, this jack-ass goes off on a run. PLEASE people STOP FEEDING THE STROLL!! The thing with .NET is it's not multi-platform. Microsoft only supports Windows implementation of .NET (so dont mention 0.3 Mono) and Sun supports Java on all major platforms. So .NET is not even a competitor to Java. Anyone who is only concerned with Windows will program in VB. That's just reality. I do however agree the Java GUI is weak. The only thing, unfortunately, that will allow people to use technologies that aren't MS is when document formats are openned. I use OpenOffice exclusively but haven't mustered the courage to send someone an OpenOffice Document file instead of a MS .doc <b>"I use OpenOffice exclusively but haven't mustered the courage to send someone an OpenOffice Document file instead of a MS .doc"</b> I did that accidentally once. They just wrote back saying that it was corrupt. I didn't however have the nerve to write back saying that Microsoft's .doc file format was far more corrupt! If Sun where to make XUL the default GUI then what about the existing code base which used AWT / Swing for the GUI. The transition will be painful for both Sun and the end users. Another thing to look at is the maturity level of XUL. Agreed XUL has a rich collection of controls, but would it suffice ? Would it be rich enough for ISVs to write applications for business users ? That is one thing that needs to be addressed. It is not just the open sourcing of technology that will generate any revenues, it is the allegiance of the developers that will make a particular platform more successful. The more the ISVs the better it is. Also consider the case of the GTK toolkit. This is also cross-platform, open sourced. How does XUL compare against this toolkit ? Agreed XUL is *much easier* than GTK, but what about the programming model ? All these things need to be looked at. I do think it would be worth Sun supporting an XML-based interface language - creating interfaces in code is good as an option but shouldn't be required, and then there are too many idiots who use IDE tools that write REALLY REALLY BAD interface code for them using shitty semi-GUI interface builders... java source code is really not the right place for autogenerated interface data to go... But I don't think there's any particular reason why it should be XUL. After all, XUL: 1. is not a W3C standard 2. is not used outside Mozilla (ok, except by a few crackpots, see above part of thread, but I'm not aware of any significant, large-scale projects other than the Mozilla-related ones) 3. isn't a natural match for existing Swing components Seems to me that it would be fairly easy to create an XML-based interface language built on the existing Swing components via Java Beans. This would provide developers with an easy way to create existing Swing components. In fact can't you already serialise beans to XML...? Not sure this would handle the 'code' issues (embedding code, rather than just describing layout) but... Incidentally on saturday I actually developed xml support for my own java layout stuff I'm doing (this is just for my own program). It's trivially easy to make xml files represent java layouts, I think it took me less than an hour to plug in xml 'layout creation' support to my framework [again, this doesn't have embedded code], but I agree there ought to be a standard built-in way to do it for all JavaBeans components (including Swing), with IDE support and so on. I sort of worry that a standard built-in way would be overly verbose and complex if Sun come up with it but, eh. :) I haven't looked at the XUL spec so maybe that is already overly verbose and complex... --sam Some contributors to this subject are running too far ahead. The Mozilla render engine Gecko contains the kind of widgets that XHTML renderers do not possess. For now, all I wish to do is substitute XHTML by XUL when delivering content to my browser clients so that I can tap into those rich widgets. I'm already using Javascript and CSS. In a nutshell, I replace one XML vocabulary by a more advanced one. That way I can migrate my IT application UIs on to a web browser and give my users more flexibility. All this talk about what you might or might not do with Swing/SWT is getting far ahead of the story. Let's deal with what is required now - web-based rich clients that are very messy and difficult to produce with XHTML. Yes, I know XPFE is capable of more but for now let's address an immediate doing the simple stuff first and see where that gets us. If Sun/Swing/NetBeans or IBM/SWT/Eclipse choose to use XPFE to unify the thin and thick clients then all the better as far as I am concerned. And if they choose to use XUL only for describing content to be rendered by some component of the JRE then that's fine with me too. I'd like to be able to create just one content that is capable of being rendered as either desktop-based or browser-based application. Let's see what is produced before judging the merits of each offering. |