Hi Ben,
I was thinking of something like Toby's page on compositioning which
sets out possible, clearly OK and clearly suspicious combinations.
Cheers,
Peter
Ben Ward wrote:
Hi Peter,
On 24 Jun 2009, at 23:04, Peter Mika wrote:
What I posit has happened is that at one point, answers.com marked
up the ‘Years Active’ part of that info box with dtstart and dtend.
Yes, but let's assume they had the dtstart, i.e. a valid event and a
card. Still, having an event named 'Kevin Bacon' is dubious.
It's not a high quality object, I agree. But, it's valid. It describes
a timespan and that's a valid event.
However, they might have gotten the idea that it's ok to do this,
because the two microformats share the fn property. So they could
have thought, why repeat it twice?
I don't agree, although we should acknowledge here that we're both
second guessing another developer's intent. I don't think the scenario
you describe is a concern, and we've never had any prior suggestion of
it occurring. With reference to this case:
* hCalendar does not have an `fn` property, no example here or
elsewhere would instruct someone to use `fn` in hCal.
* The mark-up here explicitly uses `summary` and `fn`. That "Kevin
Bacon" is an incomplete name for an event from a content quality
perspective is not in dispute, but the author explicitly made it the
summary of their event. They didn't add a second summary attribute
elsewhere in the content, expecting it to be amalgamated.
I think it's most likely that the developer is just trying to describe
all the data they have available using the tools they have: There's an
hCard there and there's an event. Someone trying to parse his page
specifically could imply information from the hCard+hCalendar, and
that's cool, but at the core he's tried to describe his complex
content using the building blocks available.
Either way, we can't be certain without consulting with them. I don't
think it's evidence of erroneous confusion.
I would suggest a page that describes precise what combinations of
microformats are allowed, e.g. that an adr inside hcard is ok, but a
recipe inside an hresume is not.
I might not be following you quite right here, I keep interpreting
this sentence in opposite ways each time I read it. I'm going to
answer both interpretations for completeness:
1. I don't think there is any concept of 'allowed' vs. 'not'. There's
obviously no specified relationship between Resumé and Recipe (at this
time… cue every unemployed chef on the world wide web joining
µf-discuss… ha), but that doesn't mean a piece of content within that
resume document couldn't be a recipe. A chef could include their
favourite salad dressing recipe in their resumé as part of the
description of some work experience. The example doesn't matter: There
shouldn't be no restriction on describing one piece of structured
data, independently of another, based on what the outer-most structure
is.
In terms of µf that have explicit function within another microformat,
that is already documented as part of the specs. ADR is part of hCard,
hAtom specifies authors must be hCard, hReview specifies that
class="item vevent" means you're reviewing an event. And so on. Any
unspecified combination should be treated as two discrete objects.
2. On the flip side, if you mean that we should provide fuller
specifications of what microformats do mean in combination, that's a
different issue, but one that again there's limited demand for.
Combinations (say, using hCal inside of hResume for experience) get
worked out in response to use cases, either in the initial development
of a spec or later, either way not pre-emptively. Using hCalendar for
life-spans (in place of an hCard date-of-death field), was an example
that came up a few years ago.
People experiment with combinations in their own pages where it makes
sense to them; no different to publishing with any other HTML element.
Those experiments may influence brainstorming for specifying new
patterns.
Like all new uses of microformats, ideas about uses of combined
microformats should be documented on each microformat's
*-brainstorming page.
Thanks,
Ben
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
