MozillaZine

Full Article Attached Open XUL Alliance Site Goes Live

Sunday May 25th, 2003

Gerald Bauer writes in with news that the Open XUL Alliance site has launched. The site aims promote XUL and encourage interoperability with a collection of XUL news articles, mailing lists and links.


#1 Speaking of interoperability...

by choess <choess@stwing.upenn.edu>

Sunday May 25th, 2003 7:56 PM

Reply to this message

Is there actually a formal spec/DTD/Schema/RELAX schema for XUL? Trying to build a bunch of systems based on "what hyatt could be bothered to implement" doesn't sound like a viable longterm plan.

#5 Re: Speaking of interoperability...

by Dracos

Sunday May 25th, 2003 10:25 PM

Reply to this message

Nope, no DTD or schema. This is mostly because XUL allows authors to add arbitrary attributes to XUL elements, which is a very useful feature <window myattrib="foo"></window>, but makes generating a schema or DTD impossible.

#7 Re: Re: Speaking of interoperability...

by met

Monday May 26th, 2003 2:07 AM

Reply to this message

... and via XBL you can define your own tags (windgets).

#38 Well...

by dhyatt

Wednesday May 28th, 2003 1:34 AM

Reply to this message

Technically I'd like to see all of the custom tags move into their own extensions namespace so that the core XUL namespace could remain uncluttered. I actually got about a third of a way through defining a schema, but it's just so damned complicated. I got so disgusted with the process (and the time it was taking) that I ended up dropping it.

Also, there's plenty of behavior specified that has not yet been implemented in Mozilla (in both XBL and XUL actually). box-align: justify anyone? :)

#2 Can't stand to look at the bright yellow < 2 secs

by dadada <da@toadmail.com>

Sunday May 25th, 2003 8:22 PM

Reply to this message

Ouch!

#3 Re: Can't stand to look at the bright yellow < 2 s

by gmoney

Sunday May 25th, 2003 9:20 PM

Reply to this message

Go to View > Use Style > Basic Page Style to get rid of all the yellow except the logo

#8 Can this be done with Mozilla Firebird?

by Galik

Monday May 26th, 2003 5:20 AM

Reply to this message

.

#10 Re: Can this be done with Mozilla Firebird?

by tve

Monday May 26th, 2003 7:33 AM

Reply to this message

#4 Self-installing XWT to get XUL in the door?

by gmoney

Sunday May 25th, 2003 10:06 PM

Reply to this message

This is a little off-topic but I've just started looking XUL as a UI framework and it's simplicity and web-based nature are exciting but I figured I'd face resistance in an IE-only shop asking IT install Mozilla on every PC in order to use XUL (e.g. "they don't need another browser", "your app is supposed to be web-based so why do we have to install more stuff on the client", etc). The XUL Alliance Site is the first place I've seen mention the self-installing ActiveX XWT. Perhaps after a sucessful deployment of a simple screen or two using XWT one could build enough confidence and momentum to move on to a more full-featured Mozilla XUL if necessary? ...anyone out there have any advice on getting XUL in the door?

#32 Re: Self-installing XWT to get XUL in the door?

by ygoraly <ygoraly@yahoo.com>

Tuesday May 27th, 2003 8:21 PM

Reply to this message

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 exitied 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 provide high value to the user, IT will go an extra mile.

#6 Standards and Innovation - XUL replays HTML story

by geraldb

Sunday May 25th, 2003 10:27 PM

Reply to this message

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?" online @ <http://www.artima.com/web…/viewpost.jsp?thread=4840> and his follow up @ <http://www.artima.com/web…/viewpost.jsp?thread=4892> and join the discussion in The Server Side forum online @ <http://www.theserverside.…hread.jsp?thread_id=19492>

I quote from my post at The Server Side:

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.

#11 I'm trying to be civil...

by choess <choess@stwing.upenn.edu>

Monday May 26th, 2003 2:42 PM

Reply to this message

...but the level of blithe ignorance being displayed here is making it hard. Now, I agree that a standards body totally detached from reality is likely to produce disastrous results: the OSI example is a good one. However, the idea that HTML would never have been improved without unstandardized "innovation" is revisionism promulgated after the fact to justify the disastrous results of vendor ignorance. See <http://groups.google.com/…u2%40client3.news.psi.net> for a good summary of HTML was dragged disastrously backwards into the HTML 3.2 morass of presentational tags.

If you're serious about XUL interoperability, I suggest that something along the lines of the current W3C process would be fitting: improvements to a recommendation are assembled into a Working Draft by representatives of the various implementors of the recommendation. When the draft is finalized, it advances to Candidate Recommendation, where it stays until two interoperable implementations of the standard are produced. (Good testcases and a strong definition of "interoperable" are important here.) This allows for useful feedback "from the field" and the document may be revised again. Only after this is complete can it advance to Recommendation status.

If you really think the "original HTML story", with browser wars, mountains of undocumented incompatibilities and browser bugs, and stupid "innovations" produced by people who didn't understand the underlying architecture they were modifying, is worth emulation...well, you just might get it.

#12 Re: I'm trying to be civil...

by jgraham

Monday May 26th, 2003 3:16 PM

Reply to this message

That's fine but I don't see why it's relevant to XUL. Just because it's an XML language doesn't mean it has to be a w3c (or any other) standard in order to be useful for it's designed purpose. The power of XUL isn't in producing web apps (for that, it would need to be a standard), but in producing application interfaces that are able to run locally or from a remote server. So, for example, a company could deploy an XUL contacts directory on their intranet which could use common interface features, such as tree controls, that aren't avaliable in html. In that situation, it doesn't matter whether there are two or more interoperable implementations - all that matters if having a single implentation that does what the company wants. That might mean using Mozilla-the-browser on every desk, might mean using the Gecko activeX control, or might mean using some other XUL runtime environement. That deosn't require any more standardisation than .net or any other similar language does.

If XUL were to become big /on the internet/ then standardisation would, of course, be necessary. But, in my opinion, the people who are suggesting XUL could be used on public websites are misguided. Just because it uses internet technologies doesn';t automatically mean it should be used on the internet at large.

#14 True to an extent ...

by GuruJ

Monday May 26th, 2003 4:52 PM

Reply to this message

... but one extremely good reason for standardization is *ease of coding*. When there was just one implementation of HTML, it was easy for anybody to pick it up, whack in a few <b> and <i> tags and know how things would look.

But then the "bad old" days of NS & IE 4 came along. Users had to learn at least two alternate (and incompatible) ways of doing the same thing (<ilayer>, anyone?). This greatly raised the bar for entry to programming HTML.

