Replies to Thomas and Bob inline:
On Tue, Jun 30, 2009 at 3:43 AM, Thomas Loertsch<[email protected]> wrote: > I'll try to copy (more of) the referenced conventions inline and make the > page more self-contained. But that isn't always as easy as it sounds: e.g. > "author" is reused from hAtom which itself states that "an Entry Author > element MUST be encoded in an hCard", which - if I got it right - leads to > the following construct: > > <div class="hrecipe"> > <p class="author vcard fn">Hans Wurst</p> > > That's not exactly self-containing and standalone. But searchmonkey would > know how to parse it, right? Currently Searchmonkey (and any other hCard parser should treat that hCard as invalid). Per the hCard FAQ you cannot combine "vcard" and "fn" classnames on the same element: http://microformats.org/wiki/hcard-faq#Can_you_mix_properties_and_the_root_class_name However, as this question / implied proposal has come up many times, and microformats does have the design principle of starting and making solutions as simple as possible, I've added a "root only shorthand syntax" proposal to hCard brainstorming for hCard 1.0.1 that would allow specifying an hCard with only the root class name. http://microformats.org/wiki/hcard-brainstorming#root_only_shorthand_syntax E.g.: <p class="vcard">Hans Wurst</p> Which would then imply the one required property "fn", which could then be used to imply additional property values. In short, this would allow the following (slightly simpler) markup for the above example: <div class="hrecipe"> <p class="author vcard">Hans Wurst</p> For more details of how ROSS would work, or to note issues or suggest improvements, please do not reply inline in email, and instead see and add to: http://microformats.org/wiki/hcard-brainstorming#root_only_shorthand_syntax On Fri, Jul 3, 2009 at 7:50 AM, Bob Douglas<[email protected]> wrote: > Hi, I'm still getting oriented to the list, apologies for the late response, > length, and any glaring naiveness. Would post on the wiki, but not > familiar enough yet to understand where it would fit. Hello and welcome Bob. Here is a brief guide to where at least some content belongs/fits on the wiki: http://microformats.org/wiki/put-it-on-the-wiki#where_to_put_what_on_the_wiki > This has been a helpful thread, but seems more guidance on handling mixed > context may be a looming issue on MediaWiki/Wikipedia type sites - > especially for users who will be introduced to microformats through Operator > (Firefox), Oomph (IE), or similar browser add-ons. Two usage problems are: > > A. Corruption (or significant alteration) of results over time as > different editors insert microformat producing templates into wiki pages or > add microformats to existing (mw-)templates. > > B. Significant differences in behavior due to the core "rules" applied in > emerging microformat browser tools. > > Here are two examples from current (30JUN2009) Wikipedia articles: > 1. Two vcards/vevents on a page (http://en.wikipedia.org/wiki/Einstein) Thank you for providing a URL to a real world example. > The Einstein bio page contains two (un-nested) infoboxes that both declare > vcard and vevent classes on the table as : > > table class="infobox vcard vevent" > td class="fn summary">Albert Einstein<.... > /table > > table class="infobox biography vcard vevent" > td class="fn summary">Albert Einstein<.... > /table > > Oomph returns the resulting two contacts and two events - none of which are > valid (missing the required "n" and "dtstart" values). In particular the hCards seem to be fine (n is implied from fn, works in Operator), and thus if you are seeing a problem with Oomph, it may be a bug in Oomph. I just created an oomph-issues page and summarized this problem - it could probably use more details to help track down the problem: http://microformats.org/wiki/oomph-issues > Detector returns a single valid contact I'm unfamiliar with the "Detector" microformats implementation - could you add it to: http://microformats.org/wiki/implementations > by extracting the "n" values > (family-name, given-name) per the spec from the single space delimited "fn" > string. Sounds like it is behaving correctly. > Luck in this case as most other bio pages include a middle name or > initial. One or more example URLs for pages like that would help with refining the resolutions to related hCard issues (when an fn includes a middle name or initial and there is no n property). > Can't tell from this example if Detector is ignoring or merging the > duplicate vcard with identical "fn"/"n" values. (Anybody know the logic?) > However, it does ignore the invalid events. Here are the complete contents > Detector produces for the Einstein page: > > BEGIN:VCARD > PRODID:-//kaply.com//Operator 0.8//EN Ah - is "Detector" another name for the "Operator" Firefox extension? http://microformats.org/wiki/operator > SOURCE:http://en.wikipedia.org/wiki/Einstein > NAME:Albert Einstein - Wikipedia, the free encyclopedia > VERSION:3.0 > N;CHARSET=UTF-8:Einstein;Albert;;; > FN;CHARSET=UTF-8:Albert Einstein > CATEGORIES;CHARSET=UTF-8:Württemberg/Germany (1879–96) Switzerland > (1901–55) Austria (1911–12) Germany (1914–33) United States > (1940–55),Ashkenazi Jewish and German,Physics > BDAY:1879-03-14 > UID: > END:VCARD This looks correct, except for the empty "UID", which simply shouldn't be present - if this is actually happening, could you document the specifics (URL, version(s) etc.) on the Operator issues page? http://microformats.org/wiki/operator-issues > 2. vcards/vevents nested within another vcard/vevent on page > http://en.wikipedia.org/wiki/Edison > > The Edison page includes a single biography infobox in which a microformat > producing template has been inserted for his two marriages. Intuitively > this should simply be two events (three if you count Edison's birth as an > event) within the scope of a person's life. What is produced is a strange > brew of nested microformat classes. The structure is: > > table class="infobox biography vcard vevent" > td class="fn summary">Thomas Alva Edison<.... > > span class="vcard" > span class="vevent" > span class="dtstart">1871</span > span class="dtend">1885</span > span class="fn org summary">Marriage: Mary Stilwell to Thomas > Edison</span > span class="uid url"><a href="http....</span > /span /span > > span class="vcard" > span class="vevent" > span class="dtstart">1886</span > span class="dtend">1932</span > span class="fn org summary">Marriage: Mina Edison to Thomas Edison</span > span class="uid url"><a href="http....</span > /span /span > > /table The template biography infobox that you mention is producing that markup appears to have a few problems, e.g. "Marriage: Mina Edison to Thomas Edison" is certainly not an "fn" nor an "org" of an hCard (though it sounds like a valid "summary" of that event). > Oomph identifies the three events: the two marriages and the vevent on the > infobox table where the "summary" values are concatenated (Thomas Alva > EdisonMarriage: Mary Stilwell to Thomas EdisonMarriage: Mina Edison to > Thomas Edison). That sounds like an Oomph bug as it is not properly respecting the parsing boundary of the nested hCalendar event as specified in the hCard parsing spec: http://microformats.org/wiki/hcard-parsing#nested_hCards Please add the description of this problem and note the nesting rule from hCard parsing to oomph-issues: http://microformats.org/wiki/oomph-issues > None are valid as it is apparently unable to set "dtstart" > from the values provided. That sounds like another Oomph issue to note - as the YYYY year values are valid. > Detector identifies only one contact for the page, though technically > invalid since "n" values cannot be automatically extracted from the three > names in "fn". The main difference in behavior is that "fn" and "org" > values are set to the first occurrences. One obnoxious result of the nested > vcard/vevent is that the marriage event description ("summary") is passed to > the top-level vcard in the "org" attribute. The vcard returned by Operator > for the Edison page is: > > BEGIN:VCARD > PRODID:-//kaply.com//Operator 0.8//EN > SOURCE:http://en.wikipedia.org/wiki/Edison > NAME:Thomas Edison - Wikipedia, the free encyclopedia > VERSION:3.0 > N:;;;; > ORG;CHARSET=UTF-8:Marriage: Mary Stilwell to Thomas Edison > FN;CHARSET=UTF-8:Thomas Alva Edison > ROLE;CHARSET=UTF-8:inventor, scientist, businessman > BDAY:1847-02-11 > UID: > END:VCARD This sounds like Operator 0.8 may have a similar hCard nesting bug as Oomph did with the hCalendar event. Please add it to: http://microformats.org/wiki/operator-issues And note the link to http://microformats.org/wiki/hcard-parsing#nested_hCards for proper parsing behavior. > 1) Seems the common practice of slapping "class= vcard vevent" on templates > will be troublesome in a wiki environment - can be too ambiguous for tools > to determine the intended semantic context. I tend to agree with that and wonder if that's something we can somehow incorporate into hcard-authoring and/or hcalendar-authoring: http://microformats.org/wiki/hcard-authoring http://microformats.org/wiki/hcalendar-authoring > 2) Seems to be a need to clarify default behaviors (rules) related to > context. For example, how should a tool handle multiple values for "fn", > "org", "summary", etc within the same div/span of a vcard or vevent class: > concatenate (Oomph), first occurrence (Detector), last occurrence > (override), etc? Example is vcard/event, but likely an issue for others > too. First occurrence for singleton properties per: http://microformats.org/wiki/hcard-parsing#finding_hCard_properties multiple occurrences for multi-valued properties should simply generate multiple values. > Best regards, Bob Douglas Thanks for the considerable feedback Bob, and please let me know if you have suggestions for how we can improve the discoverability/findability of various pages (and where to put stuff) on the wiki. Tantek -- http://tantek.com/ _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
