On Feb 12, 2006, at 5:21 PM, Ryan King wrote:
Here's the general problem:
We want to use hCards for job positions/titles in hResume, but
don't want to have to reproduced FN/N for every one (that'd be
silly). However, N is required for hCard (b/c its required for
vCard), so we need some way to subsequent hCards in an hResume page
to reference the FN/N on the contact info (typically at the top of
the page).
If we find that this is a workable method, we can generalize it to
other microformats (as has been requested, esp. with hReview).
This method is something that Tantek and I came up with while
brainstorming about hResume with James Levine of Simply Hired. We
haven't gotten any feedback on it from others (except Brian Suda,
who says it will be workable for X2V to support this), so, please
examine it and give your feedback.
Here are a few potential problems I see:
1) it allows for a complete disconnect between what a human reads and
what a machine reads, as humans read by proximity, not pointers.
2) the resultant hCards contain out-of-date information, with a
person identified under a job title they no longer hold (except
possibly the most recent experience).
3) it makes parsing more complicated. Currently, a parser needs to
consider only the fragment of the documents within the root of the
microformat, but allowing data to be scattered about the document
means a parser needs to have the entire document available during
parsing.
Backing up a step, what is the advantage of using the hCard class on
education and experience data? Just reusing components from hCard
without labeling them hCards would remove the need to follow hCard's
fn requirement, but I'm not clear on what would be lost in the process.
Peace,
Scott
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
