Re: [apps-discuss] draft-wilde-profile-link-01 published

[Erik Wilde <[e-mail]>]

hello walter.

On 2012-04-16 08:07 , Goix Laurent Walter wrote:
>> thanks for the pointer to web finger. i am sure there are quite a
>> number
>> of other formats out there using html profiles, maybe it would be
>> interesting to create a small list of "well-known" profiles.
> [walter] some work in that direction has been already recorded here [1] that you may want to check

these are link relation types and not profile identifiers, right? i am 
a bit concerned to see expected media types encoded in link relations, 
for example i'd prefer to see a "contact" link type and then getting a 
vCard or an xCard or HTML-embedded hCard is up to conneg and thus a 
runtime issue. doing it that way frees you from having to mint new link 
relation types when you want to support new media types (what about FoaF 
contact info, for example?).

> [walter] maybe i wasn't clear enough I apologize. I was indeed referring to the "type" attribute/parameter of the "link" element/header, which is already defined both in RFC5988 and in XRD for referencing the media-type associated with that link. In that sense an hcard link rel would typically be "text/html" whilst a poco#me representation of the "profile" link could be "application/json".

and that doesn't really help at all. for it to be helpful, the profile 
description language would need to have a media type, and then you could 
identify it by that. and generally speaking, a 'profile' link should not 
need to be dereferenced to be useful, it's an identifier. that also 
means that designing an environment where runtime lookup of the profile 
description is necessary would be a violation of the spec, because 
clients would not be able to "understand" that the meaning of a profile 
URI changes over time. this almost automatically means that any updates 
in the profile need to done by minting a new profile URI, and if it is 
done backwards compatible, then representations conforming to the new 
profile should list both profile versions:

<link rel="profile" href="http://microformats.org/profile/hcard"/>
<link rel="profile" href="http://microformats.org/profile/hcard/2.0"/>

> However I do understand that this may not be enough for correctly characterizing the format of the specific profile information: how would I indicate in fact that this "profile" link/web page is hcard-enabled or not a priori? Same for json: poco is a popular json format for representing profile info but may not be the only one.

if there is a format for describing profile information, then it should 
have a media type and then web clients can use that media type. just 
referring to it as JSON is not very helpful. but even if there was such 
a media type, it would not change the fact that the way how 'profile' is 
drafted right now, runtime access to profile descriptions is not part of 
the design; clients compare supported profile URIs to the profiles they 
find in a representation, and then decide what to do.

> My point is I may have the following xrd at this stage with the profile rel links:
> <Link rel="profile" type="text/html" href="http://example.com/profiles/joe" />
> <Link rel="profile" type="text/html" href="http://example.com/profiles/joe/hcard" />
> <Link rel="profile" type="application/json" href="http://example.com/profiles/joe/poco" />
> ...without any clear view on which "profile" provides which format.
> I hope I have clarified my point here and welcome your feedback on this.

now i am getting the impression that you're having some misconceptions 
about profile. profile links are not intended to link to particular 
resource that contains data of interest to the client. in your example, 
the page would be about joe, and joe might decide to embed his 
information using hcard, and then the page would say

<link rel="profile" href="http://microformats.org/profile/hcard"/>

and clients could extract joe's hcard info from the page without ever 
accessing http://microformats.org/profile/hcard; they would simply see 
that URI and then, if they supported hCard, understand that the page 
contain embedded hCard information.

i hope that clarifies things a bit. cheers,

dret.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |