On 6/4/07, Taylor Cowan <[EMAIL PROTECTED]> wrote:
hReview and the proposed hListing are very similar, sharing structure and properties. They both
use "item" and it seems logical that they should work exactly the same in that area...but
they are just different enough to cause parsing issues. From the hReview page, it states that
"fn" must be a child....
http://microformats.org/wiki/hreview
Encapsulated microformats (e.g. hCard and hCalendar events for now) may be set on the item itself (e.g.
class="item vcard"). However, when using item info subproperties ("fn", "url",
"photo"), they MUST be nested inside the item element.
However, on the hListing proposal, item and fn are used in an example like this:
<span class="item fn">Parking space</span>
--- this is a problem and it should be implemented in the same way
that hReview is, FN is a child of ITEM.
If we can make them agree it sure is easier to write pasers, in this case you merely take an exising hReview
parser and add/change a few property names. Since there are already public examples of that on edgeio I
wonder if the restriction in hReview should be relaxed regarding ("fn", "url",
"photo") as child nodes. It also seems that a second identifier within the same @class attribute
is really a child anyway.
--- in the class attribute, the order of properties is not important,
so you can't say that it will always be the second identifer. The ITEM
property acts as a container that then has additional metadata such as
FN, TYPE, PHOTO, etc.
hListing should be updated to reflect this.
-brian
--
brian suda
http://suda.co.uk
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
