- From: <olafBuddenhagen@web.de>
- Date: Sat, 3 Apr 2004 14:19:05 +0200
- To: www-html@w3.org
Hi, On Fri, Apr 02, 2004 at 05:19:34PM -0500, Orion Adrian wrote: > I think though there is a semantic difference between code (e.g. C, > C++, HTML, Java) and a code (e.g. %20, $abc). Sure -- as you have observed below, semantics is always a continuum. However, the differences between various kind of code are very small comparable to the difference between code (in the broad sense I use) and natural language. The distinction between natural language and computer strings (whether code in the classical meaning, or other kinds of symbolic data) is important (the line breaking being only one of relevant differences), while the subtle differences between unnumerable kinds of code are really neglectable and ouf of the scope of a generic language like XHTML. > One should allow normal breaking rules and one shouldn't. Sorry, I hope I misunderstand this statement. You do not really want to apply normal line breaking rules to programming languages, do you?... > This is an English problem mostly in that one person sees code meaning > one thing and another sees code meaning something else. This is one > area the W3C could do much better in (i.e. defining the exact meaning > of each semantic markup). Exactly. That's why I proposed a (useful) definition for <code>. > Here's the greater problem... there are so many semantic cases in the > real world that anyone trying to accomplish a general-purpose semantic > markup is going to have to choose along a continuum of choices. On > one end you have giving up entirely and just encoding presentation and > on the other end you have semantic markup for everything. Yes. But between those extremes, there is no straight line of possible compromises. Instead, there is a variety of possibilities of very unequal qualities. Some are really bad compromises, which do not really help either goal. Others are quite good in allowing useful semantical markup in many cases, while at the same time not getting too specific. <code> with the broad meaning I suggested, definitely belongs to the second group. > I've found that the HTML Working Group so far has decided to go > somewhere in the middle. Markup like sub, sup, hr, nobr are > presentation classes because going along and making up semantic cases > for all the nitty gritty little cases is too big a task for this > working group. Actually, both <sub>/<sup> and <hr> are very controversial cases, where no real consensus has been achieved yet. Maybe it's time to return to these... At least for <hr>, I have found some very strong conclusions. > So my point is that if you desire total purity look to these other > cases as well. Concentrating all our effort on nobr without looking at > the whole problem is just wasting everybody's time in my opinion. > There is a much bigger problem at hand here, let's not concentrate on > the minutia. The task of designing a really good semantical language is too complicated for a top-down approach. It's simply too complex, the implications are far too many for anyone to come up with useful ideas this way. Observing past discussions, one can see that often discussions started on some minutia, have opend up much more fundamental issues. See how the discussion on the <nobr> element has evolved: Starting from that point, I've developed a useful definiton for <code>, and by the way solved the Programming Collection dilemma. (At least I believe so...) Another example was how the discussion on some specific element (I don't remember which) led to fundamental questioning of the block/inline distinction. (I'll restart the debate as soon as I have catched up with my mail...) While the first drafts of XHTML 2 mostly concentrate on details, and over all look quite similar to older HTML versions, some discussions (especially during the past few months) indicate that the final version might be very much different. With fundamental changes, that came up in discussing minutia. -antrik-
Received on Saturday, 3 April 2004 10:01:02 UTC