It's hard enough to program XUL in Mozilla, where the language has been known to change fairly significantly from release to release, without backward compatibility. Imagine if we had *six* implementations of XUL, none complete, and all changing spec from week to week. Unless people can pick up their XUL knowledge from one implementation and easily apply it to another, they're either not going to bother, or will get very frustrated.

Documentation, while improving, is still fairly sparse on the ground, and I think standards would greatly aid people in their adoption of XUL. I know that ANSI C came a long time after C, but there's no reason to follow the historical just because 'it happened that way before'.

#15 Welcome to the Real-World: Theory != Practice

by geraldb

Monday May 26th, 2003 5:24 PM

Reply to this message

> I'm trying to be civil > but the level of blithe ignorance being displayed here is making it hard. [..] > stupid "innovations" produced by people who didn't understand the underlying > architecture they were modifying

I guess you're just another academic snob detached from reality (assuming from your email, *.upenn.edu, that you work in academia).

Backing up your claim with a single newsgroup posting is laughable. Please, try harder if you want to be taken serious.

#17 Real World, Indeed

by choess <choess@stwing.upenn.edu>

Monday May 26th, 2003 9:14 PM

Reply to this message

Did you actually look over my post, or read the first and last sentences and decide to write me off as hopelessly out of it?

1) Given that my academic training is in Biochemistry, I'm not particularly attached to any academic perspective on markup or UI design. (Neither, I daresay, are most of the other Mozilla developers/QA with *.edu addresses--which includes our top layout developers[1].) In fact, I'm primarily involved in Layout/Parser bug triage, so I get to see on a regular basis all the very real things we have to do to work around bad decisions made during the evolution of HTML. I'm not passionate about this because I like getting people hot and bothered; I'm passionate because I see a really tremendous failure to learn from history going on here.

2) Do you have a refutation for the actual *points* of the newsgroup post, which I chose as a useful summary review and refutation of the W3C-stifled-innovation myth? The primary points, as I see them, are as follows: a) After about a year of discussion on the most significant WWW mailing lists of the time, the W3C released the first public draft of the Cascading Style Sheets specification. b) Three days later, the first public beta of *Mosaic* was released, without stylesheet support. c) Later versions of Mosaic introduced various presentational elements, a significantly inferior method of changing the display of documents. This was "innovation". d) When Netscape finally introduced stylesheet support...it was hailed as an example of their innovation, again.

CSS is not a particularly complicated technology. (If the W3C had been advocating DSSSL, a more powerful but significantly more complicated and difficult-to-implement technology, the decision might have been more understandable.) In short, it was a browser vendor in this particular (and important) case that stifled innovation by ignoring the W3C's work and deploying an ill-considered technology for what we can only assume to be short-term internal reasons.

Look, I agree with you that throwing a bunch of academics into a locked room and waiting for a standard to emerge through parthenogenesis is a useless waste. This is why I brought up the W3C's *current* process, which I think strikes a good balance between peer review/architectural considerations and actual field experience/individual needs. But this idea that you can build widely accepted standards through competition alone, without peer review from disinterested parties or any sort of checks on individual desires, is just as foolish. Ultimately, *some* things have to be dropped, or some details locked to agree with one implementation and not another, when a language is standardized; how long does it take, then, to fix up all the implementations to agree with the standard? How long does it take to fix up all the documents written in the language so they now work correctly according to the standard, and not just the local implementation?

Once again, I warn you that if you admire the "process" by which HTML developed, you are likely to get it. But I suggest that you ask any of our core developers if they think it's a process worth repeating; I'd be highly surprised if any of them agreed.

[1] Actually, dbaron got picked up by NS last month, but he's been a long-time student-developer.

#18 History 101 - Nostalgia - The Golden Age Is Over

by geraldb

Monday May 26th, 2003 9:43 PM

Reply to this message

In your post you're talking about the W3C as it acted close to ten years ago when it was a young organization that had to prove itself. Today more than ten years later it's a different story. Just recently they gave up on Amaya - their experimental open-source browser. No, more coding for us we leave the dirty work to the commoners. Don't get me wrong the W3C has achieved a lot but it's time to move on.

To quote from my Server Side post: A good real-world case study of premature standardization is W3C XForms. I had a discussion back in April with the XFroms community and spec leads on the <www-forms@w3.org> mailing list that you might wonna check out @ <http://lists.w3.org/Archi…forms/2003Apr/thread.html>

See the threads entitled "Welcome to the Real-World; The Future of XForms" @ <http://lists.w3.org/Archi…w-forms/2003Apr/0014.html> and "The Devil of Good is Perfect" @ <http://lists.w3.org/Archi…w-forms/2003Apr/0039.html> , for example.

Also 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.

#19 XUL, the W3C, and Peer Review

by choess <choess@stwing.upenn.edu>

Monday May 26th, 2003 10:48 PM

Reply to this message

Gerald,

I'm not trying to argue that XUL should fall under the aegis of the W3C, although in retrospect I can see how my posts suggested that. Indeed, I'd be happier if the W3C divested itself of some of the more tangential recommendations it develops, such as the Web Services-related activities.

What I am arguing is that there needs to be some sort of forum for establishing a universally agreed-upon definition of "XUL". The attitude I'm seeing is "We'll all throw something together, and eventually we'll write down all the good stuff and make it a standard." If there's more of a process that I've missed, I'd be happy to hear about it. I don't think this is a viable model.

To talk some specifics: XForms: I'll withold comment other than to say that denouncing XForms in vague and less-than-constructive terms, about 3.5 years after public discussion first began about the recommendation and its direction, may have been less than politic.

XML Schema: This is a good example of the W3C process gone awry. Because of pressure from the Web Services side (esp. including Microsoft), the final product was bloated, overcomplicated, and is disdained by those seeking to create XML languages such as XUL in favor of RELAX. Unfortunately, this seems like the sort of problem that would only be exaggerated by a "implement and sort out later" approach. Each implementor will probably have a different vision of what they want the language to do, leading to overspecialization in different areas in each implementation, and making them very difficult to reconcile later.

That said, here's what I think is a reasonable approach to guiding XUL development:

Form some sort of "XUL Consortium" or whatever you want to call it. I don't think it need be as formal or fee-based an organization as the W3C; open source implementations will be important here. Essentially, membership should be open to anyone actively working on a XUL implementation, or major consumers of XUL (the two will probably be the same initially, although I can certainly see major software products implemented on such a toolkit as yours). Other than that, I see XUL evolution progressing roughly in the manner I described in my last post: members (all of whom have some "hands-on" experience with XUL development and implementation) create a working draft based on what they *in consensus* view as useful additions (or deletions!) to XUL. Once they've hammered out a document that everyone can at least agree on, the new features can be provisionally implemented, and feedback from real experience provided to the group (good, bad, hard/easy to implement, hard/easy to use, etc.). Again, when a consensus is reached and two interoperable implemenations exist, it can be considered a standard/recommendation.

