[uf-discuss] AUMFP and hResume
Chris Casciano
chris at placenamehere.com
Mon Sep 18 10:33:25 PDT 2006
On Sep 18, 2006, at 1:09 PM, Ryan King wrote:
> from the discussion at [http://
> blogmatrix.blogmatrix.com/:entry:blogmatrix-2006-09-16-0000/
> #p2006-09-17-0003], Steve Ganz says:
>
>> One of the things I suggested as a solution to the "<address> as
>> root for the hCard problem" was that if an hCard simply contained
>> the <address> element, that in itself would distinguish it as the
>> author's hCard.
>>
>> This would allow an author to explicitly markup their preferred
>> contact information within that particular hCard. Some might
>> choose to mark up the email block, others might use it to markup
>> their phone number, and still others might choose their steet-
>> address, etc.
>
> I'm not sure I like the idea of parsing hCards based on their
> contents. It would seem cleaner design to put whatever indicator we
> use on the containing element.
>
> I"m responding to this in particular because the idea of "preferred
> contact information" sounded familiar. There's already a vCard type
> (For TEL (sect. 3.3.1), EMAIL (sect. 3.3.2) and ADR (sect. 3.2.1)
> called PREF, which is used to mark the preferred item for each of
> those.
>
> So, I don't think using the <address> element would be worthwhile
> for this.
>
> -ryan
i think address 'stinks' in this context for other reasons as well...
I can think of a number of cases where the resume information is just
content and doesn't have a direct link back to the authorship of a
page itself. Be it professional bios where the address is reserved
for more globally applicable information or company info, job listing
sites, any page with multiple resumes of members of some sort, etc.
I know most of the current hresume examples found on the wiki are "my
resume" type web pages from personal sites, but I don't want to be
too quick to overlook or rule out some of the non-DTD reasons for
needing alternatives to overloading the address element
--
[ Chris Casciano ]
[ chris at placenamehere.com ] [ http://placenamehere.com ]
More information about the microformats-discuss
mailing list