[whatwg] Web Applications Markup Language 1.0 is an XUIL?

Matthew Raymond mattraymond at earthlink.net
Tue Aug 3 08:04:52 PDT 2004


    I've noticed that Web Apps 1.0 has recently changed its name to Web 
Applications Markup Language 1.0 (WAML1). Considering the contents of 
section "1.1. Requirements and ideas", it would appear to be a partial 
XML User Interface Language (XUIL), with perhaps the exception that it's 
technically SGML or tag soup when used in conjunction with HTML.

    If WAML1 is indeed an XUIL, this raises a number of questions:

1) Will WAML1 be a part of "HTML5", or is it an independent technology 
that can be used as a subset of "HTML5" in much the same way that XForms 
is used by XHTML 2.0?

2) While WAML1 elements require a namespace? If so, how will this be 
handled in HTML user agents that don't support namespaces?

3) Will "graceful degradation" be possible with WAML1 elements?

4) Will WAML1 borrow heavily from existing web-based XUILs, such as XUL 
1.0, or will it be a complete reinvention? If the latter, wouldn't that 
slow down development and adoption of WAML1? If the former, wouldn't 
that make WAML1 largely a subset of an existing XUIL, similar to my old 
XUL Basic/"Keymaster" concept?

    What I would prefer to happen is something similar to what's 
happening with sXBL/XBL2, where fundamental XUL 1.0 markup would be 
tweaked and standardized in the form of WAML1 (a sort of an "sXUL", if 
you will, although the acronym is wildly inaccurate), then a broader XUL 
2.0 standard be developed later under a standards organization like W3C.

    I'm not saying this is the best solution, and I'm open to other 
suggestions, but right now I think that the above track is the only one 
we have time for. Microsoft's Longhorn is going into beta at the 
beginning of next year, and if there isn't an effective standard for web 
  application UI by the time Longhorn hits the shelves, then this is all 
for naught. HTML based widgets are fine, but if they lack the basic 
functionality that exists in most native applications, developers will 
eventually look elsewhere.



More information about the whatwg mailing list