From jason at sixtwothree.org Tue Apr 3 10:31:38 2007
From: jason at sixtwothree.org (Jason Garber)
Date: Tue Apr 3 10:31:44 2007
Subject: [uf-dev] Simile Timeline and microformats
Message-ID: <46128F7A.3020105@sixtwothree.org>
(Note: this was my original message to uf-discuss, posted here since
it's an implementation)
Hi all, I've put together a quick-and-dirty demo for using Simile
Timeline [1] with a list of hCal events:
http://sixtwothree.org/simile/timeline-example.html
I dug through the uf-discuss archives and didn't come across too much
talk of doing this. Simile Timeline is listed on the History Examples
page under Tools [2].
Either way, it's not completely bulletproof (yet), but it proves that
Simile Timeline can be used with microformats in an accessible manner
(out of the box, viewing a Simile Timeline page w/o Javascript gives you
no content). I've got a ways to go with it (importing icons, photos,
etc.), but wanted to get community feedback on the work so far.
Thanks!
Jason
jason@sixtwothree.org
[1] http://simile.mit.edu/timeline/
[2] http://microformats.org/wiki/history-examples#Tools_for_Timelines
From ryan at technorati.com Tue Apr 3 11:51:18 2007
From: ryan at technorati.com (Ryan King)
Date: Tue Apr 3 11:51:20 2007
Subject: [uf-dev] hCard locations in hCalendar
Message-ID: <56475C7E-E022-4EFE-8521-CF05BE3D6D49@technorati.com>
I've been looking at ways to better markup up (and parse) locations
in hCalendar. I had been under the assumption that iCalendar's
LOCATION field was just plain text. [1]
However, it turns out that, per RFC 2445, section 4.8.1.7, LOCATION
can take an ALTREP parameter, which is "a URI that points to
directory information with more structured specification of the
location". So, in addition to the text, we can give a link to a
structured representation.
This brings up several issues.
Assumption: if an agent is consuming iCalendar, they'd prefer to
consume vCard, rather than hCard.
1. How could a service like X2V handle this?
* It could supply links (piped through X2V's vCard service) to a
vCard for the location. Ex (from: http://austin.adactio.com/, @id
added):
Six,
117 West 4th St
could be transformed to:
LOCATION;ALTREP="http://feeds.technorati.com/contacts/http://
austin.adactio.com/%23six": Six 117 West 4th St
Note that for cases where there is more than one hCard on a page,
the fragment identifier is extremely useful (probably necessary).
* it *could*, in theory, use multipart MIME. Has this ever been
done for HTTP?
2. How can we specify this in our test suite?
* MIME CIDs, though ugly, would keep things in one file
* putting the vCards in separate vcf files. (not sure if ALTREP can
take a relative URI, though. it should right?)
3. Should we let authors specify the ALTREP URI? Could it just be the
UID?
-ryan
1. I blame tantek: http://microformats.org/wiki/hcalendar-
brainstorming#hCard_locations
--
Ryan King
ryan@technorati.com
From andy at pigsonthewing.org.uk Tue Apr 3 11:53:36 2007
From: andy at pigsonthewing.org.uk (Andy Mabbett)
Date: Tue Apr 3 11:55:54 2007
Subject: [uf-dev] Converting Geo waypoints to GPX for transfer to GPS units
(was: Wanted: On-line parser for Geo)
In-Reply-To: <4EhkIUHozqCGFw0F@pigsonthewing.org.uk>
References:
<21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com>
<21e770780703280458n1af169a6p69a3ab2c0d12d7a2@mail.gmail.com>
<4EhkIUHozqCGFw0F@pigsonthewing.org.uk>
Message-ID: <0DhXJAYwKqEGFwlX@pigsonthewing.org.uk>
In message <4EhkIUHozqCGFw0F@pigsonthewing.org.uk>, Andy Mabbett
writes
>In message
><21e770780703280458n1af169a6p69a3ab2c0d12d7a2@mail.gmail.com>, Brian
>Suda writes
>>> >> Are there any on-line parsers for Geo?
>>what sort of output are you looking for? JSON, XML,
>>serialized PHP, other?
>
>HTML
(Postscript)
Also GPX:
"GPS eXchange Format is an XML schema designed for transferring
GPS data between software applications. It can be used to
describe waypoints, tracks, and routes."
I think being able to "move" places from a website onto a GPS device,
via GPX (which seems widely supported), is likely to be the "killer
application" for Geo. (I've also suggested GPX to Mike Kaply, for use by
Operator).
--
Andy Mabbett
From arango at gmail.com Tue Apr 3 12:09:38 2007
From: arango at gmail.com (David Arango)
Date: Tue Apr 3 12:09:45 2007
Subject: [uf-dev] Converting Geo waypoints to GPX for transfer to GPS
units (was: Wanted: On-line parser for Geo)
In-Reply-To: <0DhXJAYwKqEGFwlX@pigsonthewing.org.uk>
References:
<21e770780703280349w69eb0a00u478671e5e863c4cd@mail.gmail.com>
<21e770780703280458n1af169a6p69a3ab2c0d12d7a2@mail.gmail.com>
<4EhkIUHozqCGFw0F@pigsonthewing.org.uk>
<0DhXJAYwKqEGFwlX@pigsonthewing.org.uk>
Message-ID:
On 4/3/07, Andy Mabbett wrote:
> I think being able to "move" places from a website onto a GPS device,
> via GPX (which seems widely supported), is likely to be the "killer
> application" for Geo. (I've also suggested GPX to Mike Kaply, for use by
> Operator).
I did something with GPX and Google Maps [1] some time ago, hope it
helps someone.
Bikely [2] is serving bike routes in GPX format, very nice :-)
[1] http://www.mildiez.net/sandbox/routr/
[2] http://www.bikely.com
--
David Arango, el ?nico desarrollador con una orden de alejamiento de
Jeffrey Zeldman
Simplelogica.net, ahora con un 33,3% m?s de intromisi?n en listas de correo
Cuando no hago otra cosa escribo en mildiez.net
From brian.suda at gmail.com Tue Apr 3 14:46:36 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Tue Apr 3 14:46:39 2007
Subject: [uf-dev] Simile Timeline and microformats
In-Reply-To: <46128F7A.3020105@sixtwothree.org>
References: <46128F7A.3020105@sixtwothree.org>
Message-ID: <21e770780704031446j1b49ef30sfe7caccc629cf47b@mail.gmail.com>
On 4/3/07, Jason Garber wrote:
> Hi all, I've put together a quick-and-dirty demo for using Simile
> Timeline [1] with a list of hCal events:
>
> http://sixtwothree.org/simile/timeline-example.html
excellent! i did some work on something similar awhile ago.
http://suda.co.uk/projects/microformats/hcalendar/
-brian
--
brian suda
http://suda.co.uk
From mdagn at spraci.com Tue Apr 3 22:34:50 2007
From: mdagn at spraci.com (Michael MD)
Date: Tue Apr 3 22:34:55 2007
Subject: [uf-dev] hCard locations in hCalendar
References: <56475C7E-E022-4EFE-8521-CF05BE3D6D49@technorati.com>
Message-ID: <007201c7767a$f7baca50$116bacca@COMCEN>
> However, it turns out that, per RFC 2445, section 4.8.1.7, LOCATION can
> take an ALTREP parameter, which is "a URI that points to directory
> information with more structured specification of the location". So, in
> addition to the text, we can give a link to a structured representation.
Is this supported at all by the more common iCal clients?
If it is I would be VERY interested in it and certainly interested in ways
to transform it to/from hCal/hCard - I've been looking for ages for a good
way to specify cities and
countries without having to resort to looking for place names in freeform
text! (but it would need to work in real-world calendar software people are
using out there) - this is the main reason why I have not been able to
implement iCalendar publishing properly here! - the event listings here NEED
the city and country!
How would people enter such a location url in a calendar client?...
I don't think I ever saw any such option in Mozilla Sunbird (which is what
I'm mostly using to test iCal format stuff)...
maybe I'll try creating such an iCalendar entry manually to see how Sunbird
displays it.
> This brings up several issues.
>
> Assumption: if an agent is consuming iCalendar, they'd prefer to consume
> vCard, rather than hCard.
is it widely supported? ... I think Outlook can read vCard... but I gave up
trying to get it to read or write iCalendar
format for more than one event at a time (can this be done in Outlook?)...
> 1. How could a service like X2V handle this?
>
> * It could supply links (piped through X2V's vCard service) to a vCard
> for the location. Ex (from: http://austin.adactio.com/, @id added):
>
>
> Six,
>
> 117 West 4th St
>
>
>
> could be transformed to:
>
> > LOCATION;ALTREP="http://feeds.technorati.com/contacts/http://
> austin.adactio.com/%23six": Six 117 West 4th St
> Note that for cases where there is more than one hCard on a page, the
> fragment identifier is extremely useful (probably necessary).
>
> * it *could*, in theory, use multipart MIME. Has this ever been done
> for HTTP?
>
> 2. How can we specify this in our test suite?
>
> * MIME CIDs, though ugly, would keep things in one file
> * putting the vCards in separate vcf files. (not sure if ALTREP can take
> a relative URI, though. it should right?)
is this widely supported? ... I'm also looking for ways to represent other
fields that are not part of the normal iCalendar spec.
From ryan at technorati.com Wed Apr 4 10:06:27 2007
From: ryan at technorati.com (Ryan King)
Date: Wed Apr 4 10:06:34 2007
Subject: [uf-dev] hCard locations in hCalendar
In-Reply-To: <007201c7767a$f7baca50$116bacca@COMCEN>
References: <56475C7E-E022-4EFE-8521-CF05BE3D6D49@technorati.com>
<007201c7767a$f7baca50$116bacca@COMCEN>
Message-ID: <77BA9B1F-7306-4641-94E1-571F030A44A4@technorati.com>
On Apr 3, 2007, at 10:34 PM, Michael MD wrote:
>> However, it turns out that, per RFC 2445, section 4.8.1.7,
>> LOCATION can
>> take an ALTREP parameter, which is "a URI that points to directory
>> information with more structured specification of the location".
>> So, in
>> addition to the text, we can give a link to a structured
>> representation.
>
> Is this supported at all by the more common iCal clients?
I have no idea. I'd like to investigate that next.
> If it is I would be VERY interested in it and certainly interested
> in ways
> to transform it to/from hCal/hCard - I've been looking for ages
> for a good way to specify cities and
> countries without having to resort to looking for place names in
> freeform
> text! (but it would need to work in real-world calendar software
> people are
> using out there) - this is the main reason why I have not been able to
> implement iCalendar publishing properly here! - the event listings
> here NEED
> the city and country!
>
> How would people enter such a location url in a calendar client?...
> I don't think I ever saw any such option in Mozilla Sunbird (which
> is what
> I'm mostly using to test iCal format stuff)...
> maybe I'll try creating such an iCalendar entry manually to see how
> Sunbird
> displays it.
Apples iCal.app only allows plaintext in the location field (unless
I'm missing something).
>
>> This brings up several issues.
>>
>> Assumption: if an agent is consuming iCalendar, they'd prefer to
>> consume
>> vCard, rather than hCard.
>
> is it widely supported? ... I think Outlook can read vCard... but I
> gave up
> trying to get it to read or write iCalendar
> format for more than one event at a time (can this be done in
> Outlook?)...
I think there are a number of people who use iCalendar with X2V.
>> 1. How could a service like X2V handle this?
>>
>> * It could supply links (piped through X2V's vCard service) to
>> a vCard
>> for the location. Ex (from: http://austin.adactio.com/, @id added):
>>
>>
>> Six,
>>
>> 117 West 4th St
>>
>>
>>
>> could be transformed to:
>>
>> > LOCATION;ALTREP="http://feeds.technorati.com/contacts/http://
>> austin.adactio.com/%23six": Six 117 West 4th St
>
>> Note that for cases where there is more than one hCard on a
>> page, the
>> fragment identifier is extremely useful (probably necessary).
>>
>> * it *could*, in theory, use multipart MIME. Has this ever been
>> done
>> for HTTP?
>>
>> 2. How can we specify this in our test suite?
>>
>> * MIME CIDs, though ugly, would keep things in one file
>> * putting the vCards in separate vcf files. (not sure if ALTREP
>> can take
>> a relative URI, though. it should right?)
>
> is this widely supported? ... I'm also looking for ways to
> represent other
> fields that are not part of the normal iCalendar spec.
I'm not sure what you're asking. I'm talking about how we can
represent this in our test suite, which, AFAIK has nothing to do with
exising iCalendar implementations. This also has nothing to do with
representing fields that aren't part of the spec.
-ryan
--
Ryan King
ryan@technorati.com
From ryan at technorati.com Wed Apr 4 16:24:10 2007
From: ryan at technorati.com (Ryan King)
Date: Wed Apr 4 16:24:15 2007
Subject: [uf-dev] hCard locations in hCalendar
In-Reply-To: <56475C7E-E022-4EFE-8521-CF05BE3D6D49@technorati.com>
References: <56475C7E-E022-4EFE-8521-CF05BE3D6D49@technorati.com>
Message-ID: <4E7ADD41-4668-4D1F-9CB2-FA8A57EC43A3@technorati.com>
On Apr 3, 2007, at 11:51 AM, Ryan King wrote:
> 2. How can we specify this in our test suite?
>
> ....
> * putting the vCards in separate vcf files. (not sure if ALTREP
> can take a relative URI, though. it should right?)
Ok, I've tried this, hg patch at the end. Reasonable?
-ryan
# HG changeset patch
# User Ryan King http://theryanking.com/
# Date 1175728852 25200
# Node ID 89ff35bbc020622723c57c5ad4240c6d62d55e14
# Parent 74ebe092d7a664245360684bb43db779bdacb74f
first cut at hcard-location test
diff -r 74ebe092d7a6 -r 89ff35bbc020 hcalendar/20-location-hcard.html
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/hcalendar/20-location-hcard.html Wed Apr 04 16:20:52 2007 -0700
@@ -0,0 +1,22 @@
+
+
+
+
+ 20-location-hcard
+
+
+
+
Yuri's Night Bay Area
+
April 13, 2007, 4:30 pm
+
+
NASA Ames
+
+ Hangar 211 (Moffett
Field)
+ Mountain View,
+ California,
+ USA
+
+
+
Sudbury
|
but not :
Sudbury
|
Hence my comment the other day, about adding uFs to Wikipedia being more
complex than at first appears...
That's now in use on, only:
Interestingly, Operator, Tails and WebCards all recognise the second as
a valid hCard (the "Almost Universal Microformat Parser" returns 403
forbidden :-( ).
I think that's against the spec, but useful in limited circumstances
(see my recent, parallel, suggestion about recognising "alt" attributes
on images). Is it valid? If so, is that documented? If it's not valid,
should parsers reject it?
--
Andy Mabbett
From brian.suda at gmail.com Tue Apr 10 09:54:18 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Tue Apr 10 09:54:20 2007
Subject: [uf-dev] Class on TD, data inside anchor link in cell
In-Reply-To: <3wYnVaCcvfGGFwH4@pigsonthewing.org.uk>
References: <3wYnVaCcvfGGFwH4@pigsonthewing.org.uk>
Message-ID: <21e770780704100954n3da97747wbad9e2139ba252de@mail.gmail.com>
On 4/9/07, Andy Mabbett wrote:
> Interestingly, Operator, Tails and WebCards all recognise the second as
> a valid hCard (the "Almost Universal Microformat Parser" returns 403
> forbidden :-( ).
>
> I think that's against the spec, but useful in limited circumstances
> (see my recent, parallel, suggestion about recognising "alt" attributes
> on images). Is it valid? If so, is that documented? If it's not valid,
> should parsers reject it?
i'm not sure what you are refering too? is there a class="vcard" as a
parent anywhere? if not then this is definatly invalid! there MUST be
a parent class of 'vcard'[1] "A parser finds hCards in an (X)HTML
context by looking for elements with the root class name "vcard"... "
the fact that the class="fn org" is on the TD or the A in your
examples is irrelevant. Both the FN and ORG values are expecting
STRINGS the TD and A offer no special semantics and therefore will use
the nodeValues which in your examples are exactly the same, "Sudbury".
The TITLE attribute is onlyl used in the case of the ABBR element and
would be ignored no matter if the class="fn org" were on the A or the
TD.
[1] - http://microformats.org/wiki/hcard-parsing#finding_hCards
-brian
--
brian suda
http://suda.co.uk
From mdagn at spraci.com Tue Apr 10 20:53:06 2007
From: mdagn at spraci.com (Michael MD)
Date: Tue Apr 10 20:53:05 2007
Subject: [uf-dev] Class on TD, data inside anchor link in cell
References: <3wYnVaCcvfGGFwH4@pigsonthewing.org.uk>
<21e770780704100954n3da97747wbad9e2139ba252de@mail.gmail.com>
Message-ID: <004401c77bec$e9a2fe20$116bacca@COMCEN>
> On 4/9/07, Andy Mabbett wrote:
>> Interestingly, Operator, Tails and WebCards all recognise the second as
>> a valid hCard (the "Almost Universal Microformat Parser" returns 403
>> forbidden :-( ).
>>
>> I think that's against the spec, but useful in limited circumstances
>> (see my recent, parallel, suggestion about recognising "alt" attributes
>> on images). Is it valid? If so, is that documented? If it's not valid,
>> should parsers reject it?
I can see it could be useful ... but its the first I've heard of it...
(I guess this might be a bit like include-pattern - in terms of what the
parser would need to do - maybe the markup could be made similar to reduce
bloat in parsers? - perhaps using the td instead of object?)
From hober0 at gmail.com Mon Apr 16 14:05:16 2007
From: hober0 at gmail.com (Edward O'Connor)
Date: Mon Apr 16 14:05:39 2007
Subject: [uf-dev] Re: hCard locations in hCalendar
References: <56475C7E-E022-4EFE-8521-CF05BE3D6D49@technorati.com>
Message-ID: <86y7ksrpwz.fsf@rakim.cfhp.org>
Ryan wrote:
> Assumption: if an agent is consuming iCalendar, they'd prefer to
> consume vCard, rather than hCard.
This is somewhat unlikely. vCard and vCalendar had a shared parsing
model, but iCalendar deviates from it in several annoyingly incompatible
ways -- if someone has an iCalendar parser, it might not be terribly
useful for vCard parsing.
In related news, there's a method for embedding high-fidelity, "as
vCard-like as iCalendar will allow" location information into iCalendar
that is being worked on at CalConnect -- VVENUE[0]. VVENUE is, in
effect, a back-port of "hCalendar with hCard location field" to
iCalendar.
Assuming CalConnect and/or the relevant IETF WG(s) move forward with
this, there should be a very straightforward hCalendar+hCard ->
iCalendar+VVENUE transform available "soon."
Ted
0. VVENUE I-D here: http://www.ietf.org/internet-drafts/draft-norris-ical-venue-00.txt
--
Edward O'Connor
hober0@gmail.com
Ense petit placidam sub libertate quietem.
From ryan at technorati.com Mon Apr 16 15:07:04 2007
From: ryan at technorati.com (Ryan King)
Date: Mon Apr 16 15:07:10 2007
Subject: [uf-dev] Re: hCard locations in hCalendar
In-Reply-To: <86y7ksrpwz.fsf@rakim.cfhp.org>
References: <56475C7E-E022-4EFE-8521-CF05BE3D6D49@technorati.com>
<86y7ksrpwz.fsf@rakim.cfhp.org>
Message-ID: <7917C125-64D2-4E42-9EB7-018AEEDA1F1F@technorati.com>
On Apr 16, 2007, at 2:05 PM, Edward O'Connor wrote:
> Ryan wrote:
>
>> Assumption: if an agent is consuming iCalendar, they'd prefer to
>> consume vCard, rather than hCard.
>
> This is somewhat unlikely. vCard and vCalendar had a shared parsing
> model, but iCalendar deviates from it in several annoyingly
> incompatible
> ways -- if someone has an iCalendar parser, it might not be terribly
> useful for vCard parsing.
>
> In related news, there's a method for embedding high-fidelity, "as
> vCard-like as iCalendar will allow" location information into
> iCalendar
> that is being worked on at CalConnect -- VVENUE[0]. VVENUE is, in
> effect, a back-port of "hCalendar with hCard location field" to
> iCalendar.
>
> Assuming CalConnect and/or the relevant IETF WG(s) move forward with
> this, there should be a very straightforward hCalendar+hCard ->
> iCalendar+VVENUE transform available "soon."
>
>
> Ted
>
> 0. VVENUE I-D here: http://www.ietf.org/internet-drafts/draft-
> norris-ical-venue-00.txt
Yeah, I'd looked at that, and it looks to be exactly what we need. I
was hoping to figure out a way to solve the problem with existing
RFCs, though.
-ryan
From brian.suda at gmail.com Thu Apr 26 04:51:18 2007
From: brian.suda at gmail.com (Brian Suda)
Date: Thu Apr 26 04:51:22 2007
Subject: [uf-dev] Fwd: [uf-discuss] Text::Microformat - a uf parser for Perl
In-Reply-To: <20070425202053.GC5710@nearlyfree.org>
References: <20070425202053.GC5710@nearlyfree.org>
Message-ID: <21e770780704260451t3a89788jbba9012befb1e679@mail.gmail.com>
This was sent to the discuss-list, the dev-list would find this
interesting as well.
-brian
On 4/25/07, Keith Grennan wrote:
> Hello,
>
> Just thought I'd let everyone know about a new Perl module for
> parsing microformats.
>
> http://nearlyfree.org/introducing-text-microformat
>
> Text::Microformat is an extensible Microformat-parsing framework, which allows
> not only new kinds of microformats to be added, but also extension of the
> parser itself, so new parsing metaphors and source document encodings could be
> added.
>
> Features so far:
> * Extracting Microformats from HTML, XHTML and XML
> * Extracting Microformats from entity-encoded or CDATA sections in RSS feeds.
> * The include pattern
> * Microformats built from other Microformats
>
> Supported formats:
> * hCard
> * hGrant
>
> These are the only formats because they were required for the project
> I'm working on, but I'd love to see more formats supported.
>
> Project page: http://code.google.com/p/ufperl/
> CPAN page: http://search.cpan.org/perldoc?Text::Microformat
>
> Cheers,
> Keith
> _______________________________________________
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
--
brian suda
http://suda.co.uk