- From: Larry Masinter <masinter@adobe.com>
- Date: Mon, 18 Jul 2011 01:10:52 -0700
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: "www-tag@w3.org" <www-tag@w3.org>
I think you're saying it's hard to estimate deployment costs, and give some examples, e.g., where naïve calculations based on number of pages gives a different answer than calculations based on number of retrieval. However, many people seem to want to make arguments based on deployment cost and backward compatibility with existing content. And I don't think the points you raise invalidate the need for real data. It's either possible to make those kinds of arguments or it isn't. > My impression is that you would like to know whether there are things > left that could be done to make "HTML" and "XHTML" more similar No. I have no particular interest in making 'HTML' and 'XHTML' "more similar". "more similar" is not generally a way of getting "compatibility" or "interoperability". What I'm interested in is compatibility and interoperability. Larry -- http://larry.masinter.net -----Original Message----- From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] Sent: Sunday, July 17, 2011 2:54 PM To: Larry Masinter Cc: www-tag@w3.org Subject: Re: Revised HTML/XML Task Force Report * Larry Masinter wrote: >But the polyglot specification referenced above does not address the questions I asked: > >* How common are HTML documents that cannot be reasonably represented in XML? That's not a very meaningful question. Suppose there were only two web pages, one is visited by one person once a year, the other is visited by one billion people every day. Or suppose there was a million pages, one handcrafted, and 999 999 automatically derived from a template. If you associate some property with one group but not the other, how would you determine how "common" documents with that property are, and how is knowing that useful? If you made a proxy server that transforms text/html responses by using a "HTML5 parser" and a "XHTML5 serializer" into application/xhtml+xml before they hit your fully "HTML5 compliant" client, then you'd probably encounter web sites that do not work properly on a daily of not hourly basis (read fully compliant as meeting all must- and should-level re- quirements and then optimizing for compatibility with this setup). One issue is that, last I heard, document.write is not supposed to work with application/xhtml+xml under the "HTML5" requirements (the reasoning is likely that it could be made to work for some content, but it's ugly and needs a lot of work with little utility). There are other issues. >* What kinds of practical difficulties would arise for those documents >(and how serious are those difficulties)? Any number of "doesn't work properly" issues would arise. It should be easy to implement the setup I mentioned above to find out if you get a couple of volunteers to do their daily browsing through such a proxy. It's not feasible to answer this in some automated manner with any kind of clarity in numbers (halting problem, too many possibilities to inter- act with web sites, hard to automate, plus the problem I mentioned at the beginning of this message). My impression is that you would like to know whether there are things left that could be done to make "HTML" and "XHTML" more similar, or you would like to have some evidence that most of what could reasonably be done, has been done (you might also like to understand all the indivi- dual points; I don't think you would get that without a lot of research on your own part, as there is a lot of bias surrounding these issues). I do not think there is much in that regard where you could make a con- vincing argument for change, so in that sense we are "fine" to some ex- tent. We would be better off if "we" had fixed issues surrounding XHTML when they were raised, when there was interest in and innertia around it. As it is, browsers and other applications that do not support XHTML are dying. If you have an interest in XHTML then make sure they actually will be gone soon. We can then re-discover XHTML at some point and fix issues as people with actual interest in using it encounter them. As it is, I've not seen so much as an attempt at running new implementations through any kind of test suite to check for common bugs or whatever... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Monday, 18 July 2011 08:11:25 UTC