- From: Danny Ayers <danny666@virgilio.it>
- Date: Thu, 16 May 2002 23:36:06 +0200
- To: "Jukka Korpela" <jukka.korpela@tieke.fi>, "W3c_Access" <w3c-wai-ig@w3.org>
>In a sense, all markup is metadata, data about data. But I don't think this >view is particularly useful. What we normally call metadata in the WWW >context is data about such data that consists of entire documents like an >HTML document and associated images etc., i.e. "Web pages". Agreed, markup is essentially metadata, and IMO acknowledging this can be very useful. (Who is this 'we', BTW?) A lot of people are seeing the value of finer-grained explicit metadata (e.g. the use of the <metadata> element in SVG), or even the use of metadata describing completely arbitrary resources (e.g. RDF). >> Another way may be to use named >> classes, like "tophead" in your example, though of course it >> would be better if they came from well-known vocabularies - class="h1" >> perhaps? > >No, class="h1" does not mean anything more (to a browser) than class="foo". Depends on the browser - ok, there aren't any browsers I know of that would understand this, but I was making the point that use of common vocabularies could be referenced in other ways than by using HTML 3.2 syntax. >The class name is just an assigned symbol with no intrinsic meaning. Things >might change if we defined some specific rules for class names, with >semantic definitions (e.g., "h1" means 'first level heading') and published >them and got wide acceptance. Then we would have reinvented the wheel, >wouldn't we? It would be just like HTML, except more clumsy. My point exactly (apart from the clumsiness bit). >> Hopefully - - we won't need to rely on a vocabulary of maybe >> two dozen terms plus fairly arbitrary nesting rules to explain >> our document's structure > >It was one of the basic weaknesses of HTML as originally defined >that it had >only a handful of markup elements you can use. But it was also one of its >fundamental strengths. The smaller the set of markup elements that >a program >_must_ recognize and process in some particular way, the easier it is to >write programs that process marked-up data, for visible or audible >presentation or for other purposes. (Actually, a qualified programmer could >write a browser for HTML 2.0 in an hour, a _different_ browser >that has some >special treatment for markup like headings, to suit the properties of some >new device, or the needs of some particular people.) Ok, I've got 6 'O' levels, and could probably hack together a browser in an hour, with special handling of some form or other. I think it would be a waste of an hour though - the strengths of HTML (and HTTP) that got the web going aren't necessarily the same ones that will keep it going (and developing). And the ease of >creating "different" user agents is essential to accessibility. Yes, I just think it's better to use a little analysis rather than falling back on legacy principles. Cheers, Danny.
Received on Thursday, 16 May 2002 17:42:14 UTC