hello.
Nikunj Mehta wrote:
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.
but how do you find a link? for atom and atompub, the link can be
identified because of the element/attribute, but links are only findable
because of the fixed media type. what i was suggesting (and why i said
it is a bit off-topic) was a generic way to discover links in resources,
regardless of the media type (my current thinking is that this should
work for all XML media types, or more specifically, probably just those
XML media types which are namespace compliant).
http://dret.typepad.com/dretblog/2009/06/link-discovery-for-xml.html
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.
i agree that IANA is good for the link relations, if people want to
standardize them (i would assume that the vast majority of RESTful
services don't want to register their link relations, though, and they
should not be required to do so).
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.
the above blog post is a very early draft. my current thinking is that
LDX should allow link discovery, and discovered links should be
described by an optional link relation, an optional URI template, an
optional media type, and optional methods. this way, RESTful services
could expose as much information as required about what to expect when
traversing links.
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.
that's not exactly what i was talking about; having link types and
subtypes might get a bit complicated, i think.
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].
again, this is a bit off-list because i am approaching this from the
perspective of a general library that is supporting RESTful services.
atom and atompub would be great candidates and good use cases, which is
why i am interested in feedback from that community.
kind regards,
erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
[email protected] - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
