I just had two immediate thoughts, none of whick really effect this idea, i just wanted to get them out there documented.
1) The current GEO property has to have sub-properties of class="latitude" and class="logitude" this is lost if they get moved into the ABBR title. (which is OK because there is the RFC that describes the proper way to describe the order etc) so this is really a non-issue unless there is some hard-core geo-caching folks out there who think ALTITUDE is a requirement as well? vCard can't handle it, so i'm not sure what we do in any case.... 2) i know awhile ago i brought-up the idea of using a web service to get the LAT/LONG from an address and adding GEO to a vCard if none was present. This was rejected because an address is a polygon (your house/office is not a point in space, but actually a shape on the X/Y plane) So when we are using the ABBR element to say this point is an abbreviation of this space, is that correct? I think it is an acceptable solution. I have coded-up X2V to handle GEO in <abbr>, it is only running locally, but in the few tests it is working fine and make sense. By simply wrapping your class="adr" elements in an <abbr class="geo" ... adds value (but is it hidding metadata?) -brian On 3/4/06, Tantek Çelik <[EMAIL PROTECTED]> wrote: > On 9/23/05 10:00 AM, "Tantek Çelik" <[EMAIL PROTECTED]> wrote: > But to do this we must specify a syntax for putting both the latitude and > longitude into the title attribute as the machine-readable-geo-info. > > Fortunately, there already is a syntax for that, in vCard RFC2426 3.4.2: > > <abbr class="geo" title="37.386013;-122.082932"> > Mountain View, CA > </abbr> -- brian suda http://suda.co.uk _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
