[uf-dev] Adding hCa* properties that aren't encoded in the HTML

[Tantek Ç elik]

On 12/3/05 12:14 PM, "brian suda" <brian.suda at gmail.com> wrote:

> In X2V there are afew minor tweaks we needed to included due to
> discrepencies between the RFC and the examples in the RFC. Namely, the
> FN, N issue. X2V will attempt to extract an N value from an FN value,
> that is because N is required, but examples omit this, so we attempted
> to get the best of both worlds.

Ah, but this isn't just because of the examples, but because this is by
design in the hCard specification.  Similarly with ORG.


> This leads me to my question...
> 
> Can/Should transforming applications add additional information NOT
> specified in the HTML, even if the data is the same, except in a
> different format/representation?

In general I would say no.


> Two examples with very different meanings:
> 
> LOGO/PHOTO can either be a URI or the BASE64 encoding. Now when X2V
> transforms the hCard to a vCard is does NOT attempt to convert a URI
> referenced image into its BASE64 representation. The apple address book
> has a spot for an image, but does not honor URLs, windows address book
> doesn't have any spot for images (atleast in my older version).

Right.

> So any
> URL reference to an PHOTO/LOGO is lost completely.

Rather, ignored, for now, by those clients.

I've already asked the Apple folks (Ernie?) to please file bugs against
their Address Book to support URL PHOTOs and LOGOs.


> If X2V DID convert
> image URLS to the base64 encoding, then atleast the Apple address book
> would include it,

It could be interesting at least as an option.

> but it adds complexity to X2V

Right, that's a good reason to potentially leave it out.

> and bloats the vCard.

Another good reason.


> GEO latutide and longitude points are not always included in an address,

Correct.

> but with the help of some web services it is possible to GET a LAT/LON
> for a given address.

Which unfortunately makes all sorts of assumptions about the precision of
that address, and the quality of the web service.


> This is an alternative representation of the
> address. Should /Can applications like X2V add LAT/LON if it is NOT
> already included?

IMHO no, because then the converting application is also adding the
abovementioned assumptions, and if one had to decided which to trust (the
ADR or the GEO), there is no way to tell which was from the content
publisher, and which was automatically generated.


> I see no harm in giving more value to the vCard.

There is no need to add it ahead of time.  Any consuming application can
perform that "look up" using a web service etc. itself.  Better to be lazy
about it.


> Am i missing something, or should transforming applications JUST deal
> with the exact data they are given?

In general that.

> I won't comment on my woes with
> Microsoft Office's attempts at being "helpful"

Indeed.  I find that 9 times out of 10 MS Office's "help" actually gets
things wrong AND slows me down.


> so i could see where
> making assumptions could be bad

Right.


> althought extracting a Lat/Lon from an
> address is not an assumption really.

It makes assumptions about the quality of the service being used to do the
lookup, and makes all sorts of assumptions about *where* on the address does
the Lat/Lon reflect?  Addresses are polygons/regions, whereas Geos are
points.  They're not the same thing.


> The reason i brought this up, is a simple application/idea i have been
> kicking around. This would extract a vCard from an hCard, then pass the
> Lat/Lon to another webservice API and map those points to something like
> Google Maps. So conceivably, a conference webpage with all the speakers
> marked-up with hCard could EASILY be converted to push-pins on a map,
> all with one bookmarklet and alot of webservices.

Indeed, but one wouldn't even have to convert to vCard to achieve that.  If
you're going from web-to-web (list of hCards page to map of hCards page)
then there is no need to go through the vCard translation.

Thanks,

Tantek