What I think is most important is the element of peer review. You may dislike committees/consortia as incapable theoreticians, but your own perspective as an implementor is likely to be colored by your own knowledge, and the needs of your applications and its users. But any standard/recommendation is more than you and your own application, and having other users of the standard, with their own knowledge and needs, weigh in on the direction of the standard is an important check to keep the standard relevant to everyone.

#20 Are we on the same page?

by geraldb

Monday May 26th, 2003 11:40 PM

Reply to this message

> there needs to be some sort of forum for establishing a universally agreed-upon definition > of "XUL".

Now, I'm not sure if you missed the headline "Open XUL Alliance Site" goes live. Please, click on the link and you will see a mailing list entitled xul-talk with the blurb "Beyond Mozilla; Talk about XUL issues touching more than one XUL motor/browser/runtime"

> The attitude I'm seeing is "We'll all throw something together, and eventually we'll write > down all the good stuff and make it a standard." If there's more of a process that I've > missed, I'd be happy to hear about it.

It's all just getting started. Now is the time to innovate and build up some XUL motors/browsers/runtimes. It's too early for creating a spec.

If you want to get started, however, you're more than welcome. How about cleaning up W3C XForms or Mozilla XUL and creating a fresh XUL+XForms working draft?

> Form some sort of "XUL Consortium" or whatever you want to call it. I don't think it need be > as formal or fee-based an organization as the W3C

Have you heard about the Open XUL Alliance?

#31 Re: Are we on the same page?

by bzbarsky

Tuesday May 27th, 2003 8:08 PM

Reply to this message

> It's all just getting started. Now is the time to innovate and build up some XUL > motors/browsers/runtimes.

It looks like your definition of XUL is "any XML dialect that defines a UI". For example, if Visual Studio were to store the state of a Visual Basic project in XML, you would consider that to be XUL.

That's a fine definition, albeit a useless one. Useless because there is nothing that such XML formats have in common beyond being XML -- hence there is no reason to ever consider them as a group, beyond attempting to write converters between them (something that's bound to fail as miserably as Word-to-HTML converters already do, due to the differnt languages having different capabilities).

If what you are looking to do is tracking various XML-based UI definition languages to see what features each one has and then creating a new language that attempts to combine the best features of each, that's a fine undertaking (it sounds to me that this is what you are doing). But trying to cover up this effort with the name "XUL" would be an exercise in revisionist history, imo -- XUL would be one of the languages that you would be using as a basis for the language you design, and your language would not be any more XUL than it is XAML or any of the other languages you have mentioned in the talkback threads.

-Boris

#36 Re: Re: Are we on the same page?

by kerz <jason@mozillazine.org>

Wednesday May 28th, 2003 1:20 AM

Reply to this message

Visual Basic rocks. Glad to see you agree!

jason

#78 Re: Re: Re: Are we on the same page?

by bzbarsky

Thursday May 29th, 2003 9:04 AM

Reply to this message

I expressed no opinion on the quality of Visual Basic, mostly because I have no such opinion, having never used it.

#9 XUL Outgrows Mozilla: Discussion @ The Server Side

by geraldb

Monday May 26th, 2003 7:28 AM

Reply to this message

Now there's also a XUL discussion going on at The Server Side @ <http://www.theserverside.…hread.jsp?thread_id=19506>

Guess what was the first post again? Yep, "Is XUL a standard?".

#13 Microsoft will ship Longhorn with XUL motor

by geraldb

Monday May 26th, 2003 4:36 PM

Reply to this message

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 online @ <http://article.gmane.org/…comp.lang.xul.announce/17>

#16 Nice

by jedbro

Monday May 26th, 2003 7:56 PM

Reply to this message

How sick is that!

#21 Re: Microsoft will ship Longhorn with XUL motor

by james

Tuesday May 27th, 2003 12:04 AM

Reply to this message

Other than being an XML based user interface description language, what does XAML have to do with XUL?

#22 A Rose By Another Name Is Still A Rose

by geraldb

Tuesday May 27th, 2003 6:58 AM

Reply to this message

> Other than being an XML based user interface description language, what does XAML have to do with > XUL?

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.

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

I can't wait to see what Microsoft is going to call their <window> tag. How about their <button>, <dialog>, <wizard>, <textbox>, <checkbox>, <label>, <menubar>, or <toolbar> tag. Any guesses?

#35 Re: A Rose By Another Name Is Still A Rose

by james

Wednesday May 28th, 2003 12:26 AM

Reply to this message

Their are lots of XML based user interface description languages, and many of them look nothing like the XUL that Mozilla uses. There are many decisions you can make when designing such a format, and people won't necessarily make the same decisions as the Mozilla developers made.

If your aim is to design a language to describe user interfaces built with a particular widget set (eg. Win32, MacOS Coacoa, GTK, etc), you would usually structure the language to match how the widgets are layed out. For instance, the "menubar -> menu -> menupopup -> menuitem" heirarchy used by XUL doesn't map well on to GTK, since the widget heirarchy in GTK is "menubar -> menuitem -> menu -> menuitem".

Another place where GUI toolkits differ is geometry management (ie. how do we lay out child widgets inside a container, and how do we redo the layout when the window is resized). This is another place where Mozilla's XUL does not match the semantics of some GUI toolkits. Implementing the XUL semantics on top of the toolkit may be impossible or prohibitively difficult. Additionally, not all the aspects of the toolkit's geometry management system may be representable with XUL in its current form.

In the case of Microsoft's UI description language, do you really think they would give higher priority to "making it compatible with Mozilla's XUL" rather than "making it work consistantly with their existing technologies"?

If the only thing in common between XUL and XAML are that they are represented in XML and describe user interfaces, then I wouldn't call it XUL. Doing so is just going to cause confusion.

Of course, since I haven't seen a XAML specification or example code, I don't know what it will look like. However, I didn't see anything in that article that would lead me to believe that it will be compatible or similar to XUL.

#26 Is it XUL like?

by ndeakin

Tuesday May 27th, 2003 9:33 AM

Reply to this message

The articles you link to aren't very clear about what XAML is. My reading of them suggest it's a form of behaviors (or XBL). The articles refer to 'XAML scripts' and 'Developers will be able to manipulate the objects by XAML or C# code'. This suggests its more a scripting language for UI manipulation, than UI description. But then again, it might just be a misinterpretation by the article's author.

#23 Embrace? Extend? or both?

by Galik

Tuesday May 27th, 2003 8:00 AM

Reply to this message

