Feedback regarding H-Factor

mike amundsen <[email protected]>
Newsgroups gmane.comp.web.services.rest
Message-ID <CAPW_8m6uN1dWaBpkWypzws54PP6Z0jYkvBugtxa0+Yuf5zU6jA@mail.gmail.com>
Mark Baker posted a comment about my H-Factors[0] in the LDP-Public list[1]
and, via a private convo, suggested I bring that topic here for further
discussion.

I'm copying the bulk of his comments here to start:

I agree in general, but have reservations about the use of H Factor,
both as a method of evaluation, but more importantly, as a tool for
motivating a solution. Consider that the difference between idempotent
and non-idempotent methods doesn't matter at all from a hypermedia
POV, but what does matter is whether the state transition can occur in
the absence of additional information. This makes "LI" meaningless,
along with its distinction from "LN". Also, "CM" as a factor seems to
derive solely from HTML's unification of GET and POST forms, and
appears to extrapolate from that, that it's desirable to have the
server prescribe the method used by the client; IMO, that's the
opposite of what you want as the client is solely responsible for the
meaning of the messages that it sends.

My initial response follows:

Consider that the difference between idempotent
and non-idempotent methods doesn't matter at all from a hypermedia
POV,

In the work I do (creating clients that can parse, recognize, and activate
hypermedia controls within a response), awareness of whether a control
represents a safe/unsafe and idempotent/non-idempotent action is important;
esp. when attempting a recover from cases where errors occur or no response
is received after activation. Can you expand a bit on why you think the
diff between idempotent and non-idempotent does not matter?

"CM" as a factor seems to
derive solely from HTML's unification of GET and POST forms, and
appears to extrapolate from that, that it's desirable to have the
server prescribe the method used by the client

The ability to designate a protocol method within a hypermedia control
appears in HTML[2], VoiceXML[3], and some other designs I've seen that are
not yet registered (Siren[4] comes to mind). I suspect this is true for
other designs I have not yet encountered.

My work on the Factors is meant to identify and catalog patterns for
enabling hypermedia in use on the WWW. It is not meant to confer
"desirability" upon any of the items I find.


that's the
opposite of what you want as the client is solely responsible for the
meaning of the messages that it sends.

I'm not sure what you mean here. "[T]he opposite of what you want.." is
addressed to whom? (e.g. "you"==??). "[T]he client is solely responsible
for the meaning..." I am not ascribing meaning or responsibility in
H-Factors.

Finally, if anyone thinks I have failed to identify existing hypermedia
patterns (e.g. they are not found in these H-Factors) and/or thinks I have
included pattern that do not actually exist, I'd like to hear about it.
 The purpose in this work is to create useful names for existing elements
to foster more understanding around how [hypermedia|hypertext] messages are
designed and how they are used. Any and all feedback is welcome.

Thanks.

[0] http://amundsen.com/hypermedia/hfactor/
[1] http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0022.html
[2] http://www.w3.org/TR/html401/interact/forms.html#adef-method
[3] http://www.w3.org/TR/voicexml20/#dml5.3.8
[4] https://github.com/kevinswiber/siren#method

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.