On Tue, 20 Jul 2010 15:47:19 +0200, Scott Reynen <sc...@randomchaos.com> wrote:

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.

Yes, which is why general purpose parsers cannot exist, and why browser support is unlikely.

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.

The magic was in the vCard extraction algorithm: <http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#conversion-to-vcard>

The DOM isn't changed, that would indeed be a very bad fit with the overall design.

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.

HTML5 parsing is also unambiguous. The only reason it's so ridiculously complex is because it's needed to parse real markup on the web. With microdata there was no existing content, so it's possible to make a more sane definition. But of course, some parts may be too strict and I've previously left feedback and had gotten the spec changed due to this. If there are more things which are unnecessarily strict and makes it difficult for authors, please do send mail to the WHATWG or W3C so that it can be fixed.

--
Philip Jägenstedt
Core Developer
Opera Software

_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Reply via email to