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

Which URIs are bookmarkable?

Expand Messages
  • Jan Algermissen
    Hi, how do I decide whether a URI is bookmarkable or not? ( Bookmarkable meaning: Being an entry point into an application that is worth remembering ) Some
    Message 1 of 9 , Oct 11, 2011
      Hi,


      how do I decide whether a URI is bookmarkable or not?

      ('Bookmarkable' meaning: 'Being an entry point into an application that is worth remembering')


      Some things to consider:

      There is a difference between the stability of a URI (whether a client can asssume a URI will
      be dereferencable in the future) and the suitability of a URI to act as an application entry point.
      For example, I'd assume HTML style sheet URIs to be pretty stable but they are not useful
      application entry points.

      Should a user agent remember as many URIs as possible, thereby increasing the amount of
      known application entry points and possibly avoiding re-doing certai steps through the
      application in the future (sth we do all the time when bookmarking e.g. page 4 of
      a search result).

      o All URIs I find in responses from a server in a link context are bookmarkable
      ('Link context' meaning Atom <link> elemnts, HTML <a> elements, Link headers,
      HTML GET-forms, etc.)

      o Not all URIs I find in responses from a server are bookmarkable. For example,

      - a URI I find in an HTML <form> element with action 'POST' is not
      - a URI I find in an Opensearch <Url> element is not
      - a URI I find in an HTML <style> element is not


      o What about

      - a URI I find in an HTML <img> element
      - a URI I find in an AtomPub <collection> element
      - a URI I find in HTTP headers such as Location, Content-Location, Alternates
      - AtomPub's edit-media links?
      - Atom <content src=""> references


      Does the cachability of a response affect these issues?


      In general, I am trying to answer the question:

      What are the indicators in media type (and link relation) specifications that tell
      the user agent implementor what URIs in responses of the media type in question
      can be considered bookmarkable?


      JAn
    • Ivan Žužak
      Hi Jan, I must say I ve thought about the same thing many times. I feel that there are two aspects of this question: 1) is it bookmarkable and 2) is it a
      Message 2 of 9 , Oct 11, 2011
        Hi Jan,

        I must say I've thought about the same thing many times.

        I feel that there are two aspects of this question: 1) is it bookmarkable and 2) is it a suitable entry point.

        My current opinion is that any identifier which is available when the user-agent is in a stable state may be bookmarked by the user-agent. This may be an identifier of an embedded <IMG> image or an <a> link in a HTML document, for example.

        Whether a bookmark is a suitable entry point is a more subtle thing and IMO depends on the application (i.e. depends on the agent using the bookmark). In most cases, you will want to bookmark links that return a hypermedia document which can then lead you onwards using links. However, I can imagine an application which only has the goal of fetching a bookmarked image and therefore does not need to go onwards from there i.e. doesn't need any links in the returned representation. Therefore, in one case, an identifier of an HTML document is needed (or similar), while in the other case, an identifier of a PNG image is needed (however, a parent HTML document identifier containing a link to the PNG would also be ok, but I wouldn't say it is mandatory). So as a general guideline, I'd bookmark identifiers of resources returning hypermedia documents because they can be used to navigate to other resources. However, some applications may be satisfied with bookmarking identifiers of resources returning non-hypermedia documents, which is also allowed. A consequence of this is that I would probably not bookmark a resource identifier if I have not successfully fetched it's content (either by navigation or by embedding) and examined it to see if it fits the above requirements (e.g. I'm not bookmarking an <a> link and expecting it will return a hypermedia document because it may return anything). 

        If any of the bookmarked identifiers becomes invalid at some point in time, the server should return a response which can guide clients onwards, e.g. include a link to a "home" resource or a resource related to the previously requested resource.

        Best,
        Ivan

        On Tue, Oct 11, 2011 at 09:40, Jan Algermissen <jan.algermissen@...> wrote:
         

        Hi,

        how do I decide whether a URI is bookmarkable or not?

        ('Bookmarkable' meaning: 'Being an entry point into an application that is worth remembering')

        Some things to consider:

        There is a difference between the stability of a URI (whether a client can asssume a URI will
        be dereferencable in the future) and the suitability of a URI to act as an application entry point.
        For example, I'd assume HTML style sheet URIs to be pretty stable but they are not useful
        application entry points.

        Should a user agent remember as many URIs as possible, thereby increasing the amount of
        known application entry points and possibly avoiding re-doing certai steps through the
        application in the future (sth we do all the time when bookmarking e.g. page 4 of
        a search result).

        o All URIs I find in responses from a server in a link context are bookmarkable
        ('Link context' meaning Atom <link> elemnts, HTML <a> elements, Link headers,
        HTML GET-forms, etc.)

        o Not all URIs I find in responses from a server are bookmarkable. For example,

        - a URI I find in an HTML <form> element with action 'POST' is not
        - a URI I find in an Opensearch <Url> element is not
        - a URI I find in an HTML <style> element is not

        o What about

        - a URI I find in an HTML <img> element
        - a URI I find in an AtomPub <collection> element
        - a URI I find in HTTP headers such as Location, Content-Location, Alternates
        - AtomPub's edit-media links?
        - Atom <content src=""> references

        Does the cachability of a response affect these issues?

        In general, I am trying to answer the question:

        What are the indicators in media type (and link relation) specifications that tell
        the user agent implementor what URIs in responses of the media type in question
        can be considered bookmarkable?

        JAn


      • Mike Kelly
        On Tue, Oct 11, 2011 at 8:40 AM, Jan Algermissen ... A given application should specify its entry points explicitly ... No, this is not necessary - caching
        Message 3 of 9 , Oct 11, 2011
          On Tue, Oct 11, 2011 at 8:40 AM, Jan Algermissen
          <jan.algermissen@...> wrote:
          > Hi,
          >
          >
          > how do I decide whether a URI is bookmarkable or not?
          >
          > ('Bookmarkable' meaning: 'Being an entry point into an application that is worth remembering')

          A given application should specify its entry points explicitly

          >
          > Some things to consider:
          >
          > There is a difference between the stability of a URI (whether a client can asssume a URI will
          > be dereferencable in the future) and the suitability of a URI to act as an application entry point.
          > For example, I'd assume HTML style sheet URIs to be pretty stable but they are not useful
          > application entry points.
          >
          > Should a user agent remember as many URIs as possible, thereby increasing the amount of
          > known application entry points and possibly avoiding re-doing certai steps through the
          > application in the future (sth we do all the time when bookmarking e.g. page 4 of
          > a search result).

          No, this is not necessary - caching already addresses this challenge.

          I'm not sure bookmarking a search page is a good example. I wouldn't
          do it personally but if I did, I imagine the potential for
          discrepancies on revisiting the bookmark to be quite high.. as a human
          I can adjust and handle that ok but not so much if I'm a piece of
          software. The rules can't be as liberal when the end user is not
          human, so there's significant limitations in trying to draw lessons
          from html for machine-oriented apps.

          >
          > Does the cachability of a response affect these issues?
          >

          No, they are two separate concerns

          >
          > In general, I am trying to answer the question:
          >
          > What are the indicators in media type (and link relation) specifications that tell
          > the user agent implementor what URIs in responses of the media type in question
          > can be considered bookmarkable?
          >

          The bits of a given spec that are explicit in specifying what
          constitutes a valid entry point.

          The question seems to assume that all media types (and their user
          agents) exist for a specific application, which is not always the case
          (e.g. HTML). In cases where the media type is generic, it isn't
          possible to establish entry points up front - which is why browsers
          allow users to bookmark whatever URL they want.

          Cheers,
          Mike
        • Jan Algermissen
          ... This cannot work because the application only comes into existence based on the choices the client makes. The server does not know what applications it
          Message 4 of 9 , Oct 11, 2011
            On Oct 11, 2011, at 11:23 AM, Mike Kelly wrote:

            > A given application should specify its entry points explicitly

            This cannot work because the application only comes into existence based on the choices the client makes. The server does not know what applications it will be a part of.

            Jan
          • Mike Kelly
            On Tue, Oct 11, 2011 at 10:42 AM, Jan Algermissen ... Do you mean application state? Either way, not sure I understand your point; AtomPub is an application,
            Message 5 of 9 , Oct 11, 2011
              On Tue, Oct 11, 2011 at 10:42 AM, Jan Algermissen
              <jan.algermissen@...> wrote:
              >
              > On Oct 11, 2011, at 11:23 AM, Mike Kelly wrote:
              >
              >> A given application should specify its entry points explicitly
              >
              > This cannot work because the application only comes into existence based on the choices the client makes.

              Do you mean application state?

              Either way, not sure I understand your point; AtomPub is an
              application, and it exists.

              >
              > The server does not know what applications it will be a part of.
              >

              Agreed, but why does that matter here? This is an issue for clients not servers

              Cheers,
              Mike
            • Jan Algermissen
              ... No, AtomPub is a media type that enables a certain set of applications. The AtomPub spec suggests a set of canonical[1] applications. But there are
              Message 6 of 9 , Oct 11, 2011
                On Oct 11, 2011, at 12:07 PM, Mike Kelly wrote:

                > On Tue, Oct 11, 2011 at 10:42 AM, Jan Algermissen
                > <jan.algermissen@...> wrote:
                >>
                >> On Oct 11, 2011, at 11:23 AM, Mike Kelly wrote:
                >>
                >>> A given application should specify its entry points explicitly
                >>
                >> This cannot work because the application only comes into existence based on the choices the client makes.
                >
                > Do you mean application state?
                >
                > Either way, not sure I understand your point; AtomPub is an
                > application, and it exists.

                No, AtomPub is a media type that enables a certain set of applications. The AtomPub spec suggests a set of canonical[1] applications. But there are certainly many, many others. For example, crawling a dozen of feeds and building an index of posts is one that is not in the AtomPub spec.

                The application is defined by what the user agent(s) do. Not by what a media type spec says.

                Jan

                [1] 'canonical application' has IIRC been coined by Jim Webber at restunconf in January 2011.




                >
                >>
                >> The server does not know what applications it will be a part of.
                >>
                >
                > Agreed, but why does that matter here? This is an issue for clients not servers
                >
                > Cheers,
                > Mike
              • Mike Kelly
                On Tue, Oct 11, 2011 at 11:18 AM, Jan Algermissen ... Right, this is actually one of my issues with Atom because, in my opinion, there should be complete
                Message 7 of 9 , Oct 11, 2011
                  On Tue, Oct 11, 2011 at 11:18 AM, Jan Algermissen
                  <jan.algermissen@...> wrote:
                  >
                  > On Oct 11, 2011, at 12:07 PM, Mike Kelly wrote:
                  >
                  >> On Tue, Oct 11, 2011 at 10:42 AM, Jan Algermissen
                  >> <jan.algermissen@...> wrote:
                  >>>
                  >>> On Oct 11, 2011, at 11:23 AM, Mike Kelly wrote:
                  >>>
                  >>>> A given application should specify its entry points explicitly
                  >>>
                  >>> This cannot work because the application only comes into existence based on the choices the client makes.
                  >>
                  >> Do you mean application state?
                  >>
                  >> Either way, not sure I understand your point; AtomPub is an
                  >> application, and it exists.
                  >
                  > No, AtomPub is a media type that enables a certain set of applications.
                  >

                  Right, this is actually one of my issues with Atom because, in my
                  opinion, there should be complete separation between the media type
                  and the 'application' i.e. hal (media type) and a set of link
                  relations (the application).

                  >
                  >The AtomPub spec suggests a set of canonical[1] applications. But there are certainly many, many others. For example, crawling a dozen of feeds and building an index of posts is one that is not in the AtomPub spec.
                  >

                  That's just a client performing multiple "applications" (I believe the
                  Jian™ terminology for this is Domain Application Protocol™) in a
                  particular sequence. Yes, there's some unique application state stuff
                  involved on the client side but that's not related to the AtomPub
                  application/DAP I was referring to originally and, more to the point,
                  isn't actually visible to the network. If you create a user agent that
                  generates and manages some application state of its own that's great
                  but I don't see what that has to do with bookmark-ability of the
                  resources or the Domain Application Protocols™ it's engaging in. The
                  DAPs are what is informing your user-agent of the significance of
                  given resources, and that is where (if at all) any potential entry
                  points should be specified.

                  Cheers,
                  Mike
                • Erik Mogensen
                  On Tue, Oct 11, 2011 at 9:40 AM, Jan Algermissen
                  Message 8 of 9 , Oct 11, 2011
                    On Tue, Oct 11, 2011 at 9:40 AM, Jan Algermissen <jan.algermissen@...> wrote:

                    [...] In general, I am trying to answer the question:

                    What are the indicators in media type (and link relation) specifications that tell
                    the user agent implementor what URIs in responses of the media type in question
                    can be considered bookmarkable?


                    Isn't it the prose in the media type specification itself?  A media type indicates that activating a particular hypermedia control advances the user agent to a new application state.  If that ends up in a "safe" state (i.e. it ends up with a GET'able resource) then that means that it's a "bookmarkable state" and one that's worthy of a future entry point.

                    Example: if a form directs you to POST something to a URI and it responds with a redirect to another resource, and the agent automatically follows that cue, then that new resource would IMHO be a bookmarkable state.

                    HTML states this clearly for <A>: "By activating these links [...], users may visit these resources." [1].  For  <IMG> images are to be "embedded [...] in the current document" [2].

                    --
                    -mogsie-
                  • Jan Algermissen
                    ... HA! It has been in the archives all along (thanks, Roy :-) If the application is designed correctly, then the only times that the user agent will pause
                    Message 9 of 9 , Oct 30, 2011
                      On Oct 11, 2011, at 9:40 AM, Jan Algermissen wrote:

                      > Hi,
                      >
                      > how do I decide whether a URI is bookmarkable or not?

                      HA! It has been in the archives all along (thanks, Roy :-)

                      "If the application is
                      designed correctly, then the only times that the user agent
                      will pause long enough to make a bookmark will be at one of
                      the application steady states, which should correspond to one
                      of the cool URIs. In other words, a RESTful architecture will
                      expose the cool URIs (and only the cool URIs) to the user."

                      http://tech.groups.yahoo.com/group/rest-discuss/message/13606

                      Jan


                      >
                      > ('Bookmarkable' meaning: 'Being an entry point into an application that is worth remembering')
                      >
                      > Some things to consider:
                      >
                      > There is a difference between the stability of a URI (whether a client can asssume a URI will
                      > be dereferencable in the future) and the suitability of a URI to act as an application entry point.
                      > For example, I'd assume HTML style sheet URIs to be pretty stable but they are not useful
                      > application entry points.
                      >
                      > Should a user agent remember as many URIs as possible, thereby increasing the amount of
                      > known application entry points and possibly avoiding re-doing certai steps through the
                      > application in the future (sth we do all the time when bookmarking e.g. page 4 of
                      > a search result).
                      >
                      > o All URIs I find in responses from a server in a link context are bookmarkable
                      > ('Link context' meaning Atom <link> elemnts, HTML <a> elements, Link headers,
                      > HTML GET-forms, etc.)
                      >
                      > o Not all URIs I find in responses from a server are bookmarkable. For example,
                      >
                      > - a URI I find in an HTML <form> element with action 'POST' is not
                      > - a URI I find in an Opensearch <Url> element is not
                      > - a URI I find in an HTML <style> element is not
                      >
                      > o What about
                      >
                      > - a URI I find in an HTML <img> element
                      > - a URI I find in an AtomPub <collection> element
                      > - a URI I find in HTTP headers such as Location, Content-Location, Alternates
                      > - AtomPub's edit-media links?
                      > - Atom <content src=""> references
                      >
                      > Does the cachability of a response affect these issues?
                      >
                      > In general, I am trying to answer the question:
                      >
                      > What are the indicators in media type (and link relation) specifications that tell
                      > the user agent implementor what URIs in responses of the media type in question
                      > can be considered bookmarkable?
                      >
                      > JAn
                      >
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.