Re: Should (some of the) ContactField objects use URLs rather than free-form strings?

Le mercredi 01 juin 2011 à 23:27 +0200, Robin Berjon a écrit :
> I know that adding a |uri| attribute that is only present when the URI
> could be correctly inferred addresses that part. But it's still a
> problem. It means that we need to specify the heuristics — for they
> will be heuristics in some cases — that map from possibly arbitrary
> values to URIs.

I guess you're right we would have to define those; I think the work is
minimalistic for photos and urls, and probably for emails. The algorithm
would be:
* parse the URL as defined in HTML5
http://dev.w3.org/html5/spec/urls.html#parsing-urls
* if the parsing fails, abort
* otherwise, stick the value in the uri attribute

(emails would have to be appended with a mailto: scheme prior to that
treatment)

>  I'm not saying it's necessarily huge work, but it's extra stuff. And
> we also need to require that implementations validate those URIs. In
> some cases, that's more of a burden than meets the eye.

Do you have anything specific in mind?

> > That's probably true for ims and phone numbers:
> > * ims, because the type of instant messaging is not always recorded with
> > the data, and when it is, it's not necessarily in a way that can lend to
> > be turned into a URI scheme (when one exists)
> 
> I think that handling IMs is very likely impossible in the general
> case. I'd really rather we didn't try for these.

Yeah, I agree it's probably too hard for too little benefit.

> > * phone numbers, because they need to be complete enough to be turned
> > into URIs (e.g. they need the international calling code?), and they may
> > also contain non phone number information (e.g. manually indicated
> > extension number)
> 
> Actually, they don't. The tel: scheme allows for an awful lot of
> variations, and my understanding is that that includes partial
> numbers. That being said, it is a complicated scheme that would have
> to take care of things like extensions, and a bunch of other aspects
> that I believe are more complex than I feel comfortable with.

I could live with leaving that one alone for now as well.

> > It seems to me that these concerns don't apply to emails, photos, and
> > urls (!).
> 
> For photos I think it's an easy win. The current draft has Base64 or
> URI. We could just have URI, indicating that if it's Base64 it can be
> a data: URI (and it could also be a blob: URI).

Photos are clearly my #1 request; having a field that can have both URLs
and binary-encoded-data-but-not-a-data-URL seems like non-sense.

> For the others, I'm still not convinced :)
> 
> With email, what's the value of getting mailto:foo@bar.com over
> foo@bar.com? The extra processing required to ensure that the former
> is valid in the face of user error seems a high price to pay to me.

Well, it seems to me that this price has to be paid sooner or later if
these fields are going to be used; the number of usage of email
addresses that doesn't include linking (or sending a message via our
beautiful Messaging API) seems limited.

>  We'd also have to handle issues such as what to do if the user enters
> foo@bar.com?subject=blah into their address book. I'm not at all
> saying that's impossible, but it's a number of extra conformance
> requirements, more testing, etc. It does raise the bar for
> implementation more than it seems to be worth.

I appreciate that it raises the bar for implementation; I'm not entirely
convinced that it is more than it is worth.

> As for URLs, I don't see that it's a given. We have to think about
> round-tripping even if we don't support it directly (yet).

I don't think we need to think about it if we keep dual value/url
properties.

>  There are two options to convert user-entered URLs into proper URLs
> when they aren't (users often drop the "http://"): modify the value
> directly, or keep the value as is and add a corrected uri field. Again
> the issues with testing, heuristics, etc. crop up. But we also have to
> think about updates. What if I put two completely different values in
> there? How does it get serialised?

I don't understand what you mean here.

> All in all, given that it can be handled in script with minimal
> trouble, I think that we should change photos and keep the rest as is.

I can live with that solution as long as photos is fixed. I guess we
could always add the URL processing to a later version if needed; I'm
hoping we're not under-delivering, though.

Dom

Received on Monday, 6 June 2011 07:46:21 UTC