Fwd: follow up on link rels...
mca
I spoke about my "appropriate link rels" issue w/ Tim Williams this
week while we are attending OSCON.
He reminded me that he brought up this very issue on REST-DISCUSS
about a year ago.
I'm looping in his message in hopes that it adds a bit to the discussion.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
#RESTFest 2011 - Aug 18-20
http://restfest.org
---------- Forwarded message ----------
From: Tim Williams <willi...@gmail.com>
Date: Wed, Jul 27, 2011 at 09:17
Subject: Re: follow up on link rels...
To: mca <m...@amundsen.com>
Hey Mike,
I've realized now that I think you're struggling with the same thing
that I struggled with a while back - that is, link selection criteria
when there is no relationship between the current and target resource.
In other words, when the client would want to select the link based
on criteria other than the relationship. Here's the thread that I
tried to articulate my question in some time ago:
http://tech.groups.yahoo.com/group/rest-discuss/message/15287
If you have more time available today before you leave for MS, lemme
know if you'd like to discuss....
Thanks,
--tim
On Tue, Jul 26, 2011 at 11:18 PM, mca <m...@amundsen.com> wrote:
> tim:
>
> i submitted a set of rel values to microformat.org today and got some
> feedback from @tantek (Celik). thought you'd like to see it.
>
> http://krijnhoetmer.nl/irc-logs/microformats/20110727#l-13
> <snip>
> # [00:58] <@tantek> however the use of "collection" and "maze" don't
> make sense IMHO as rel values
> # [00:59] <@tantek> because they are not relative relations to the
> current document
> # [00:59] <mamund> hmmm
> # [00:59] <mamund> i see
> # [00:59] <@tantek> e.g. rel="collection" to me would mean a
> collection of things in which the current resource is a member/item of
> the collection
> </snip>
>
> i can see his point and am re-thinking some of my use of rels in my
> generic designs.
>
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
>
> #RESTFest 2011 - Aug 18-20
> http://restfest.org
>
Tim Williams
It seems that while the class attribute's formal introduction does
coincide with CSS - it's definition provides the flexibility for it to
be used as link selection criteria. Unfortunately, it's not a
media-type independent solution in the same way that a link relation
is - maybe that's a gap?
""The class attribute, on the other hand, assigns one or more class
names to an element; the element may be said to belong to these
classes. A class name may be shared by several element instances. The
class attribute has several roles in HTML:
o) As a style sheet selector (when an author wishes to assign style
information to a set of elements).
o) For general purpose processing by user agents."
http://www.w3.org/TR/1998/REC-html40-19980424/struct/global.html#h-7.5.2
Thanks,
--tim
Mike Kelly
--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To post to this group, send email to hyperme...@googlegroups.com.
To unsubscribe from this group, send email to hypermedia-we...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hypermedia-web?hl=en.
mca
There is another thread[0] that I started this week that outlines the
details of the Maze+XML[1] design issue that prompted this discussion.
Essentially, when I logged the link-rel values[2] from that registered
type to the Microsoformats.org site[3], the response was that some of
my values were "an abuse of @rel" since they could not be expressed as
"relationships", but were instead simply "things."
As a reference, the Web Linking RFC (5988) gives guidance on this in
Section 3[4]:
<quote>
A link can be viewed as a statement of the form "{context IRI} has a
{relation type} resource at {target IRI}, which has {target
attributes}".
</quote>
At least one of my link-rel values for the Maze+XML media type
("maze") fails to meet that criteria. I've implemented a number of
other designs over the last year that also use "things" as link-rel
values rather than relationships.
I'm working on some text that explores this a bit more, but have not
yet completed the piece. I'll proly post it to this list later today.
Any and all feedback is most welcome.
[0] https://groups.google.com/forum/#!topic/hypermedia-web/1LjRGqolZyw
[1] http://amundsen.com/media-types/maze/
[2] http://amundsen.com/media-types/maze/format/#link-relations
[3]http://microformats.org/wiki/existing-rel-values
[4] http://tools.ietf.org/html/rfc5988#section-3
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
#RESTFest 2011 - Aug 18-20
http://restfest.org
William Martinez Pomares
I'm taking this snips [1] as examples.
1. Class is one of those attributes doomed to be associated to the first use more that to the actual definition of it. Class is to indicate the class of element, a second level specialization, given the majority are generic types (a link is a link, but we may have different link classes :D )
2. The rel is defined as a description of "the relationship from the current document to the anchor specified by the href attribute". So, rel is totally document related.
Mike, do you remember all our conversations about control, status and the actual different semantics you may have in one document? One thing is the lower, document format interaction and the other one was the higher, business level interactions. So, the document may need to contain a mix of different semantics, that the actual client should consume using different components.
Well, in this case, one thing is the actual maze navigation (which I feel it falls more into the business field of the sample) and another one the manipulation of list of mazes (which may fall into the lower implementation control). So, we are facing here a problem of how to identify that level of semantics.
As I mention in point 2 above, the rel defines a relationship to the whole document. Now, that document represents one resource and the links found in the document may represent other resources. That means the rel is a relationship indication between the current resource and the other ones the link identifies. On the other hand, class refers not to the document, but to the element.
So, the third component we must check when consuming control data is the actual element. In the examples I do not see a rel="collection" but a Collection element. Just the name of that element is telling me this is an implementation control data. The actual rel="maze" may make no sense or be unnecessary as the client may expect a maze collection.
The other thing that looks odd, is that we have several little examples. Just as if we have one media type, but several subtypes of documents. If that is so, I would add a class attribute to the root (<maze>) element to identify the document subtype.
Finally, not all links may need a rel. If the linked resource has no relation to the current resource, a rel may not be specified and the control information of why/what for should I follow that link should be extracted of implied from the current structure of element (a collection element of class="maze" full of links is enough info for me).
Thoughts?
1. http://amundsen.com/media-types/maze/examples/
mca
thanks for your comments. i esp. appreciate you inspecting the samples
and provided feedback.
first:
<snip>
In the examples I do not see a rel="collection" but a
Collection element. Just the name of that element is telling me this is an
implementation control data. The actual rel="maze" may make no sense or be
unnecessary as the client may expect a maze collection.
</snip>
yes, this *particular* design would probably be better if i had used
<collection ... /> instead of <link rel="collection" .../> and <maze
... /> instead of <link rel="maze" ... /> there are a couple reasons
(at the time of initial design and implementation) that lead me to
this decision and it was a mistake. now that i've reg'd the media
type, i'll soon be doing a blog post on safely modifying an existing
media type<g>.
in addition.... this problem is not limited just to this design.
implementing designs in [X]HTML will face the same challenge.
<snip>
So, we are facing here a problem of how to identify that level of semantics.
</snip>
Yes, i can see that POV. i often work to keep clear "levels of
abstraction" (as you know in some of our convos) and i see the
possibility that some elements (previous, next, first, last, etc.) may
be general elements and others (user, account, invoice, maze, etc.)
may belong to another level of abstraction (application problem
domain). it is possible that certain design details (@rel) should be
reserved for expressing "general abstractions" and others (@class?,
@name? @id?) should be reserved for expressing "app-level
abstractions."
this is the type of discussion i'd like to promote here.
the current RFCs seem to highly constrain the use of @rel, the current
HTML specs seem to offer a very wide interpretation in the use of
@class and @name. it is also possible that the HTML semantics should
be the only POV when designing media types using other formats (e.g.
XML, JSON, etc.).
thanks again.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
#RESTFest 2011 - Aug 18-20
http://restfest.org
Mike Kelly
On 28 Jul 2011, at 05:25 PM, William Martinez Pomares <wmar...@acoscomp.com> wrote:
> 2. The rel is defined as a description of "the relationship from the current document to the anchor specified by the href attribute". So, rel is totally document related.
A link relates its target however the given media type specifies, surely? E.g. If I have an embedded resource which in turn contains a link.. The link relates the embedded resource and not the full containing document.
Cheers,
Mike
William Martinez Pomares
On Jul 29, 6:16 am, Mike Kelly <mikekelly...@gmail.com> wrote:
>
> A link relates its target however the given media type specifies, surely? E.g. If I have an embedded resource which in turn contains a link.. The link relates the embedded resource and not the full containing document.
>
Just in case, I'm just reproducing the spec words. Now, the
interesting point here is the spec refers to the document, not to the
resource, so the rel is more about format control than business
control. Failure in the spec?
I assume any document is the representation of a resource. So, the
notion of "embedded" resources does not fit at first.
Unless of course we are talking about a resource that acts as a
collection of other resources. In that case, the representation may
contain the contained resources' representations, or links to them.
The scope of the @rel is defined in a global way. The @rel would had
been relating the linked resource to the actual element, in case the
element is not the common generic link, but any other element
containing an href, or to the parent element in the link case.
Unfortunately, it was defined globally. Link was actually defined as a
global element as it can only appear in the headers for HTML. Using it
in any other document may give us the freedom to release it from those
restrictions, using it anywhere and adjusting the @rel scope.
William Martinez Pomares.
Mike Kelly
Is this 'ok'? Personally, I look at this as a feature
Cheers,
Mike
Sent from my iPhone
mca
I have these "thing-style" rels in both of my reg'd types (Maze+XML
and Collection+JSON) and i don't plan on changing them any time soon.
I am, however, thinking about modifying future designs (including the
un-reg'd ones I do w/ clients).
One thing I recall, Ian Robinson once called me out for using a design
that had *verbs* as rel values (my RESTBucks sample in my blog[1]).
I can see that verbs are "bad" since they make it easy to start
creating "RPC-style" designs. I wonder if "thing-style" rels do the
same thing; promote "RPC-thinking." maybe that's a reason to keep
strictly to the rel guidance that one should only use words that
easily fit into the suggested sentence structure[2]:
<quote>
A link can be viewed as a statement of the form "{context IRI} has a
{relation type} resource at {target IRI}, which has {target
attributes}".
</quote>
Of course, one way to *avoid* most of this is to simply use Link
Relations Extensions[3]. No need to register and no need for "pedants"
to complain about the word you picked as the link rel value<g>.
[1] http://www.amundsen.com/blog/archives/1101
[2] http://tools.ietf.org/html/rfc5988#section-3
[3] http://tools.ietf.org/html/rfc5988#section-4.2
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
#RESTFest 2011 - Aug 18-20
http://restfest.org
William Martinez Pomares
I guess the most important problem, even beyond the "RPC-Thinking", is
the semantic identity loss of @rel. That is, you may expect a relation
and you find a thing type/name.
But anyway, I agree totally with all Mike is saying. I specially think
of specs to be not as perfect as we may like. I believe that, when a
spec does not satisfy reality, spec is the one that must be changed. And
my point in this case is that we may not even need @rel is we can induce
the type from the containing elements. TO me rel is am aid, not a
requirement.
BTW, Mike, I hope you are not referring to me when you mention pedants
:S I usually stick to definitions as I feel they are important to be
clear in communication, but I'm as flexible as a bamboo to allow
exceptions that totally make sense.
Cheers!
William
mca
<quote>
BTW, Mike, I hope you are not referring to me when you mention pedants :S I
usually stick to definitions as I feel they are important to be clear in
communication, but I'm as flexible as a bamboo to allow exceptions that
totally make sense.
Two things:
1) i did not have you in mind when using the moniker "pedants"
2) i, personally, do not see the label "pedants" as a derogatory term.
I know most all definitions of the term offer an unflattering
description; sorry if i offended anyone by using the term. My point
here was to say that there are some who are *very focused* on the spec
and on proper use of the spec. to me these are important POVs. I was
trying to express the idea that, IMO, it would be nice if a solution
could satisfy both the "pragmatists" (trying to get something done
today) and the "pedants" (trying to keep the implementations clear of
willful violations).
that's all.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
#RESTFest 2011 - Aug 18-20
http://restfest.org
On Sat, Jul 30, 2011 at 14:56, William Martinez Pomares
mca
<sorry for not following up sooner>
i've gone over a few of my designs here and see a couple things:
1) in the case of Domain-Specific style designs, it makes sense (to
me) to, whenever possible, use domain-specific elements that
self-identify; tehreby obviating the need for @rel decorations:
<queries>
<pending-orders href="..." title="View Pending Orders" />
<closed-orders href="..." title="View Closed Orders" />
<open-orders href="..." title="View Open Orders" />
</queries>
2) in the case of non-HTML general or agnostic designs, it makes sense
to carry the link identifier in a different property or attribute:
{"queries" :
[
{"name" : "pending-orders", "href" : "...", "prompt" : "View
Pending Orders"},
{"name" : "closed-orders", "href" : "...", "prompt" : "View Closed Orders"},
{"name" : "open-orders", "href" : "...", "prompt" : "View Open Orders"}
]
}
3) in the case of [X]HTML designs, i see two possible solutions:
a) use @class attribute to carry problem-domain information and only
use @rel for generic details (paging, etc.)
<ul class="queries">
<li><a href="..." class="pending-orders" rel="related">View Pending
Orders</a></li>
<li><a href="..." class="closed-orders" rel="related">View Closed
Orders</a></li>
<li><a href="..." class="open-orders" rel="related">View Open Orders</a></li>
</ul>
b) use @rel extensions that are specific to your application domain
<ul class="queries">
<li><a href="..." rel="related;amundsen=pending-orders">View Pending
Orders</a></li>
<li><a href="..." rel="related;amundsen=closed-orders">View Closed
Orders</a></li>
<li><a href="..." rel="related;amundsen=open-orders">View Open Orders</a></li>
</ul>
c) simply engage in "willful violation" and continue to use
"thing-style" values for @rel:
<ul class="queries">
<li><a href="..." rel="pending-orders">View Pending Orders</a></li>
<li><a href="..." rel="closed-orders">View Closed Orders</a></li>
<li><a href="..." rel="open-orders">View Open Orders</a></li>
</ul>
I am confident that the first two cases (domain-specific and non-HTML
generic) are solid reasoning and will work well for existing use cases
I have encountered.
I am still a bit fuzzy on the best approach for HTML cases.
My disappointment w/ the @class option is that client "engines" will
need to learn to look in two places for domain information on links
(@rel="next-page", @class="list-of-orders", etc.). it would be nice to
see this information in a single place: (@rel="next-page
list-of-orders").
My concern with the extension approach is that i've not seen this in
the wild (it is mentioned in RFC5988) and have no direct experience
with it when designing media types or writing clients.
My issue w/ the "willful violation" approach is that it flies in the
face of existing documentation. Documentation that I am not confident
will be changed any time soon.
Essentially, this all boils down to a conundrum regarding a single
existing media type: HTML. In other cases, I think the guidance is
reasonable and can be applied consistently.
Of course, I'd like to hear any feedback this "assessment"
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
#RESTFest 2011 - Aug 18-20
http://restfest.org
Mike Kelly
Sent from my iPhone
On 31 Jul 2011, at 07:12 PM, mca <m...@amundsen.com> wrote:
>
> My issue w/ the "willful violation" approach is that it flies in the
> face of existing documentation. Documentation that I am not confident
> will be changed any time soon.
Are there actually any negative side effects of this wilful violation?
Cheers
Mike
William Martinez
For that to happen, the violation should, at least to me, make sense and also needed. So I guess the discussion should go that way: what alternatives there are and which is better.
Sent from my iPod
mca
Yes, I agree; let's focus on the alternatives (and weigh them).
1) For non-HTML domain-specific designs, simply skip the use of any rels:
<user href="..." /> instead of <link rel="user" href="..." />
{"user" : {"href" : "..."}}; instead of {"link" : {"rel" : "user",
"href" : "..."}}
2) For non-HTML generic designs, use some property/atttribute _other_ than rel:
<link name="user" href="..." />
{"link" {"name" : "user", "href" : "..."}}
3) For HTML generic designs
a) Use @class:
<a href="..." class="user" >...</a>
b) Use @name
<a href="..." name="user">...</a>
c) Continue to use @rel
<a href="..." rel="user" >...</a>
COMMENTS:
- HTML A, LINK, and AREA elements are the only ones affected by this
problem. FORM does not support "rel." FORM.name and/or FORM.class will
need to be used.
- A.class seems to fit both the user-agent needs and any design
author's needs w/o immediate negative affects on user agent behavior
(only slight overloading, but well in line w/ Microformats anyway).
Using @class also has the added effect of segregating "app-level"
domain information _away_ from @rel and leaving @rel for generic media
type needs such as paging, alternate representations, and other
registered "universal" @rel values.
- A.name has the possible disadvantage of causing common browsers to
treat the @name value as an internal anchor which may be unintended in
the author's design (also causes some "overloading" of that
attribute).
- A.rel is a "well-known" pattern that many will recognize (even if
the "thing" designation is off-key according to specs). There is
little chance of encountering unintended overloads w/ common
user-agents (browsers), but there is a risk of "semantic confusion"
for those who wish to keep "universal" and "app-specific" values
segregated. Continuing to use @rel for "thing" style decorations can
be seen as a "willful violation" of the spec (HTML). RFC5988.Sec4
offers some support for a "service" style lin-rel-value, tho.
There may be other options. I'm open to feedback.
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me
#RESTFest 2011 - Aug 18-20
http://restfest.org
Moore, Jonathan (CIM)
I think I agree with (1) and (2). For HTML designs, I don't like the @name
use, because this precludes having more than one <a> or <form> show up
with the same relation. For example, if I have a list of items (<ul>) then
I might want to have @rel="edit" links (or forms) that are different for
each <li>.
[As an aside, by the way, there are examples in the wild of "thing"-style
rels:
<link rel="stylesheet" ...>
<link rel="shortcut icon" ...>]
So I wouldn't hesitate putting in the most obvious semantic relationship
in a @rel attribute, and this works well for <a> and <link> tags as that's
where existing clients already look for these things. [1]
However, as you note, <form>s don't have @rel attributes, so I think the
best you can do now is to put it in a @class (because of the one-only
restriction on @name). You have to look for your links and forms in
different attributes then, but you have to construct the requests for
those differently anyway, and my experience is that it isn't so bad.
Summary: use @rel for <a> and <link>, use @class for <form>.
Perhaps the right thing to do, though, is to suggest that @rel be added to
<form> for future versions of XHTML.
Jon
[1] I seem to recall another thread that claimed that a @rel attribute
should represent the relationship of the target to the whole current
resource, but I disagree. For example, "edit" links are contextual in,
e.g. Atom feeds (like GData uses). For XHTML, I think <link> @rels are
related to the whole current resource, but <a> @rels are contextual.
........
Jon Moore
Comcast Interactive Media