mfo-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(MFO solution)
 
Line 14: Line 14:
=== Issues ===
=== Issues ===
* People who publish using blogs, CMSs, Wikis etc. (including this wiki!) have no ability to add or change profile URIs in header tags. [[User:AndyMabbett|Andy Mabbett]] 14:28, 17 Jun 2007 (PDT)
* People who publish using blogs, CMSs, Wikis etc. (including this wiki!) have no ability to add or change profile URIs in header tags. [[User:AndyMabbett|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.
* 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. [[User:TobyInk|TobyInk]] 01:23, 7 Mar 2008 (PST)
 
== mfo class is a workable solution ==
 
What I've found to be a workable solution when implementing [http://buzzword.org.uk/cognition/ 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:
*# The parser should first attempt to parse "meaningfully embedded" microformats. For example, "adr", "geo" and "agent vcard" within an hCard.
*# 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.
*# 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. [[User:TobyInk|TobyInk]] 01:23, 7 Mar 2008 (PST)


==Related pages==
==Related pages==


[[mfo-examples]]
[[mfo-examples]]

Latest revision as of 09:23, 7 March 2008

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