Modularization
The second benefit is to make HTML more modular. Currently HTML is one big markup language: you cannot add to it and you cannot take away from it! It's the "one size fits all" markup language but, increasingly, it does not fit.
A number of groups need a simplified version of HTML. One such group is the Open eBook Authoring Group (http://www.openebook.org) which developed a, coincidentally XML-based, subset of HTML. This new subset is the basis for electronic books.
Why do they need a subset? Why not go for the real thing? Because eBook readers are built around cheap processors so they are not powerful enough for the full complexity of HTML.
Another group is the WAP Forum (http://www.wapforum.org) which develops standards for mobile phones. Mobile phones are also built around small, cheap components that could not process a complex language like HTML. So the WAP forum had to develop its own simplified markup language.
Yet while some groups simplify HTML, other groups want to add more options to it! Some areas of HTML are very primitive. Take forms, for example. HTML forms are very limited when compared to Java forms. Web-based applications would benefit from a more modern forms that support advanced widgets. For a good discussion on what HTML forms lack, visit http://www.mozquito.org/ and follow the links to XHTML-FML.
What it amounts to is that HTML is torn apart by two groups: one group wants to simplify HTML and the other wants to enhance it. The W3C answer is to modularize HTML: to break it into smaller pieces.
Ultimately there will be a text module (paragraph, bold), an image module, a form module, an object module (applet, plugin, ActiveX), a scripting module (JavaScript, EcmaScript), a frame module, etc.
Browsers will pick and choose according to their audience. For example, eBooks needs only the text and image modules. Intranet applications needs objects, scripts and forms. A palmtop browser needs text and scripts.