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 <[EMAIL PROTECTED]> 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
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