Well it's obvious where this one's going...

#27 Not quite like Java/MSJava

by flacco

Tuesday May 27th, 2003 10:43 AM

Reply to this message

Java had wide enough name recognition that it could kind of stand up for itself. Given XUL's relative obscurity, I have little doubt that MS once again will be incorrectly hailed as the great innovator.

#25 Like Java?

by Racer

Tuesday May 27th, 2003 9:17 AM

Reply to this message

This reminds me of the time that M$ packaged their own rendition of "Java" with Windows and IE. Sure, everyone (including Sun) was happy at first; until they found out that M$ changed M$ Java just enough to not be compatible with Sun Java. It took 5 years and some nasty battles to finally get M$ to admit their dirty deed...but by that time, it was almost too late as the damage had already been done.

#24 What is XUL? XAML, UIX, XUI, UIML, XIML, AAIML

by geraldb

Tuesday May 27th, 2003 8:26 AM

Reply to this message

> 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 @ <http://lists.sourceforge.…t/lists/listinfo/xul-talk> 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 and so on.

#28 What is XAML? How about a Luxor Rip-Off

by geraldb

Tuesday May 27th, 2003 12:52 PM

Reply to this message

> The articles you link to aren't very clear about what XAML is. > The articles refer to 'XAML scripts' and 'Developers will be able to > manipulate the objects by XAML or C# code'. This suggests its more a scripting > language for UI manipulation, than UI description.

If I dare say XAML will be pretty much like Luxor @ <http://luxor-xul.sourceforge.net>

You might wonna check out my VanX talk slides from last summer titled "Luxor: The "Linux Kernel" for Desktop Apps - Uniting XUL, SVG, HTML, Velocity, Web Start, XSL/T, Python and more" for a XAML sneak preview online @ <http://luxor-xul.sourcefo…vanx-jul-2002/slides.html>

About XML Scripting and UIs you might wonna check out the Jelly teaser in my JUG Austria talk slides titled "Python and Jelly: Scripting Power for Java and XML: Do More With Less (Lines of Code)" online @ <http://luxor-xul.sourcefo…/jug-feb-2003/slides.html>

#29 XUL is NOT UIML, XAML, etc.

by dhyatt

Tuesday May 27th, 2003 5:03 PM

Reply to this message

You seem to be suggesting that any XML-based UI markup language that anyone designs should be called "XUL." I don't think that makes any sense at all. For example, UIML is nothing like XUL.

#33 XUL Has Outgrown Mozilla

by geraldb

Tuesday May 27th, 2003 8:26 PM

Reply to this message

> You seem to be suggesting that any XML-based UI markup language that anyone > designs should be called "XUL."

Not really. You might wonna check out the XUL motor catalog at the Open XUL Alliance to see that it's a careful selection. You're also welcome to join the xul-talk mailing list @ <http://lists.sourceforge.…t/lists/listinfo/xul-talk> to work out an "official" definition if you feel like it.

> I don't think that makes any sense at all.

I dare to disagree. XUL just has outgrown Mozilla. Face it.

> For example, UIML is nothing like XUL

I agree. UIML is worthless and you won't find it listed; so is the Glade XML UI haystack, the Qt Designer XML UI haystack, the Sun Long-Term Persistance XML haystack, and many more.

Just to clearify Glade XML UI in contrast to UIML works great for what it is designed. However, it's not targeted at people like HTML and pretty much unusable with any forms designer.

#30 Interesting

by jedbro

Tuesday May 27th, 2003 5:41 PM

Reply to this message

Cool to see XUL gettinh more mainstream publicity, and being used outside of mozilla.

#34 What is XUL? Round Two

by geraldb

Tuesday May 27th, 2003 8:50 PM

Reply to this message

> It looks like your definition of XUL is "any XML dialect that defines a UI".

Not really. You might wonna check out the XUL motor catalog at the Open XUL Alliance to see that it's a careful selection. I admit some might be bordline cases you can argue over endlessly.

You're also more than welcome to join the xul-talk mailing list @ <http://lists.sourceforge.…t/lists/listinfo/xul-talk> to work out an "official" definition or criteria catalog if you feel like it.

To repost from my last answer, here are some XML UI dialects that I didn't include under the XUL umbrella: UIML is worthless and you won't find it listed; so is the Glade XML UI haystack, the Qt Designer XML UI haystack, the Sun Long-Term Persistence XML haystack, and many more.

Just to clearify the Glade XML UI in contrast to UIML works great for what it's designed. However, it's not targeted at you and me like HTML and, therefore, is pretty much unusable without machinery such as a forms designer.

#37 What is XUL?

by dhyatt

Wednesday May 28th, 2003 1:32 AM

Reply to this message

I guess we just disagree on terminology. When I use the term "XUL", I mean Mozilla XUL. You're using it as an umbrella to describe other vaguely similar (but not interoperable) XML UI implementations. In my opinion that's kind of confusing, but whatever. :)

#39 Growing the Pie Together - XUL Needs To Break Free

by geraldb

Wednesday May 28th, 2003 7:36 AM

Reply to this message

If you're realistic noone will use Mozilla as a platform other than some fanatics. Sure, Mozilla is free and open-source. However, it's still a single-vendor product with lack of competition and its own ecosystem using common standards and much more to make it into an next-gen application platform for a rich internet.

Breaking XUL free from Mozilla will increase competition. Today Mozilla can claim to be the #1 XUL motor on the planet. However, if innovation continues at this rate Mozilla better gets it act together or the new kids take over.

> When I use the term "XUL", I mean Mozilla XUL.

Now, how ego-centric is that?

> You're using it as an umbrella to describe other vaguely similar > (but not interoperable) XML UI implementations. In my opinion that's kind of confusing, but > whatever. :)

As I wrote before it's all just getting started. The first step is to create a new market/new identity and tell all those XML UI motor developers: Look, your ideas and projects are great, but hardly unique. If you want to make it happen you can't expect anyone to use your own ego-centric format you need to open up. Only by growing the market together will you succeed, otherwise you'll end up on the fringe.

So let's get the XUL browser war started and build a rich internet for everyone without the shackles of W3C standards.

#40 Re: Growing the Pie Together - XUL Needs To Break

by jgraham

Wednesday May 28th, 2003 10:43 AM

Reply to this message

>If you're realistic noone will use Mozilla as a platform other than some fanatics. Sure, Mozilla is free and open-source. However, it's still a single-vendor product with lack of competition and its own ecosystem using common standards and much more to make it into an next-gen application platform for a rich internet.

If your realistic, no one will use (.net / Visual Basic / whatever) as a platform other than some fanatics. After all, it's closed source and proprietry - a single vendor product.

