Re: [apps-discuss] Feedback on draft-wilde-profile-link-00

[Erik Wilde <[e-mail]>]

hello mark.

thanks a lot for the feedback! i am cross-posting this response to 
[e-mail], because it may be interesting for that 
community as well. too bad that the IETF drafts don't have commenting 
support on the IETF page itself, that would be really useful!

On 2012-04-05 09:25 , Mark Nottingham wrote:
> Overall, I'm really happy to see this draft; have been considering doing something along these lines too.
> *** Major issues
> * "Resource Profiles" - this spec defines the profile is being about the *resource* of its context. This is too loose; in HTML and other uses I've seen, profiles are about the *representation* they occur within.

actually, most of the abstract talks about the profile qualifying a 
representation, but you're correct that this should be made very clear, 
and that it should be about the specific representation containing the 
profile link. i'll rewrite all the places where the text says that 
profiles are about resources.

> In other words, the common idea of a profile, IME, is that it describes the conventions, extensions, etc. that are used in a particular document, but it doesn't say anything about the resource that the document was retrieved from.

yes, that is how it should be. only that i really would not want to say 
"describes" here, to clearly avoid the expectation that a 'profile' link 
MUST resolve to some sort of description. i'd say it "identifies" 
conventions, extensions, etc., and the only dependable operation on a 
'profile' link is to compare the URI to known profile URIs.

> That's a good design, because link relations are already a defined mechanism to talk about resource behaviours; having two such mechanisms isn't a good idea (at least without some discussion).
> E.g., when I interact with a resource, I know it supports particular behaviours, because it's been linked to with relation "Foo." When I get a representation from the "Foo" resource, it will have a media type that describes the format, and also a profile ("Bar") that describes additional features / conventions of that document (such as a particular use of JSON or XML), but that profile won't -- and shouldn't! -- be an additional way of describing the behaviours of the "Foo" resource.

now i am little bit confused. taking your example, i am not concerned 
with the link relation that was used to discover 'foo' at all. all i am 
concerned with is that if i am retrieving 'foo' and i find a 'bar' 
profile identifier in the representation, i know that it follows 
constraints and conventions beyond the 'foo' media type. one example i 
am currently considering adding is atompub. currently, when you retrieve 
a feed, there's no way to tell it's atompub-capable just by looking at 
it. that could be easily remedied by adding a 'profile' link identifying 
the support of atompub. that's the kind of scenario i have in mind, but 
it sounds to me you're thinking about something else, or am i just 
misunderstanding you?

> *** Nits / minor feedback:
> * """This link relation type is independent of the resource representation it is used in (but the representation must support types links for this mechanism to work)"""
> I'd state this in terms of "context", as per the link RFC.

"This link relation type is independent of the context in which it is 
used (however, the representation must support typed links for this 
mechanism to work)"

> * s/must support types links/must support typed links/

done.

> * """
>     In fact, for the purpose of this
>     specification, the URI does not necessarily have to link to a
>     dereferencable resource, and clients can treat the occurrence of a
>     specific URI in the same sense as a namespace URI and invoke specific
>     behavior based on the assumption that a specific profile URI signals
>     that a resource follows a specific profile.
> """
> Here, I'd state this in terms of "target URIs", as does the link RFC.

"In fact, for the purpose of this specification, the target URI does not 
necessarily have to identify a dereferencable resource (or even use a 
dereferencable URI scheme), and clients can treat the occurrence of a 
specific URI in the same way as an XML namespace URI and invoke specific 
behavior based on the assumption that a specific profile target URI 
signals that a resource representation follows a specific profile."

> * Your Security Considerations section isn't going to pass muster; if it were me, I'd talk about how software shouldn't make security-sensitive assumptions based upon profiles.

any specific suggestions on how to phrase that? ;-)

> *"""
>     As one example, consider the case of podcasts, a specific kind of
>     feed using additional fields for media-related metadata.  Using a
>     'profile' link, it would be possible for a client to understand that
>     a specific feed is supposed to be a podcast feed, and that it may
>     contain entries using podcast-specific fields.  This may allow a
>     client to behave differently when handling such a feed (such as
>     rendering a UI), even when the current set of entries in the feed may
>     not contain any podcast entries.
> """
> This is an interesting use case. My use cases for "profile" tend to be things like "links that this document contain follow *this* convention". More examples would be good.

to me, it's both about those links and about conventions followed in the 
document itself. i am currently planning to include three examples in 
the next version of the draft:

- HCard
- Dublin Core
- AtomPub

particularly this last one might be what you're looking for, right? if 
you have any suggestions what to add to this list, please let me know.

thanks a lot for the feedback! i'll continue working on the examples, 
and as soon as these are finished, i am planning to publish -01 and see 
whether the additional examples make it easier to understand what this 
draft is trying to accomplish, and there might be more feedback.

cheers and happy easter everybody,

dret.

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