[uf-dev] hResume question

[Steve Ganz]

On October 20, 2006, David Janes wrote:
> On 10/6/06, Ryan King <ryan at technorati.com> wrote:
> > On Sep 18, 2006, at 5:20 PM, David Janes wrote:
> >
> > Sorry for the lag on this...
> >
> > Personally I'd rather not introduce an opacity rule, I'd 
> > rather make the one hCard explicitly the person's experience hCard. Any 
> > suggestions on how we should do that?
> >
> > -ryan
> 
> The slowest moving conversation ever...
> 
> This has been itching at me for a while, and the best 
> solution I can some up with is that the _first_ hCard must be 
> the person's experience hCard. This almost certainly would 
> always be the case and avoids introducing another class name.
> 

I just added this as an open issue to the recently created hResume issues[1]
page.

I understand the general reluctance to introduce another class name, but I
am generally opposed to requiring that sets of information occur in a
specific linear order in a microformat. Is there precedence for that?

Because this is a second (and probably not the last) instance of needing to
distinguish different types of hCards in hResume (the other being the
subject's contact info), I think we should think about a common set of class
names we can use as a compound with "vcard" on the root element of the
hCard. 

Ideas - 

Contact Info:
1. "vcard contact" - Some hResume authors have mistakenly interpreted the
schema as calling for this as required class name for Contact Info. Happy
accident?
2. "vcard me" - Existing XFN naming convention. 

Experience:
1. "vcard colleague" - Existing XFN naming convention. LinkedIn refers to
colleagues in general.
2. "vcard co-worker" - Existing XFN naming convention. LinkedIn refers to
co-workers specifically in their "recommendations" [2].
3. "vcard manager" - LinkedIn refers to managers specifically in their
"recommendations" [2].

[1] http://microformats.org/wiki/hresume-issues 
[2] http://www.linkedin.com/profile?viewProfile=&key=2876929