[uf-discuss] Re: Nested hCards (WAS: microformats for groups and group memberships?)

[John Panzer]

In our blogging app, we currently use a xoxo list of vcards as one 
format for simple "friends lists" of readers and contributors.  Our use 
case is a bit more oriented towards personal lists than publishing 
(think Rolodex or buddy list), but perhaps it maps well to the contact 
groups/category model.  My "Friends" are a group from my point of view, 
regardless of whether they actually know each other.

Currently we're just using separate xoxo lists for the separate groups 
or roles.  This is a bit annoying as there may be quite a bit of overlap 
and we'd like to be able to have a flexible representation that can 
easily 'compactify' this information.  Categories sound like the right 
tool for this job; are they?

A concrete example:

<ul class="xoxo">
<li class="vcard">
<a href="aim:goim?ChattingChuck" class="fn url">Chuck</a> (<span 
class="category">reader</span>)
<li class="vcard">
<a href="aim:goim?SurfinDave" class="fn url">Dave</a> (<span 
class="category">reader</span>, <span class="category">contributor</span>)
</li>
</ul>

So Chuck is categorized as a reader, while Dave is categorized as both a 
reader and contributor.  (If this seems too special-case, think "Friend" 
and "Colleague" categories in an address book.  Is this reasonable?

-John


brian suda wrote:

>Correct, when you export out of some address books you will notice that
>the "Groups" come across as Categories.
>
>You could easily do something like:
><div class="vcard">
>...
><a href="http://acm.org" rel="member" class="category">ACM</a>
>...
></div>
>
>-brian
>
>Chris Messina wrote:
>  
>
>>So in rethinking my proposal, I can't think of any client software
>>that allows nested vcards.
>>
>>In my example, I basically wanted a group to be able to have members.
>>
>>Thinking it over though, Address Book.app allows groups of contacts
>>and will also export those groups (need to see their syntax).
>>
>>Perhaps my proposal was wrong, but this issue of scoping helps show
>>why. I think this fact -- that client software does support grouping
>>-- should give us extra impetus to push ahead with our brainstorming.
>>
>>Chris
>>
>>On 8/14/06, Brian Suda <brian.suda at gmail.com> wrote:
>>    
>>
>>>This mark-up snippit came across the mailing list a few days ago, i
>>>just wanted to point out a few parsing issues that people MIGHT not
>>>have been aware of.
>>>
>>>      
>>>
>>>>There's no reason why you couldn't do this and infer a relationship:
>>>>
>>>><div class="vcard">
>>>><h2 class="fn org">Foo Co.</h2>
>>>>
>>>><h3>Member Listing</h3>
>>>><ul class="xoxo">
>>>><li class="vcard"><a href="http://mulettesgalore.com" class="fn url"
>>>>rev="founder moderator member">Joe Bob</a></li>
>>>></ul>
>>>></div>
>>>>        
>>>>
>>>In this example there is an hCard inside another hCard.
>>>
>>>The deapest class="vcard" (the second instance) will pull the following
>>>fields:
>>>FN: Joe Bob
>>>URL: http://mulettesgalore.com
>>>
>>>This is expected and makes sense.
>>>
>>>The outermost hCard (the first instance) will probably pull more than
>>>expected.
>>>FN: Foo Co.
>>>ORG: Foo Co.
>>>URL: http://mulettesgalore.com
>>>
>>>Because a parse finds the FIRST class="vcard" it will then attempt to
>>>look at ANY child element for additional properties. It finds the
>>>first FN and ORG == to "Foo Co." and uses that - it will also find
>>>"Joe Bob" but because it will ONLY take the first instance, we are
>>>safe here - so ORDER DOES MATTER!!! It will then continue to look
>>>through the list of properies and it will find that URL does match the
>>>criteria and also pull that. We all sort of assume that the URL is
>>>part of Joe Bob's vCard, but according to the parsing rules Foo Co.
>>>will find this.
>>>
>>>This is not a bug, it is a feature. When we begin to nest hCards in
>>>hCalendars, they BOTH have a URL property, this is shared so a URL
>>>inside a vCard which is inside a vEvent will be pulled for that EVENT,
>>>which might not be what is intended.
>>>
>>>Just wanted to make folks aware that "scoping" could be a misunderstood
>>>issue.
>>>
>>>-brian
>>>
>>>-- 
>>>brian suda
>>>http://suda.co.uk
>>>_______________________________________________
>>>microformats-discuss mailing list
>>>microformats-discuss at microformats.org
>>>http://microformats.org/mailman/listinfo/microformats-discuss
>>>
>>>      
>>>
>>    
>>
>
>_______________________________________________
>microformats-discuss mailing list
>microformats-discuss at microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss
>  
>