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