>> When I use the term "XUL", I mean Mozilla XUL.

>Now, how ego-centric is that?

Uh not at all? Unless another XUL-like language has exactly the same syntax as (Mozilla) XUL, then giving it the same name would just be confusing. If it's Mozilla-XUL compatiable then XUL is a good name. But trying to call anything that defines any type of user interface in an XML format XUL is just confusing.

> You're using it as an umbrella to describe other vaguely similar (but not interoperable) XML UI implementations. In my opinion that's kind of confusing, but > whatever. :)

> As I wrote before it's all just getting started. The first step is to create a new market/new identity and tell all those XML UI motor developers: Look, your ideas and projects are great, but hardly unique. If you want to make it happen you can't expect anyone to use your own ego-centric format you need to open up. Only by growing the market together will you succeed, otherwise you'll end up on the fringe.

> So let's get the XUL browser war started and build a rich internet for everyone without the shackles of W3C standards.

Well, yes, if you agree on a commonly impelmentable XML UI format then that would be *a good thing*. But, unless the internet landscape changes dramatically, it won't be sutiable for use on the web without IE implementing it. I think the probablity of IE impementing a language for compatibility with a bunch of open source programs is pretty slim.

#42 History 101 - Windows A Bunch Of Device Drivers

by geraldb

Wednesday May 28th, 2003 12:07 PM

Reply to this message

> Well, yes, if you agree on a commonly impelmentable XML UI format then that would be *a good > thing*.

Glad we agree on something.

> But, unless the internet landscape changes dramatically, it won't be sutiable for use > on the web without IE implementing it. I think the probablity of IE impementing a language for > compatibility with a bunch of open source programs is pretty slim.

You might wonna read up on how the web (HTML) got started? Do you remember M$ Blackwidow?

Anyway, Micro Willy and the Yes-Man Brigade haven't yet gotten the point of the internet (or more likely deny it), that is, the OS no longer matters or won't soon. This might sound like a Netscape Atlas replay, but this time its for real.

#45 Re: History 101 - Windows A Bunch Of Device Driver

by jgraham

Wednesday May 28th, 2003 12:21 PM

Reply to this message

>You might wonna read up on how the web (HTML) got started? Do you remember M$ Blackwidow?

No. But in any case times have changed significantly. When the web started, Microsoft didn't own 95% of the browser market. There weren't already tens of millions of people who needed to be convereted from one technology to another. Sadly, that makes a big difference. It's now *impossible* for most people to do anything, especially anything that involves money, on the internet without catering for Internet Explorer users. If Microsoft release some XML UI language then there are probably quite a lot of sites that will use it. But it won't be compatible with XUL, just like all those other slightly-incompatible Microsoft technologies like jscript and MS-Java didn't quite work with other things.

At the moment, XUL has a great future. But that future isn't on web sites. It's on closed networks - for example company intranets where the ability to design real GUIs that work across a wide range of hardware. What Mozilla needs is more people explaining to companies that they don't have to hack together poor html interfaces for their internal web apps when they could be using a more powerful framework that reuses most of their existing html/css/javacsript skills. In that situation, the fact that XUL requires Mozilla (or another XUL like language requires something else) doesn't matter. That can easilly be deployed and will be if there are clear business benefits. The same isn't true on the web at large.

#41 Huh?

by dhyatt

Wednesday May 28th, 2003 11:59 AM

Reply to this message

"The shackles of W3C standards?" Much of the power and flexibility of XUL comes from its integration with the DOM and CSS. There are fundamental pieces of the language (like the command structure and event handling) that rely on the DOM event model to function. The layout primitives are defined in CSS, and standardization of those primitives (like the XUL box model and grid) is actively being worked on in the CSS WG.

To break XUL out of a Web browser implementation is to miss the very point of the original design of XUL, which is to make a UI language that people who write Web pages can use to make UI.

Besides, without implementing a DOM, XBL, CSS, and the chrome registry, your implementation is not going to be interoperable, so what is it that you're shooting for here with your Open XUL Alliance? Tag name consistency? If the implementations aren't interoperable anyway, you're not designing the same language, so who really cares then what tag names you use?

#43 XUL Wants To Be Free

by geraldb

Wednesday May 28th, 2003 12:17 PM

Reply to this message

It looks like the Mozilla folks like all good parents are anxious to let their loved child (that is, XUL) grow up and break free and go its own way.

Sure, noone knows what the future holds and the outside world can be scary but being overprotective won't help anyone, that is, neither XUL nor Mozilla nor the Free World.

#47 Freedom To Innovate

by geraldb

Wednesday May 28th, 2003 12:33 PM

Reply to this message

> "The shackles of W3C standards?"

Don't get me wrong. The W3C's achievements are outstanding.

> To break XUL out of a Web browser implementation is to miss the very point of the original > design of XUL, which is to make a UI language that people who write Web pages can use to make > UI. See, that's were we differ. For XUL to grow up it needs to break free from the browser and, thus, the W3C is the wrong forum for standardization.

My tag line for the coming area that blurs the difference between web pages and classic desktop apps is "Rich Clients, Rich Browsers, Rich Portals".

For more about the W3C I invite you to check out my post titled "History 101 - Nostalgia - The Golden Age Is Over" burried in a MozillaZine thread @ <http://www.mozillazine.or…ticle=3213&message=18> somewhere above.

To quote: 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.

#44 Hey...

by dhyatt

Wednesday May 28th, 2003 12:20 PM

Reply to this message

Hey, if you want to run around making up XML UI languages and calling them XUL, that's fine. A little nuts, but fine. I am completely confused regarding what the goal of your site is and what you actually want Mozilla to do (if anything).

#46 Re: Hey...

by asa <asa@mozilla.org>

Wednesday May 28th, 2003 12:31 PM

Reply to this message

Actually, it's not fine to create new XML UI languages and call them XUL. XUL refers specifically to languages that use the namespace "<http://www.mozilla.org/ke…ekeeper/there.is.only.xul>" and calling other XML UI languages XUL wrong. If you want to create a XML UI language (which is what it sounds to me like you're planning), then you should name it something different.

--Asa

#50 Time To Move On - Time To Drop Namespaces

by geraldb

Wednesday May 28th, 2003 12:53 PM

Reply to this message

> XUL refers specifically to languages that use the namespace.

Why not change the namespace URL from there.is.only.xul to once.there.was.only.mozilla.xul

Just kidding. ;-)

A parting thought: Who needs the useless namespace bloat in core markup? Why not ditch it all together? I'm not kidding.

#52 Re: Time To Move On - Time To Drop Namespaces

by asa <asa@mozilla.org>

Wednesday May 28th, 2003 1:00 PM

