Working on a trip to New Delhi, hoping to meet some potential W3C Members who can contribute a lot to our specifications and to the World Wide Web.
The article I posted here on Advogato about the future of XML (go look at the front page) has attracted a lot of interest on the xml-dev mailing list and elsewhere. Some people feel XML should never ever be changed, that the Specification is a Holy and Sacred Text. Some feel that the specification could be changed as long as no line of code had to be changed and no documents were affected. Some are concerned mostly with interoperability, and are OK with some code changes as long as no documents are affected. Some are willing to change documents but not code. And some are willing to change both, but only beneath the SAX or DOM level. There has even been talk of sacrificing children, something not currently mandated by any W3C specification. (nor, as far as I am aware, by any specification from IEEE, IETF, Oasys, ISO, ICE, not any other organisation or consortium in the computer industry. )
It's nice to see that people are listening, though, and expressing opinions. How else can we learn how people feel?
*
xach, maybe W3C should define Assembly Language for the Web, with no curly braces. Maybe there could be an arbitrary number of registers each defined by a URI. Text hadling in assembly tends to be hard, but hey, real programmers don't use library functions! :-)
pjrm, you might like to look at the XSL-FO specification as a way of formatting arbitrary XML content. If you do come up with new table layouts, the XSL Working Group may be interested to hear about them -- but note that there's been a lot of research on table layouts over the past five hundred or so years, so although there's certainly the possibility of innovation, it helps your case if you study what has gone before. I can give you some references, although for computer algorithms I'm afraid that most of the work has been propietary.
You mention minimising wasted space, so I should note that an experienced graphic designer will often increase spacing in tables to improve readability. One of the guiding principles is to have related items clearly aligned one with the other, of course.
I wouldn't hold out too much hope of getting changes into HTML at this point, but if you (or your organisation) wants to join W3C and participate in the HTML or CSS Working group, I can give you the necessary information, of course.
mirwin, I'm very pleased that you like the pictures from old books. Interestingly, I note that quite a few people visit the page when I mention it in Advogato, but look only at that single Web page, and hence don't get to see the pictures. I should redesign the page. But I digress. For those pictures that are marked on their corresponding HTML pages as being in the public domain, you can do anything you like with them as long as it's in accordance with the usage guidelines on my page. For the others, I have sent you email.
dfenwick, I recently tried running textedit (it comes with the xview-clients package). It starts masssively faster than gedit on my system. It has some features that seem weird at first (e.g. the ability to surround the selection with |> and <|, a feature used by Sun's calendar manager) but it has drag and drop, and from a user perspective the Sun OpenWindows desktop was probably slightly more integrated than Gnome.
So why the huge slowdown? Partly the number of shared libraries I expect, and partly the use of more layers. Is the code easier to maintain? That's not clear to me; having been inside both XView and Gtk+, the glue is more visible in XView, and it's not so clean, but then it's more than ten years older. Gedit has syntax highlighting I think (I've never seen it) but as a notepad replacement it actually seems less useful than textedit, which can easily reformat a paragraph or insert the output of a command.
The difference might be in the focus of the development team. The open source community tends to have a hard time in thinking of people trying to get every-day tasks done, rather than programmers using their code. The Gnome project has made huge and fabulous advances here, and the Gnome human interface guidlines have also helped dramatically, so we are definitely seeing improvements. Bt it's a pain that a 600MHz pentium system should feel even slightly sluggish.