On Jul 19, 2010, at 8:57 PM, Oli Studholme wrote: >>> Microdata doesn't go out of its way to be compatible with existing RDF >>> vocabularies >> >> Maybe not specific vocabularies (that's kind of my point), but RDF itself is >> clearly a major consideration. There's a whole section on it: >> >> http://www.w3.org/TR/microdata/#rdf > > No. There’s a sub-sub-section on converting to RDF, just as there are > for converting to JSON and Atom. That’s not a design goal, it’s > specified interoperability.
They're mentioned as "requirements" in the original announcement: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019681.html But again, the RDF syntax doesn't matter. This is the important part for me: "Distributed vocabulary development should be possible; it should not require coordination through a centralised system." Distributed vocabulary development requires a general purpose solution. Microformats don't have that requirement, so vocabulary-specific solutions are common. >> I'd argue it is a bad idea in microdata, but not in microformats, because of >> the very distinction I'm trying to draw between the two. > > As far as microdata goes it’s irrelevant — that’s something decided by > the *vocabulary* author. I don't think that's really true, though, and I think this is exactly why n optimization was removed. For every other microdata property, the value is determined by following the parsing rules in the microdata spec: http://www.w3.org/TR/microdata/#values With n optimization, undeclared properties are given values via a completely different parsing model. This "magic" may not be explicitly disallowed, but it doesn't really fit with the general design of microdata. On Jul 19, 2010, at 10:05 PM, Angelo Gladding wrote: > Could it be said that microdata intends to do to Microformat syntax > what HTML5 did to HTML4 syntax rules in the sense that parsing is > unambiguous and easier to validate normativity? I'd say that's true as far as what they both do, but not how they do it. HTML5 makes parsing unambiguous by describing a wide variety of parsing rules for invalid content. I'd say such tolerance of human error is more in line with the microformats approach. Microdata, on the other hand, simply changes the syntax to reduce the risk of invalid content. So in terms of strategy for making parsing unambiguous, microdata looks more like XHTML to me. On Jul 20, 2010, at 4:25 AM, Philip Jägenstedt wrote: > Microdata should be compared to the class attributes and the various patterns > that microformats use, not any specific vocabulary. Agreed! > The main benefit is that parsing becomes well-defined and simple. Right, a lot of it comes down to optimizing for parsers vs. optimizing for publishers. HTML itself is familiar to publishers, but difficult to parse for data. Microformats are limited to HTML to make things simpler for publishers at a cost to parsers. Microdata extends HTML to make things simpler for parsers at a cost to publishers. Of course, publishers and parsers need to work together, so these approaches only diverge so far. Peace, Scott _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
