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
[email protected] - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
