[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: link relations and links in general
For the purposes of read-only usage, what we have with link relations
is good enough for identifying semantics. You follow a link and issue
a GET request and boom.. you get what you asked for.
The IANA link registry is a good enough place to hold this
information, although it may be made even more easy to manage than to
write to iana-assign for a new assignment. Whether that is a Wiki or
something else, that could be discussed.
Oracle is certainly interested in putting together some kind of
adjectives on Atom resources so that we can better predict the kind of
operations that can be performed. For example, the edit and edit-media
relations actually mean something beyond other link relations because
I can actually manipulate those resources.
Likewise, the hierarchy-ID attempts to define a few new semantics for
Atom resources that are, for lack of a better word, highlighted as
being "master" or "detail" resources. The IETF RFC list is as good a
place as any for recording these adjectives and the meanings of these.
If there is a way to annotate link entries with such additional
semantics so that we can use them even when people create separate rel
values, we would love it.
Of course, I am approaching this from the perspective of a general
library that wants to interpret standardized Atom extensions so that
we can play a role when we are disconnected from the server. My blog
talks a lot about this in the context of AtomDB [1].
Curious to hear what others think. Thanks to Eric for bringing this up
and looking at it from a different angle.
Nikunj
On May 14, 2009, at 11:18 AM, Erik Wilde wrote:
hello.
i know this is a bit off-list, but i am looking for pointers and
thoughts and opinions, so i thought i'll give it a try anyway...
the recent discussions around link relations indicate a general
interest to identify link semantics, right? and there seems to be a
more general issue of not only identifying link semantics, but maybe
generally possible RESTful interactions via links. for example, HTML
forms use form/@enctype as a hint for what encoding has to be used
for a form submission, and AtomPub uses collection/accept to
indicate the MIME type(s). HTML forms use form/@method to indicate
the supported HTTP method, in AtomPub it is implicit. in HTML and
AtomPub, links are identified by the schema, but not in the markup.
what i am wondering: would it make any sense to come up with
something like xml:id for links? something that allows XML
vocabularies to be generically RESTful by making links discoverable
and also exposing some minimal information about how to access those
links? after all, hypermedia is one of the core constraints of REST,
and ironically, XML does not have a way of identifying links.
for link relations, should there be just one well-defined list of
values with a registry? should there be extensibility on a per
application basis, via things like QNames or CURIEs (both of which
have their issues because they're often not supported well in
implementations).
maybe we're all still traumatized by HLink, or REST does not need
any generic link recognition and link-enabled vocabularies are good
enough. right now, i am just interested in some feedback about the
general idea of "making links and some link semantics discoverable".
thanks and cheers,
erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
dret@xxxxxxxxxxxx - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
Nikunj R Mehta | Consulting Member of Technical Staff | Phone: +1 650
506 0679 | Blog: http://o-micron.blogspot.com
Oracle Advanced Development Projects
500 Oracle Parkway #4OP662 | Redwood Shores, CA 94065
Oracle is committed to developing practices and products that help
protect the environment