Reply to this message

My point is that you're doing a disservice to XUL by naming not-XUL things "XUL" and that's just plain wrong. If you want to creat a new XML based UI language, do it. Great! Have fun. But don't call it XUL. XUL has a specific meaning and calling something which isn't XUL by that name is wrong, just as calling it XAML would be wrong.

--Asa

#63 XUL is the name of a language, like HTML

by jesse <jruderman@hmc.edu>

Wednesday May 28th, 2003 6:32 PM

Reply to this message

> XUL has a specific meaning and calling something which isn't XUL by > that name is wrong, just as calling it XAML would be wrong.

Right, it would be like calling a new language HTML "because it's a hypertext markup language".

#53 Uh...

by dhyatt

Wednesday May 28th, 2003 1:01 PM

Reply to this message

Whenever XUL is intermixed with other content, you have to use namespaces to disambiguate. This commonly occurs in XBL for example, or when XUL is mixed with HTML or SVG.

#65 Re: Time To Move On - Time To Drop Namespaces

by hto

Wednesday May 28th, 2003 7:02 PM

Reply to this message

If you want to mix your XML user interface language elements with arbitrary XML (or vice versa), you will need namespaces.

#48 Freedom To Innovate (Repost)

by geraldb

Wednesday May 28th, 2003 12:41 PM

Reply to this message

Sorry for the repost, but somehow my "Freedom To Innovate" comments didn't end up on the top-level. Here we go:

> "The shackles of W3C standards?"

Don't get me wrong. The W3C's achievements are outstanding.

> To break XUL out of a Web browser implementation is to miss the very point of the original > design of XUL, which is to make a UI language that people who write Web pages can use to make > UI.

See, that's were we differ. For XUL to grow up it needs to break free from the browser and, thus, the W3C is the wrong forum for standardization.

My tag line for the coming area that blurs the difference between web pages and classic desktop apps is "Rich Clients, Rich Browsers, Rich Portals".

For more about the W3C I invite you to check out my post titled "History 101 - Nostalgia - The Golden Age Is Over" burried in a MozillaZine thread @ <http://www.mozillazine.or…ticle=3213&message=18> somewhere above.

To quote: 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.

#54 Re: Freedom To Innovate (Repost)

by Ben_Goodger

Wednesday May 28th, 2003 1:04 PM

Reply to this message

Many of XUL's semantics are tied to the presence of the other components that Dave mentioned - XBL, CSS, etc. While it might be possible to recreate a XUL runtime using native widgets or another layout engine (I assume this is what you mean by "break free from the browser"), to recreate even the current level of XUL compliance would be a mammoth undertaking, and as Dave has pointed out stray from the original intent of XUL/XPToolkit if widgets were implemented in technologies other than XBL, CSS, etc.

Your enthusiasm is great. I don't want to trample on that, just let you know what you're getting yourself into if you really want to create new XUL implementations. Myself, I don't think there's a need for more than one XUL implementation per platform, especially given how well Mozilla XUL/XPToolkit works now on windows and linux. As far as "Mozilla XUL" goes, what we implement will always be defined by our needs and our customers' needs. We won't necessarily be hamstrung by "compatibility" requirements with other runtimes, such as may exist, since at this point we have the most comprehensive runtime.

#49 Threading 101

by AlexBishop <alex@mozillazine.org>

Wednesday May 28th, 2003 12:49 PM

Reply to this message

And next week, MozillaZine will be holding a live Threading 101 workshop, to explain the intricacies of using the 'Reply to this message' links to post a reply to a specific comment, rather than posting a new top-level message.

Alex

#51 W3C

by dhyatt

Wednesday May 28th, 2003 12:56 PM

Reply to this message

"Ask yourself why does the W3C show no interest in XUL (XML UI Language)?"

The point of the W3C is to create frameworks that can then be used by organizations like Mozilla to describe markup languages (like the XUL language). XUL fundamentally breaks down into several pieces:

(1) Layout primitives - These are all defined using CSS and are completely independent of the XUL markup. You can make divs or spans into boxes, grids or popups right now in Mozilla today. These layout primitives are designed to integrate with the rest of the CSS layout primitives. You can't view the new primitives in a vacuum, since you need block and line layout in order to do simple wrapping markup even in XUL dialogs. (2) Widgets - The widgets in Mozilla largely (with a few exceptions) fall out of having the layout primitives + XBL. You could of course map the XUL markup to native widgets or any widgets you want to. (3) XUL Templates - For dynamic building of markup from back-end data. (4) Infrastructure - Commands, keys, etc. The rest of the markup.

The point of W3C technologies like CSS, DOM, XSLT, etc. is to create a framework that enables you to define your own markup languages. Most of the XUL implementation is independent of the markup used to describe it. This behavior, therefore, is outside the province of any one particular markup language design.

How the XUL box model should behave is therefore a question best decided by the CSS WG, since you have to consider its integration with the rest of CSS, e.g., how does it work with overflow, z-index, when a child of a block, with min and max width, etc. etc.

#55 Threading 201

by dhyatt

Wednesday May 28th, 2003 1:16 PM

Reply to this message

Threading 201: When you can't actually view all the threads in a single Web page, the threading becomes pointless, and it's easier to just post at the top level. ;)

#57 Re: Threading 201

by AlexBishop <alex@mozillazine.org>

Wednesday May 28th, 2003 1:31 PM

Reply to this message

"Threading 201: When you can't actually view all the threads in a single Web page, the threading becomes pointless, and it's easier to just post at the top level. ;)"

And we really thought no-one used flat mode when it was decided to remove it...

Alex

#66 Re: Re: Threading 201

by WeSaySo

Wednesday May 28th, 2003 7:13 PM

Reply to this message

"And we really thought no-one used flat mode when it was decided to remove it.."

Better than flat mode is nested mode. This way thread depths are preserved while still showing all the text. Flat mode was just chronological from what I remember.

#56 Show Me The Widgets

by geraldb

Wednesday May 28th, 2003 1:28 PM

Reply to this message

That's all lovely. However, I don't see any tags for a rich widget set upcoming from the W3C and you state in your last post:

> The widgets in Mozilla largely (with a few exceptions) fall out of having the layout > primitives + XBL.

Sure, some dream of using SVG markup to create widgets, but isn't this a replay of the DOM/Javascript kludge used today?

Why not come up with tags for a rich widget set that lets you pick a back-end (XUL browser, Javascript/DOM library, SVG, or whatever)?

If you want to create a toolbar why not use simply a <toolbar> tag? If you want to create a menu why not use simply a <menu> tag? If you want to create a data grid why not use simply a <datagrid> tag? If you want to create a tree why not use simply a <tree> tag? I hope you see the pattern. Here are some more tags to go on: <wizard>, <tabbox>, <stack>, <deck>, <dialog>, <groupbox>, <browser>, <editor>, <popup> and so on.

