mfo-brainstorming

Microformat Opacity/Object/Opaque Brainstorming

Can increased use of profile URIs solve this problem?

profile-uris are already recommended. Here's a proposal to make them required whenever opacity rules come up:

• Whenever one microformat is used within another, the interior microformat's profile URI MUST be used.
• Parsers must disregard all content within the root element identified in an unrecognized profile.

While not as flexible as an additional class name (e.g. class="mfo"), I like that profile URIs don't require publishers to think about parsing behavior.

-- ScottReynen

Issues

• People who publish using blogs, CMSs, Wikis etc. (including this wiki!) have no ability to add or change profile URIs in header tags. Andy Mabbett 14:28, 17 Jun 2007 (PDT)
• This will not work. How does a parser know whether or not they have encountered the root element of an unrecognised profile? How can they determine between a microformat root class and a POSH or presentational class? They would have to download every profile listed, and pray that they're in a parseable format such as XDMP or RDF. TobyInk 01:23, 7 Mar 2008 (PST)

mfo class is a workable solution

What I've found to be a workable solution when implementing Cognition is...

Parsers must:

• Maintain an as up-to-date as possible list of root class names used by current and draft microformats, even if the parser does not fully support those formats. (e.g. Cognition doesn't parse hAtom, hReview or hResume yet, but does have "hatom", "hreview" and "hresume" in that list.) The pseudo-root-class-name "mfo" MUST be in the list.
• When parsing a compound microformat:
  1. The parser should first attempt to parse "meaningfully embedded" microformats. For example, "adr", "geo" and "agent vcard" within an hCard.
  2. The parser should then run through its list of root class names, excluding any elements bearing those class names from being parsed as part of this object. For example, any element with class "hatom" would be excluded from being parsed as part of an hCard -- note that this doesn't mean that parsers should fail to parse the embedded hAtom at all -- but they must parse it completely independently of the hCard.
  3. The parse should then continue parsing as normal. Within our example hCard that may be to look for elements with class "fn", "role", "org", etc.

Authors may:

• Include class "mfo" on the root element for a microformat -- especially useful for new draft microformats.

As I've said, this does actually seem to work in practice. TobyInk 01:23, 7 Mar 2008 (PST)

Related pages

mfo-examples