[uf-discuss] hresume draft
scott at randomchaos.com
Sun Feb 12 16:08:18 PST 2006
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
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.
More information about the microformats-discuss