#58 Re: Show Me The Widgets

by dhyatt

Wednesday May 28th, 2003 2:01 PM

Reply to this message

The XUL language itself (namely the tag names and the DOM APIs defined using XBL for the various widgets) is under the control of Mozilla. Although we would like to standardize (through the W3C) the layout primitives (and also XBL), we have no plans to standardize the tagset or syntax through an external organization like the W3C.

Nor do we have any plans to allow others to try to force changes on us that might be incompatible with our design goals, e.g., we're not going to open up the language to a design-by-committee approach where tag names end up changing just because someone prefers a different word for <wizard>. At this point, we also have no plans to make changes that would break backwards compatibility with previous versions of XUL.

If you'd like to have a say in the design of the XUL language, you're free to make proposals in the appropriate Mozilla newsgroups, but the ultimate control over the XUL tagset and language design rests with Mozilla.

#59 What a Twist - The Truth is Out

by geraldb

Wednesday May 28th, 2003 3:04 PM

Reply to this message

> we have no plans to standardize the tagset or syntax through an external organization > like the W3C.

Taking offence when I wrote "The shackles of W3C standards" and now your outing as a control freak. What a twist.

#61 Re: What a Twist - The Truth is Out

by Ben_Goodger

Wednesday May 28th, 2003 4:20 PM

Reply to this message

Hi. Maybe you're new to Mozilla. People that have cvs access and who own modules (like dave) can "control" what's going on. That doesn't make him a "control freak" that makes him a "responsible module owner."

#60 Ok...

by dhyatt

Wednesday May 28th, 2003 3:29 PM

Reply to this message

I took no offense when you wrote about "the shackles of W3C standards." I merely pointed out that XUL is very much tied to those selfsame standards, and that to develop a language that is not dependent on having a DOM or on styling using CSS (e.g., for padding and margins) is to create a new markup language all together. It may be very similar to XUL, but it wouldn't *be* XUL.

I respectfully request that you stop using the term XUL, which is used to describe a very specific XML markup language with a specific namespace, to describe other implementations of XML user interfaces. You are simply creating confusion with this co-opting of the XUL acronym.

#62 Let's Cool Off

by geraldb

Wednesday May 28th, 2003 4:31 PM

Reply to this message

I suggest to cool off and revist the XUL naming debate in a week or two. In the meantime let others voice their opinions. Please don't be shy.

#64 Let the people speak. Let's have a poll.

by geraldb

Wednesday May 28th, 2003 6:59 PM

Reply to this message

Why not put up a poll on Mozillazine and let the people vote? Please be fair and don't use any leading questions.

#67 Re: Let the people speak. Let's have a poll.

by Ben_Goodger

Wednesday May 28th, 2003 8:35 PM

Reply to this message

Because this isn't a democracy?

#68 Look...

by dhyatt

Wednesday May 28th, 2003 8:38 PM

Reply to this message

The issue here is that you are infringing on the name XUL. While I have no problem with names like "jXUL" for languages that are specifically designed to mimic the design of the original XUL, trying to lump completely unrelated XML UI languages under the term "XUL" is misleading. For example, your posts claiming that Longhorn is shipping with a "XUL motor" are absolutely ludicrous.

It's important that you understand that XUL is a specific language, and not some generic umbrella that should be used to describe all XML UI languages. If you misuse it, you are infringing on Mozilla's invention and our use of this specific acronym.

I will repeat the request that you cease and desist your use of XUL as a generic term to describe other XML-based UIs. Why not just replace your uses of the acronym XUL on your site with "XML UI." Then you are speaking generically and not making use of the specific acronym invented by Mozilla.

#69 Look... How about Zool

by geraldb

Wednesday May 28th, 2003 8:52 PM

Reply to this message

If want to brand Mozilla XUL why not use a "real" brand name lets say "Zool". If find claiming ownership over the XML UI Language (XUL) acronym ludicrous. Please grow up.

#70 Re: Look... How about Zool

by choess <choess@stwing.upenn.edu>

Wednesday May 28th, 2003 9:15 PM

Reply to this message

Why would that be ridiculous? FTP, gopher, email, and so forth, can all be considered, in some sense "HyperText Transfer Protocols", but if you suddenly insisted on referring to them as "HTTP" and spouting market-speak about how the IETF needed to "let go", you'd probably meet the same sort of reception you've been getting here.

I also find it interesting that despite the fact that any number of people have invented XML-based UI-descriptive languages, no one has raised any trouble about our use of "XUL" before, perhaps because they weren't engaged in half-baked schemes to put them all under one umbrella.

#71 Re: Look... How about Zool

by dhyatt

Wednesday May 28th, 2003 11:08 PM

Reply to this message

If it's an acronym you need to describe all XML UI languages, why don't you use XUIL as a generic identifier then, since it is actually an acronym for "XML UI Language" and isn't currently used to identify a specific markup language?

This isn't about control or about restricting your ability to create XML UI languages. Create away. The problem is that you are genuinely confusing people by co-opting XUL as a generic term.

#72 Who are you?

by Ben_Goodger

Wednesday May 28th, 2003 11:22 PM

Reply to this message

I'm going to post out of thread here in the hopes that my posts will actually be read.

geraldb wrote:

"If want to brand Mozilla XUL why not use a "real" brand name lets say "Zool". If find claiming ownership over the XML UI Language (XUL) acronym ludicrous. Please grow up."

Mozilla is a meritocracy. I've never heard of you before. I think you'll find your views are taken more seriously when you have some contributions under your belt and you're not just running around barking orders and calling people names.

#76 Hello, My Name Is Gerald

by geraldb

Thursday May 29th, 2003 7:09 AM

Reply to this message

> I've never heard of you before.

Don't worry. I've never heard of you before either. If you want to find out more about myself check out my VanX talk slides from last summer titled "Luxor: The "Linux Kernel" for Desktop Apps Uniting XUL, SVG, HTML, Velocity, Web Start, XSL/T, Python and more" online @ <http://luxor-xul.sourcefo…vanx-jul-2002/slides.html>

#77 Re: Hello, My Name Is Gerald

by james

Thursday May 29th, 2003 7:34 AM

Reply to this message

Ben is one of the people listed as an author of the XUL 1.0 specification: <http://www.mozilla.org/projects/xul/xul.html> (as are some of the other people you have pissed off).

#83 What the heck?

by jedbro

Thursday May 29th, 2003 1:07 PM

Reply to this message

