- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Thu, 12 Oct 2006 13:39:11 +0100
- To: w3c-wai-ig@w3.org
Hi Charles, Interesting comments. > Well, it is the idea behind the recently announced "ARIA" work from WAI. > UBAccess and IBM were both working on this last century (probably along > with others), which might be why they are leading the work today. And yes, > it is an exciting idea, and it is heavily based in RDF. The WAI work leverages just one of the many hooks that have been placed into XHTML 2 to allow richer metadata to be added. Some of these features are being made available as XHTML Modularisation modules so that they can be used with langauges based on XHTML 1.1. In this particular case, the 'hook' WAI is using is the @role attribute, but there are many other features in the RDFa toolkit that can be used for exactly the things you are describing. > > The statement "...<div class="paragraph"> does not equal <p>..." still > > stands! > > Strongly agreed. This is a very interesting point. I think the key thing here is to differentiate between the semantics associated with the *purpose* of some mark-up in terms of the document structure (footer, header, main menu, etc.) and the semantics associated with the *content* of the document. The RDFa extensions for XHTML 2 (which as I said, are now being made available for XHTML 1.1) allow both of these areas to be addressed. The 'purpose' aspect is addressed by the already mentioned role attribute. Obviously we're not saying that every element becomes a div with a @role: <div role="paragraph"> ... </div> But equally, we can't say that every time you need a new feature like headers and footers you have to wait for the W3C to update the HTML family of standards. The balance is therefore struck by having a core langauge that provides as full a list of elements as possible to describe the structure of a document (section, h1, h2, div, p, and so on), and then to provide an additional mechanism to add other 'elements' as needed. This is achieved by @role, which allows you to do things like this: <ul role="menu"> <li><a href="...">Home</a></li> <li><a href="...">...</a></li> <li><a href="...">About</a></li> </ul> Now assistive technologies can find their way around the document, based on semantics about the *structure*. When it comes to the 'content' aspect though, things are not so easy; having mark-up in the language that blurs the distinction between the meaning of the content and its structure (like <address>), has never really been successful, and tends to confuse. In this context the approach taken in XHTML 2 is not to add more elements, but to leverage the use of <meta>, <link>, @class, @rel and @rev, to provide a systematic and coherent way to add *any* metadata to an XHTML document. > There is a potential problem with microformats. While they are a simple > "poor man's semantic web" that anyone can do, they end up keeping you > poor. There is no decentralisation process, no formal schema, that can a > priori disambiguate the use of "date" ('things given', in italian) from > "date" (the boy or girl we are proposing you go meet). If we assume that > everyone will make the same use of a free text naming scheme, 2500 years > of experience suggests we should look more carefully at what we have in > our pipe and think again. Even with the (in my opinion naive to the point > of incredibly stupid) assumption that people will always use english in > the value space. > > The greater their success, the more they may doom us to moving on from > HTML as we love it, unless there is a strict use of the profile attribute > (or analgous mechanism) to clearly disambiguate and allow validation and > an out-of-band but automatically processable formal definition of the > grammar and semantics of a given microformat (or a total centralisation of > the allowable values of the class attribute) - just the sort of thing that > simple stuff like microformats starts out trying to avoid. Making the > decision whether we have gone below the threshold of "as simple as > possible *but no simpler*" is never easy, but it is not clear to me that > microformats gets it quite right enough. > > Still. The above involves a bit of crystal-ball gazing, and could well > turn out to be incorrect, since human history and logic are only sometime > bedfellows, and since there are always assumptions that may prove to have > been ill-founded. You are absolutely spot on! The issues you raise are very real: * Microformats gets into real trouble when you try to combine more than one 'format' (in fact, rules of combination have to be defined); * it requires converting already existing langauges so that they work within the microformat rules--painful and slow, given that langauges like FoaF have already had an enormous amount of work put into them, and this must be almost completely repeated; * there is no notion of namespacing; * adding new languages seems to be based on a few key individuals; * there is no way to validate; * and it isn't actually a "poor man's semantic web", since it isn't providing a generic mechanism, but a way of hand-crafting a small number of use-cases--which means that format-specific process still have to be created to work out what some mark-up means. RDFa tackles all of these issues by providing a series of *general* rules that can be applied to any metadata, rather than the specific rules for specific formats. It also allows QNames to be used if required, to resolve the namespacing issue that you flagged up. Of course it's not an either/or situation, and microformats will continue to find plenty of uses. But for a solution that can: * be written as simply as microformats; * scale to any level of complexity; * make use of any RDF taxonomy; * operates at the level of document *structure* semantics, as well as and document *content* semantics RDFa definitely has more 'legs'. Regards, Mark -- Mark Birbeck CEO x-port.net Ltd. e: Mark.Birbeck@x-port.net t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/
Received on Thursday, 12 October 2006 12:39:25 UTC