affordance mutability / templated requests

Hi Mike,

Nice to hear from you.

> the list I work from (safety, idempotence, mutability, transcluion) is an abstraction above any single level 7 protocol and can be applied to HTTP, XMPP, WebSockets, etc. with equal success

How much of these abstractions must be realized in markup in order that a media type spec can identify what request to make in a given situation?
IOW how much request metadata is *necessary* to make the 'right' request?

That reminds me of the discussion between Berners-Lee, Andreesen et al regarding transclusion and navigation

http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html

where the new <img...> tag with a @src won out over the more verbose forms derived by recombining other markup (href, rel).

I've wanted to discuss the @method in html here as an example.  Is it necessary, especially given that only GET and POST are allowed, and mostly
it seems just a way to tunnel content by browsers outside of URL parameters.

What are other examples of level 7 protocols which would need the additional/explicit markup and how would it be used?  (I guess that is a big topic).

Cheers,
Peter

________________________________
From: mca [mailto:mca@amundsen.com]
Sent: July 5, 2013 11:27
To: liam@w3.org
Cc: stephengreenubl@gmail.com; Rushforth, Peter; public-xmlhypermedia@w3.org
Subject: Re: document node attributes

As Liam points out, there has been quite a bit of "re-invention" regarding hyperlinking over the years.

In my case, while working on my Hypermedia Factors[1], I created a list of (what I view as) essential "aspects" of hypermedia when used over a network[2]. These look similar to the XLink[3] and HLink[4] properties. However, the list I work from (safety, idempotence, mutability, transcluion) is an abstraction above any single level 7 protocol and can be applied to HTTP, XMPP, WebSockets, etc. with equal success.

One way to look at this problem is to ask "How can I describe hypermedia affordances in a machine-readable way such that it does not tightly constrain the protocol to be used?" An additional question might be "Can I do this an a general enough way that it can be modeled easily and with high-fidelity across various media type formats?" IOW, is there a way to describe hypermedia that is de-coupled from both protocol and format? I addressed this an a QCon talk a while back[5].

One can start w/ a single "uber" hypermedia affordance that looks like this (the XML variant appears below):

<uber:link
  name="search"
  href="http://example.com/search/"
  safe="true"
  idempotent="true"
  transclusion="true"
  mutable="true">
  <uber:data name="q" value="hypermedia" />
</uber>

which describes this in HTTP:
GET /search?q=hypermedia
host: example.com<http://example.com>
....

By tweaking the properties of this single affordance, you can describe almost every possible network request (for HTTP, PUT/DELETE and PATCH/POST have similar-enough network signatures that an additional property is needed [method]. Some protocols like WebSocket don't have this network signature collision problem).

Note that this approach would require a very small addition to XML (via NS or some other means), can be described easily via both XSD and DTD, and can be applied to existing documents w/o too much disruption of their doc models. Just two elements (link and data) and a handful of attributes.

When thinking about a generic way to describe linking and parameter-passing (e.g. forms) for XML, I think it can be valuable to start from this "uber" approach and consider another pass at the way XLink and HLink attempt to solve the same problem. I know it seems silly (possibly laughable) to propose _another_ attempt at distilling what we learned from HyTime, but there you go ;)

FWIW, I think that by raising the bar to an additional abstraction level (e.g. the network signatures instead of the media-type or protocol descriptions) makes this a worthwhile and portable effort. And I think the XML space is a great place to start ;)

Cheers.





[1] http://amundsen.com/hypermedia/hfactor/
[2] http://www.amundsen.com/blog/archives/1109
[3] http://www.w3.org/TR/xlink/#N1238
[4] http://www.w3.org/TR/hlink/#s_hlink_module
[5] http://www.slideshare.net/rnewton/amundsen-costbenefitshypermedia/80

mca
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen



On Fri, Jul 5, 2013 at 10:33 AM, Liam R E Quin <liam@w3.org<mailto:liam@w3.org>> wrote:
On Fri, 2013-07-05 at 13:53 +0100, Stephen D Green wrote:
> How about HLink then?
>
> http://www.w3.org/TR/hlink/
>

HLink is (unfortunately) an example of a group of people working in
isolation.  If we wanted a way to associate semantics with elements in
XML documents based on namespace, we'd want to be able to associate more
than just linking - e.g. see my "automatic namespaces" proposal.

Having said that, the idea of link discovery is an important one. HLink
is doing what HyTime architectural forms did, in a way.


--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net<http://irc.sorcery.net> irc.gnome.org<http://irc.gnome.org> freenode/#xml