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

[Goix Laurent Walter <[e-mail]>]

Thank you erik for your clarifications. Indeed my first reading of the draft was biased into another understanding of the "profile" keyword, related to user/resource "profile" representation format. I have now clear that this is not the purpose of this draft.

As I understand it now his link type is thus to be typically included in the documents themselves to better describe their own format (just like the html "profile" you mentioned).

I am biased by the current discussion/activity going on wrt resource discovery (see thread on webfinger vs swd) that relies on "similar" links within a descriptor to "discover" endpoints of certain types to access different information related to a user. One of these links which is quite popular is the "http://webfinger.net/rel/profile-page" that links to a user profile description, but that doesn't indicate "your" type of profile. In other words that type of link does not allow you to know in advance whether that page contains hcard information or others. In the discovery use case this is useful as based on that information I could avoid accessing that endpoint (and read the "profile" link type in it) to understand the specific type/format of information it contains.

walter

> -----Messaggio originale-----
> Da: Erik Wilde [mailto:[e-mail]]
> Inviato: lunedì 16 aprile 2012 14.11
> A: Goix Laurent Walter
> Cc: REST Discuss; application-layer protocols
> Oggetto: Re: draft-wilde-profile-link-01 published
>
> 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 |

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.