What the heck is wrong with you? Gerald, I do understand your point, but you are also wrong. You seem to not know what namspaces are for, and not being able to respect the creation of others. If you generically call anything you want XUL, that is damaging to all of us and couter productive.

Please don't piss off the XUL CREATORS!!! It's not fun when someone goes around and starts fucking with what you took allot of time to make. Like Hyatt said, call it XUIL or something similat GXUL, but unless it IS XUL then don't call it that. (Because my tangerine may look like an Orange, it's still a tangerine)

#73 How About Calling XUL.....

by TheBashar

Thursday May 29th, 2003 12:02 AM

Reply to this message

FireBirdXUL. I bet Asa would love writing up that announcement!

#74 DOS, DVD, VCR, RAM

by geraldb

Thursday May 29th, 2003 6:39 AM

Reply to this message

Before you wipe yourself in a frenzy over an acronym. Check out these and get real.

DOS - Disk Operating System: MS DOS, DR DOS, IBM DOS etc. DVD - Digital Versatile Disc: Sony DVD, Maxell DVD, Philips DVD, etc. VCR - Video Cassette Recorder RAM - Random Access Memory

#75 Re: DOS, DVD, VCR, RAM

by Galik

Thursday May 29th, 2003 7:04 AM

Reply to this message

XUIML - E(x)tensible (U)ser (I)nterface (M)arkup (L)anguage XUL XUIML. Que problem?

#79 Re: DOS, DVD, VCR, RAM

by jgraham

Thursday May 29th, 2003 9:20 AM

Reply to this message

What's the point? Those are all acronyms. So what? All the DOS's are similar but incompatiable enough that it is necessary to prefix them with a manufacturer name. All the DVDs are compatiable, so they just get referred to as DVD's rather than SonyDVD mDVD or whatever. All (VHS) VCRs are compatiable so we use a single acronym VCR (and call incompatiable things something else like LaserDisc or PVR). Different types of RAM are incompatiable and so have to be specified exactly EDO RAM, SD RAM, etc.

Conclusion: If things are similar but incompatiable, it is necessary to give them different names. Collary: Sometimes similar things have names which share a common section even when they are incompatiable (all the DOS's share DOS). So it might be possible for all XML languages designed for user interfaces to share a common 'base' acronym. This is no means necessary though (Docbook and HTML do slightly similar things, but they don't need a similar name) and nothing suggests that any base acronym should be XUL.

My turn:

Using the same term for a range of different products is liable to produce confusion among people wishing to use the product, therefore doing so produces no conceviable benefit for proponenets of the product. Discuss.

#80 Why pick on me? Check out Nexaweb

by geraldb

Thursday May 29th, 2003 9:45 AM

Reply to this message

I quote from the website online @ <http://www.nexaweb.com/features.htm> : Nexaweb is the only standards-based smart client platform on the market today. User interface instructions are based on XUL (pronounced "zool"), which is a standard championed by Sun, Netscape and Nexaweb. Any thoughts?

Or this news byte: Nexaweb Secures $4.3 Million in Funding for Breakthrough Software Platform. Now if you want to sue somebody like SCO now you know where to go.

#81 Re: Why pick on me? Check out Nexaweb

by GAThrawn

Thursday May 29th, 2003 11:04 AM

Reply to this message

>I quote from the website online @ (LINK) : Nexaweb is the only standards-based smart client platform on the market today. User interface instructions are based on XUL (pronounced "zool"), which is a standard championed by Sun, Netscape and Nexaweb. Any thoughts?

And the important phrase there is: "[Nexaweb]'s User interface instructions are based on XUL"

They are calling their product Nexaweb, and saying its similar to XUL, there's nothing wrong with that. Now if they said that their XML UI language *is* XUL even when its incompatible but similar, then that would be an issue.

#82 What is "is"?

by geraldb

Thursday May 29th, 2003 12:52 PM

Reply to this message

That's clintonesque. Please don't split hairs.

#84 Re: What is "is"?

by jgraham

Thursday May 29th, 2003 1:16 PM

Reply to this message

It's very simple. If it is compatible with the XUL 1.0 specifcation then it is XUL. If it is incompatible with that spec. it's not XUL, any more than it is Xforms or HTML, even if some of the tags look the same, and it has a similar purpose. In fact, it's particuarly not XUL if it almost but not quite does the same thing. Calling different things by the same name doesn't benefit anyone. Clear?

#85 Re: What is "is"?

by Ben_Goodger

Thursday May 29th, 2003 3:16 PM

Reply to this message

Why not, because he's right, and you're wrong?

#86 XUL Moves On

by geraldb

Friday May 30th, 2003 8:13 AM

Reply to this message

I guess the latest news about the Timer Warner and Microsoft deal proofs the point that "branding" XUL as a Mozilla-only technology is a dead-end.

#87 Re: XUL Moves On

by kerz <jason@mozillazine.org>

Sunday June 1st, 2003 1:04 AM

Reply to this message

Uh, no, XUL has nothing to do with "Timer Warner" but thanks for playing.

#88 The Munich Revolution - 14.000 Linux Desktops

by geraldb

Sunday June 1st, 2003 12:08 PM

Reply to this message

Here is slightly off-topic post to help you get the story together and why XUL is so important.

As I see it the browser war is over and now the desktop war is on. Just recently, for example, the Munich city council decided to move 14.000 desktops from Windows to Linux, see the write-up off the story in CNET @ <http://news.com.com/2100-…_3-1010740.html?tag=cd_mh>

So where does XUL come into the picture? HTML is the markup for browsers and XUL is the markup for desktops.

Unfortunately, the W3C leadership doesn't get it. To quote from Tim Bray's weblog:

<quote>The Browser Still Matters. Finally, there was a thread that said that the notion of running everything through the browser was broken anyhow, and what we really needed was something like WinForms, that would give the developer fine layout controls and richer UI apparatus like they used to have back in the days of Visual Basic.

This is another example of people Not Getting It. Why do you think the users turned away from VB to the browser? Because they by and large didnít like what the VB programmers of the world did with those fine layout controls and rich UI apparatus. I can remember like yesterday a Content Management conference about 1997, a woman from a big computer company talking about how great it was when they switched their CM system over from custom clients to the browser: ďItís so great! The browser is so limited, so they had to throw away three-quarters of the buttons and sliders and pulldowns and options, and just do it with hyperlinks and simple forms... it was so much easier to use!Ē

For heavy authoring and graphics and so on, you need a native application. But a huge majority of business data processing is you interacting with a database off on a server somewhere, and as far as I can see, a Web Browser is still the best way to do that. WinForms? Pshaw! </quote>

Heard about XUL, Tim? I guess not too busy with the semantic web and RDF. Welcome to the XUL revolution.