Re: affordance mutability / templated requests

<snip>
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?
</snip>

first, "right" is vague here. my assertion is that all four of them must be
handled by both clients and servers. Note that two are network level
(safety & idempotence) and are "promises" from the server. The other two
are client-side related (mutability and transclusion) and are hints from
the server on how the client MAY/SHOULD handle the results of the request.
 Whether this is explicitly stated in the response (e.g. my UBER example)
or implied in the human-readable documentation and then realized via code
is another matter. My recent experience in creating systems where machines
make most of the determinations at runtime is leading me to include more
explicit affordances in my designs. This is an optimization for _machines_
not humans, tho.

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

The IMG discussion is apropos for a couple reasons. it was the first time
someone attempted to indicate transclusion for HTML (good idea) and it was
a very succinct affordance as all the aspects are implied in the
documentation of IMG, not in the representation. For example, idempotence
and safety arise from using HTTP.GET. immutability and transclusion are
documented behavior for this control. It's also worth noting the use of SRC
instead of HREF. This is another key to the affordance design. SRC means
transclude=true, HREF means  transclude=false.

FWIW, in my Cj design[0], I adopted an affordance model[1][2] very close to
TimBL's model[3]. Again this was due to my desire to optimize for machines,
not humans.

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

not sure i follow you here. HTML.FORM@method="get" means "here is a
template for constructing a URL". HTML.FORM@method="post" means "here is a
template for constructing a message body." These are quite different
actions that MUST be communicated to the client. HTML designers could have
created different affordances for each (e.g. <url action="..."><input ...
/></url> AND <payload action="..."><input .../></payload>) but that did not
happen. Instead the @method value tells the client whether to construct a
URL or body. This is not a browser-specific issue, BTW. even when i build
my own native client, i need to resolve for this issue (URL or body
construction). Again, in Cj, i created the "template"[4], and "queries"[5]
elements in order to communicate constructing bodies (template) or URLs
(queries).

<snip>
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).
</snip>

Again, what is explicit in the representation and what is implied in the
human-readable documentation is a totally different discussion than the one
I am proposing in this thread. I suspect you mean (here) which L7 protocols
cannot have the full range of their uniform interface expressed using only
my "aspects." To that point, off the top of my head, most all the
HTTP-inspired L7 protocols have the "feature" of more than one of their
uniform interface methods having the same "aspect" signature over the
network.
FTP.PUT and FTP.DEL are both unsafe and idempotent.
HTTP.GET, HTTP.HEAD, and HTTP.OPTIONS are all safe and idempotent.
HTTP.PUT, HTTP.DELETE are both unsafe and idempotent
HTTP.POST and HTTP.PATCH are both unsafe and non-idempotent
CoAP.PUT and CoAP.DELETE are unsafe and idempotent

I'm sure there are others i can't bring to mind ATM. This is not a "bug" of
course, but a feature. For these protocols method is a significant part of
the _network_ signature (as it affects caching, for example). I chose to
leave this out of my aspects model since there are quite a few possible
protocol-specific variations that weren't helpful to my design work at the
time.

Note this all comes down to 1) what affordance you wish to model and 2) how
much of your affordance design will be explicit (in the message) and how
much will be implicit (in the human-readable docs). As "implied" relies on
entailment[6], my machine-optimized designs usually leave very little that
is not explicit. That is my _design_ decision, not anything technical, tho.


[0] http://amundsen.com/media-types/collection/
[1] http://amundsen.com/media-types/collection/format/#arrays-links
[2] http://amundsen.com/media-types/collection/format/#properties-render
[3] http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html
[4] http://amundsen.com/media-types/collection/format/#arrays-queries
[5] http://amundsen.com/media-types/collection/format/#objects-template
[6] http://www.thefreedictionary.com/implied


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 12:33 PM, Rushforth, Peter <
Peter.Rushforth@nrcan-rncan.gc.ca> wrote:

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