HCalendar with nested HCard

3 views
Skip to first unread message

jystewart

unread,
Feb 6, 2007, 12:18:24 PM2/6/07
to mofo
I've been using mofo on a project where we want an API that accepts
events marked up with hcalendar. So far it seems to be working great.
Thanks.

The one area we have a problem is when an event contains nested hCard/
geo/addr data as its location and we want to parse that out. Initially
I tried modifying the HCalendar class to set

one :location => HCard

but that fails if the location is a simple string.

I've thought of a few possible approaches, including:

* parse out hcards separately and either hope they match up or use
hpricot and selectors to make sure its only hcards from within the
specific event

* add an extra class such as HCalendarWithNesting and try parsing
with both to see which picks up useful data.

But I wanted to see if anyone had any other ideas, or pointers as I
don't yet know the internals of mofo very well?

Where the specs allow for multiple ways of representing data, it would
be really good to be able to get at the various options through a
single interface.

thanks. James.

Chris Wanstrath

unread,
Feb 6, 2007, 2:04:41 PM2/6/07
to mof...@googlegroups.com
On 2/6/07, jystewart <ja...@jystewart.net> wrote:

> The one area we have a problem is when an event contains nested hCard/
> geo/addr data as its location and we want to parse that out. Initially
> I tried modifying the HCalendar class to set
>
> one :location => HCard
>
> but that fails if the location is a simple string.

What if we do:
one :location => [ String, Adr, HCard ]

The idea here being mofo would try to find a String, then an Adr, then
an HCard when it comes across .location.

If this is what you're looking for, I'll add it in.

--
Chris Wanstrath
http://errtheblog.com

James Stewart

unread,
Feb 6, 2007, 3:07:31 PM2/6/07
to mof...@googlegroups.com

Yeah, that looks like it's exactly what I need.

Would it be better to go in the other order though? Looking for
progressively less structured data?

thanks. James.

Chris Wanstrath

unread,
Feb 6, 2007, 7:07:38 PM2/6/07
to mof...@googlegroups.com
On 2/6/07, James Stewart <ja...@jystewart.net> wrote:

> Would it be better to go in the other order though? Looking for
> progressively less structured data?

Good point. I'll try and hack this in tonight. If you're feeling
adventerous, feel free to add a spec (and a fixture) so I can just hit
up the implementation based on a failing test case. Either way, this
has been asked for before so it needs to be done. Will let you know.

James Stewart

unread,
Feb 7, 2007, 9:40:25 AM2/7/07
to mof...@googlegroups.com

I have a simple spec and a couple of extra fixtures. I'm attaching
them in a tarball. Let me know if you'd like them submitted any other
way.

James.

new-test.tgz

Chris Wanstrath

unread,
Feb 8, 2007, 3:24:07 AM2/8/07
to mof...@googlegroups.com
On 2/7/07, James Stewart <ja...@jystewart.net> wrote:

> I have a simple spec and a couple of extra fixtures. I'm attaching
> them in a tarball. Let me know if you'd like them submitted any other
> way.

Cool. There are a few issues with this, but I've begun work. Most
importantly: your event_addr.html fixture is wrong, I believe. The
adr and geo inside of the location class should correspond to the
hCard, but you took out the 'vcard' class and the dude's name. This
is confusing, it's understandable, but I think this 'location' example
is an hCard example as opposed to a true Adr example. Got any more
Adr examples laying around? That'd help.

I have been committing to svn://rubyforge.org/var/svn/mofo/trunk
tonight, some changes. I added the Adr and Geo microformats and added
them to hCard.

Should hopefully have the [ HCard, Adr, Geo, String ] stuff done soon.
Of the three specs you've submitted, I've got one passing. It's a
start!

Thanks.

James Stewart

unread,
Feb 8, 2007, 10:05:58 AM2/8/07
to mof...@googlegroups.com
On Feb 8, 2007, at 3:24 AM, Chris Wanstrath wrote:
> On 2/7/07, James Stewart <ja...@jystewart.net> wrote:
>
>> I have a simple spec and a couple of extra fixtures. I'm attaching
>> them in a tarball. Let me know if you'd like them submitted any other
>> way.
>
> Cool. There are a few issues with this, but I've begun work. Most
> importantly: your event_addr.html fixture is wrong, I believe. The
> adr and geo inside of the location class should correspond to the
> hCard, but you took out the 'vcard' class and the dude's name.
> This is confusing, it's understandable, but I think this 'location'
> example is an hCard example as opposed to a true Adr example. Got
> any more Adr examples laying around? That'd help.

