Loading ...
Sorry, an error occurred while loading the content.

Feedback regarding H-Factor

Expand Messages
  • mike amundsen
    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.
    Message 1 of 1 , Nov 19, 2012
    • 0 Attachment
      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.

    Your message has been successfully submitted and would be delivered to recipients shortly.