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)
<oracle_sig_logo.gif>
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
<green-for-email-sig_0.gif> Oracle is committed to developing
practices and products that help protect the environment
