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
....

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> 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 irc.gnome.org freenode/#xml
>
>
>