2009/8/16 Ian Hickson <i...@hixie.ch>: >> In practise I think this means a strict interpretation mechanism is >> desirable at the statement level, but with ignore-if-fail, so the >> information communicated by documents (and their embedded data) can be >> maximally conveyed. I reckon this is generally consistent with the rest >> of HTML5 design. >> >> Thing is, I'm not sure the microdata spec in its current form can >> support this, while the RDFa approach almost certainly can. Remember >> looser interpretation should be (and in both cases is) possible further >> down the chain, depending on the client application. > > I don't see any material difference between RDFa and Microdata that would > make one or the other more able to support what you describe,
Right, I missed a lot of the URI- (and hence RDF-) friendliness of Microdata in my initial reading of the spec (set right by your pointers via twitter, thanks). other than > Microdata's self-contained nature (not using prefixes) making Microdata > somewhat less susceptible to accidental changes in meaning. I must admit to a bias towards prefixes in general, as in most circumstances I've seen it's the neatest route to URI-based extensibility. But, (in particular noting Bengee's remarks about easy manipulation of quasi-RDF via the DOM), there are clearly other factors to consider when it comes to HTML. Similarly, speaking personally, having a sizeable built-in vocabulary produces a knee-jerk reaction from me - it looks like terribly clunky design, compared to minimal core + extensions. But I am conflicted on this point, since it can certainly help in the two typical circumstances where (<head>less) doc fragments are passed around, copy & paste and bloglike additions to a doc. (If HTML5 was starting from scratch I suspect it would have made sense to have two fairly different sets of conventions, one for complete docs and another for frags. Atom managed to give a sane story in both cases - <feed> or <entry> as root - probably only because it was XML... and it is more likely to be machine-generated from already-clean sources). Cheers, Danny. -- http://danny.ayers.name