Maybe I should have named that one differently? What I wanted to show
with that was an hCalendar entry with just an 'addr' and not a full
vcard. From the uf wiki:

"A named LOCATION (potentially with an address and/or geo) in
iCalendar may be represented by a nested hCard in hCalendar.
Similarly, an address LOCATION may be represented by an adr, and a
geo (latitude and longitude) LOCATION may be represented by a geo."

For adr on its own there's one example on the main wiki page:

<div class="adr">
<div class="street-address">665 3rd St.</div>
<div class="extended-address">Suite 207</div>
<span class="locality">San Francisco</span>,
<span class="region">CA</span>
<span class="postal-code">94107</span>
<div class="country-name">U.S.A.</div>
</div>

But it seems the expectation is that adr will almost always be used
within another microformat, and there aren't any other examples given.


> I have been committing to svn://rubyforge.org/var/svn/mofo/trunk
> tonight, some changes. I added the Adr and Geo microformats and
> added them to hCard.
>
> Should hopefully have the [ HCard, Adr, Geo, String ] stuff done
> soon. Of the three specs you've submitted, I've got one passing.
> It's a start!

Great!

Thanks.

James.

--
James Stewart
Web Developer

Work: http://jystewart.net/process/
Play: http://james.anthropiccollective.org/

Chris Wanstrath

unread,
Feb 8, 2007, 11:18:11 AM2/8/07
to mof...@googlegroups.com
On 2/8/07, James Stewart <ja...@jystewart.net> wrote:

> "A named LOCATION (potentially with an address and/or geo) in
> iCalendar may be represented by a nested hCard in hCalendar.
> Similarly, an address LOCATION may be represented by an adr, and a
> geo (latitude and longitude) LOCATION may be represented by a geo."

The fixture you submitted has an adr AND a geo. The wiki seems to
imply that while iCal can have both, an hCal can only have one or the
other. I am feeling a bit fuzzy on this so will check some more stuff
out to see what the answer is.

Can an hCalendar have a location and a geo and an adr? Questions.

> For adr on its own there's one example on the main wiki page:

Thanks.

James Stewart

unread,
Feb 13, 2007, 9:38:47 PM2/13/07
to mof...@googlegroups.com
On Feb 8, 2007, at 11:18 AM, Chris Wanstrath wrote:
> On 2/8/07, James Stewart <ja...@jystewart.net> wrote:
>> "A named LOCATION (potentially with an address and/or geo) in
>> iCalendar may be represented by a nested hCard in hCalendar.
>> Similarly, an address LOCATION may be represented by an adr, and a
>> geo (latitude and longitude) LOCATION may be represented by a geo."
>
> The fixture you submitted has an adr AND a geo. The wiki seems to
> imply that while iCal can have both, an hCal can only have one or the
> other. I am feeling a bit fuzzy on this so will check some more stuff
> out to see what the answer is.
>
> Can an hCalendar have a location and a geo and an adr? Questions.

Revisiting that paragraph I'd lean towards your interpretation, that
it's one or the other.

How's the coding to support this going?

James.

Chris Wanstrath

unread,
Feb 14, 2007, 4:55:47 AM2/14/07
to mof...@googlegroups.com
On 2/13/07, James Stewart <ja...@jystewart.net> wrote:

> Revisiting that paragraph I'd lean towards your interpretation, that
> it's one or the other.
>
> How's the coding to support this going?

It's checked into trunk. I think we're looking at a 0.2 release
sometime next week.

If you wanna play:
$ svn co svn://rubyforge.org/var/svn/mofo/trunk

Here's the new hCalendar format:
http://require.errtheblog.com/mofo/browser/trunk/lib/mofo/hcalendar.rb

My next push for mofo will be adding documentation to the code (need
to document the API for writing custom parsers like xoxo and xfn) and
working on the site, mofo.rubyforge.org.

Reply all
Reply to author
Forward
0 new messages