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

Representations (Was: Resources as Orange Apples)

Expand Messages
  • Eric J. Bowman
    ... If the resource is a box of apples and its state is Red Delicious then the representation is a Red Delicious apple. When the representative apple is
    Message 1 of 20 , Aug 25, 2006
    • 0 Attachment
      >
      > 5.2.1.2 Representations
      >
      > REST components perform actions on a resource by using a representation
      > to capture the current or intended state of that resource and
      > transferring that representation between components. A representation
      > [includes] representation metadata to describe itself.
      >

      If the resource is a box of apples and its state is Red Delicious then the
      representation is a Red Delicious apple. When the representative apple is
      removed from the bin labeled "Red Delicious" for transferral from the box
      component to the human component, the human can still tell it's a Red
      Delicious by reading the little sticker of metadata.

      >
      > Other commonly used but less precise names for a representation
      > include: document, file, and HTTP message entity, instance, or variant.
      >

      In this example we sometimes use "variety", "varietal" or "variant" to
      describe the representative apples.

      >
      > Response messages may include both representation metadata and resource
      > metadata: information about the resource that is not specific to the
      > supplied representation.
      >

      The sticker on the apple may include both representation metadata indicating
      the variety of apple, and resource metadata indicating the name of the
      company the grocer obtains all apples from.

      >
      > Control data defines the purpose of a message between components, such
      > as the action being requested or the meaning of a response. It is also
      > used to parameterize requests and override the default behavior of some
      > connecting elements. For example, cache behavior can be modified by
      > control data included in the request or response message.
      >

      The grocer DELETEs apples from the bin before they go rotten, PUTs new apples
      in their place, and may POST an entirely new variety of apples not available
      the day before. Customers GET their apples, some of which have an additional
      little sticker stating, "This apple is for PIES." This is to override the
      customer's expected behavior of purchasing an apple to eat raw. The apple
      may also have an "expiration date" sticker to control how long the apple may
      be cached in a fruit basket. The customer may override that expiration date
      by eating the apple anyway after it's expired, or by throwing it out before
      it's expired and buying a new apple at the store.

      >
      > Depending on the message control data, a given representation may
      > indicate the current state of the requested resource, the desired state
      > for the requested resource, or the value of some other resource, such as
      > a representation of the input data within a client's query form, or a
      > representation of some error condition for a response.
      >

      The customer might only be interested in a particular variety of apple, or
      may prefer one variety over another. The given representation may not be an
      apple at all, it may be a picture of an apple with a message stating that the
      variety is out of stock (410 Gone). If we're talking about an apple vending
      machine, a GET request includes a query for the desired variety of apple (D-
      2), which yields either a representation of that apple in the vending slot or
      an error message stating, "Sorry, that RED DELICIOUS apple is past its
      expiration date."

      >
      > If the value set of a resource at a given time consists of multiple
      > representations, content negotiation may be used to select the best
      > representation for inclusion in a given message.
      >

      The error response from the vending machine could also include, "Would you
      like a GOLDEN DELICIOUS apple instead?" Or even a list of other available
      apples to select from (300 Options) with their key combos (i.e. D-3 through D-
      6).

      >
      > The data format of a representation is known as a media type [48]. A
      > representation can be included in a message and processed by the
      > recipient according to the control data of the message and the nature of
      > the media type. Some media types are intended for automated processing,
      > some are intended to be rendered for viewing by a user, and a few are
      > capable of both. Composite media types can be used to enclose multiple
      > representations in a single message.
      >

      Some apples are "Cider Apples", some could be designated as "Pie Apples" and
      of course there's always the good ol' "Eatin' Apple". Some apples can go
      straight into the juicer, some are for making pies, and some apples used in
      both juice and pies are also tasty eaten raw. If I go to the store looking
      for apples to both eat and bake in pies, and the only varietal they have in
      stock is good for both, I don't need the apples I buy put into separate bags.
      I might want separate bags if the store had one variety only good for eating
      and another variety only good for baking in pies, which happened to both be
      green, especially if the store didn't use "This apple is for PIES" stickers.

      >
      > The design of a media type can directly impact the user-perceived
      > performance of a distributed hypermedia system. Any data that must be
      > received before the recipient can begin rendering the representation
      > adds to the latency of an interaction. A data format that places the
      > most important rendering information up front, such that the initial
      > information can be incrementally rendered while the rest of the
      > information is being received, results in much better user-perceived
      > performance than a data format that must be entirely received before
      > rendering can begin.
      >

      Apples and Oranges simply won't do here.

      Both HTML 4.01 and XHTML 1.1 follow the same table model. To increase user-
      perceived performance it is necessary to use the proper markup, and the CSS
      table-layout:fixed property. This does not vary between the "text/html" and
      the "application/xhtml+xml" media types. Both <thead> and <tfoot> must
      appear before <tbody> in HTML 4-based markup languages, for the purpose of
      incrementally rendering the table before the HTML file is fully parsed. I
      have explained in much greater detail here:

      [1] http://www.iwdn.net/showthread.php?t=4114

      There's a really fine point to be made here. If we are discussing a simple
      little table in an HTML page then the greatest user-perceived performance may
      be had from the "application/xhtml+xml" media type. The effect of treating
      XML as XML is that new pages transfer completely before rendering, but on
      small pages this tends to make things look "snappier" to a user browsing the
      site.

      If the page in question is a large data table with thousands of rows, the
      opposite is true -- treating XML as XML means an awful lot of latency for the
      end user because the entire table needs to run through the XML parser before
      rendering begins. So a better choice for large data tables is "text/html"
      because that media type strictly allows user-agents to incrementally render
      the table before the document has finished SGML parsing.

      The "application/xhtml+xml" media type overrides incremental table layout,
      even when the table is rendered in a single pass by virtue of using the <col>/
      <colgroup> tags and table-layout:fixed, because the whole document must
      finish parsing before rendering begins.

      -Eric
    • Josh Sled
      ... I find this whole analogy rather forced. Why so much of a focus on containers, sets and physical objects anyways? There s very little -- on the HTTP web,
      Message 2 of 20 , Aug 26, 2006
      • 0 Attachment
        On Sat, 2006-08-26 at 03:29 +0000, Eric J. Bowman wrote:
        > In this example we sometimes use "variety", "varietal" or "variant"
        > to
        > describe the representative apples.

        I find this whole analogy rather forced.


        Why so much of a focus on containers, sets and physical objects anyways?
        There's very little -- on the HTTP web, anways -- that actually exploits
        a "container" relationship; even Apache directory listings are done by
        generating HTML, and simply following links. The browser doesn't know.


        What about focusing on URI's identifiying application states, and using
        hyperlinks (and forms) in the media to transition between them?

        http://airline.com/
        http://airline.com/upcoming-flights
        http://airline.com/booking/select
        http://airline.com/booking/promotion
        http://airline.com/booking/payment
        [...]

        This is obvious to CS types and non-CS webdevs ... pretty much anyone
        who's booked a flight online.

        --
        ...jsled
        http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
      • Josh Sled
        ... *ahem* [...the browser doesn t know] that a particular thing is a `directory` containing `files`. There is only a link to another URI in the hypermedia,
        Message 3 of 20 , Aug 26, 2006
        • 0 Attachment
          On Sat, 2006-08-26 at 10:28 -0400, Josh Sled wrote:
          > generating HTML, and simply following links. The browser doesn't
          > know.

          *ahem*

          [...the browser doesn't know] that a particular thing is a `directory`
          containing `files`. There is only a link to another URI in the
          hypermedia, and a known set of operations to apply.

          --
          ...jsled
          http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
        • Eric J. Bowman
          ... Because the definition of resource in REST is built on the notion of set theory. REST leaves equivalent undefined, which it can get away with by leaving
          Message 4 of 20 , Aug 27, 2006
          • 0 Attachment
            >
            >Why so much of a focus on containers, sets and physical objects anyways?
            >There's very little -- on the HTTP web, anways -- that actually exploits
            >a "container" relationship; even Apache directory listings are done by
            >generating HTML, and simply following links. The browser doesn't know.
            >

            Because the definition of resource in REST is built on the notion of set
            theory. REST leaves "equivalent" undefined, which it can get away with by
            leaving the responsibility for understanding set theory squarely on the
            shoulders of the reader. I'm afraid this has led many to interpret
            "equivalent" to mean "anything I want it to mean". REST also defines
            concepts like content negotiation and redirection without elaborating on
            them, requiring the reader to first understand equivalence as defined by set
            theory in order to properly implement a REST-based solution.

            To me, this suggests that the best way to understand or explain REST concepts
            like content negotiation and redirection is to converse in terms of set
            theory, because understanding or explaining those concepts first requires a
            clear understanding of the semantics of "equivalent". The problem is that
            "equivalent" may only be defined as it pertains to any given example, which
            is why I think there needs to be some sort of base vocabulary using non-
            opaque URIs.

            Otherwise, parties must first agree on the semantics of the example URIs
            before proceeding to discuss the issue at hand, even if both are well-versed
            in REST. It can take days for a group to even understand that their
            disagreement comes down to the semantics of a URI's mapping, not the behavior
            of that URI when dereferenced, because one side thinks it's talking about
            apples and the other side thinks it's talking about oranges.

            The semantics of a mapping can be made more obvious by restricting examples
            to sets whose membership and equivalency are inherent in their naming,
            regardless of URI allocation scheme, so I chose apples and oranges. It
            provides a common-ground example, wholly unrelated to any specific service
            (flight reservations, weather etc.), which carries over to a wide variety of
            situations and possible URI allocation schemes.

            This may allow examples to be more easily understood without having to first
            define the conceptual sets, and provide a means for parties who disagree
            about the semantics of a particular mapping to illustrate their positions. If
            not, hopefully some people besides me will find it useful to explain or
            understand REST or at least those parts of it which are wholly reliant on an
            understanding of set theory, like "resource".

            >
            >What about focusing on URI's identifiying application states, and using
            >hyperlinks (and forms) in the media to transition between them?
            >

            I wish you hadn't asked me that, since I had planned to spend my Saturday
            differently, but it was cold and rainy so I spent it adding URI-based
            examples to what I already had. ;-) But it just didn't work. Problem is,
            whatever URI allocation scheme is chosen for an example comes across as some
            sort of "preferred" method if it's an example of good practice, while those
            used as examples of bad practice look as though it results from the URI
            scheme itself instead of flawed conceptualization.

            Some Venn diagrams in the narrative might prove useful, though.

            If I've established the analogy correctly, it may be used as an example-
            neutral "common notation" to illustrate the situational semantics of that
            pesky word "equivalent", and other REST concepts:

            [1] http://example.com/apple/
            [2] http://example.com/apple/red-delicious.apple
            [3] http://example.com/apple/golden-delicious.apple

            [1] http://example.com/apple
            [2] http://example.com/apple.red-delicious
            [3] http://example.com/apple.golden-delicious

            [1] http://example.com/apples
            [2] http://example.com/apples/red-delicious/apple.fruit
            [3] http://example.com/apples/golden-delicious/apple.fruit

            Considering any of the three URI allocation schemes above, resource [1]
            sometimes responds with a representation of resource [2] when dereferenced,
            while at other times the response is a representation of resource [3],
            depending upon user preference. This is a perfectly acceptable use of REST
            content negotiation, provided that resources [2] and [3] are "proper subsets"
            of set [1] (they must be both conceptual and hierarchical subsets), AND
            representations [1], [2] and [3] are all members of set [1]'s "Union of
            Complements".

            The inverse of the Union of Complements is the "Intersection". A basic Venn
            diagram consists of two overlapping circles, A and B, inside a rectangle U
            (for Universal set). The area where the circles overlap is the Intersection,
            everything else inside the rectangle is the Union of Complements. URIs [1],
            [2] and [3] so far, have all been in the Union of Complements. If we
            conceptualize resource [1] as "fresh apples", this URI would be in the
            Intersection:

            [4] http://example.com/apples/red-delicious/rotten.apple.fruit

            The representation of a rotten apple is a member of the Red Delicious
            hierarchical subset, therefore it is a member of the Apples hierarchical
            subset. But, if we've decided that [4] will never be a response
            representation when resource [1] is dereferenced, we have excluded [4] from
            membership in any conceptual subset of [1] without altering the URI
            allocation scheme. REST does not care how you go about defining the
            semantics of your mappings (configuring your server) so long as they're
            valid, and static.

            Resource [1]'s conceptual set is defined by its mapping, not by its members,
            so it is up to the server manager to ensure that all members belong by
            properly constraining the responses returned when resource [1] is
            dereferenced. It is this constraint of the set which defines the resource
            concept in REST, not the semantics of its members, becasue the resource is
            the box -- not its contents at any given point in time.

            A Venn diagram which expresses a hierarchical subset is a rectangle U
            containing one circle B completely enclosed within another circle A. To
            express REST content negotiation for a given resource as a Venn diagram
            requires both the circle-in-a-circle diagram to constrain it to proper
            subsets, then the overlapping-circle diagram to constrain the resource set to
            its conceptual Union of Complements.

            [1] http://example.com/fruit/
            [2] http://example.com/apples/
            [3] http://example.com/oranges/

            [1] http://example.com/fruit
            [2] http://example.com/apple
            [3] http://example.com/orange

            In either sequence above, if resource [1] sometimes responds with a
            representation of resource [2] when dereferenced and at other times, a
            representation of resource [3], it is a REST error (aka "URI collision") even
            though conceptually, [2] and [3] are equivalent subsets of [1]. This is
            because "Each origin server provides... a resource hierarchy", which means
            that [1], [2] and [3] are "disjoint sets" by definition of URIs as
            hierarchical sets. URIs [2] and [3] cannot be seen as proper subsets of [1]
            unless they are also hierarchical subsets of [1]:

            [1] http://example.com/fruit/
            [2] http://example.com/fruit/apples/
            [3] http://example.com/fruit/oranges/

            [1] http://example.com/fruit
            [2] http://example.com/fruit.apple
            [3] http://example.com/fruit.orange

            So far, the examples have assumed content-negotiation situations, where the
            response representation when resource [1] is dereferenced may be any
            equivalent member representation contained the Union of Complements with a
            response code of 200 OK. These are examples of the "late binding of a
            representation to a resource". Sometimes, we want to include an equivalent
            set in our conceptual set, which is NOT in the same hierarchical set. In such
            a case, the response when [1] is dereferenced is not a representation of the
            resource it identifies, instead the response representation "indicates the
            value of some other resource" by redirection.

            This redirection serves the purpose of identifying a "disjoint set" as an
            equivalent resource, which could also be called the early binding of a
            resource to a request. This redirection must be the same for all users,
            regardless of the preference settings of their user-agents, in order for the
            semantics of the resource mapping to remain static. The "late binding of a
            representation to a resource" may only occur at the target of the
            redirection, not the dynamically-redirecting resource itself, because that
            set's only member representation "indicates an equivalent disjoint set" and
            nothing more.

            [1] http://example.com/fruit-of-the-month
            [2] http://example.com/apples/
            [3] http://example.com/apples/red-delicious.apple
            [4] http://example.com/oranges/

            URI [1] indicates some other resource as being a disjoint set of temporarily-
            equivalent value by responding to requests with a 307 redirect. Let's assume
            this month's fruit is "apples". For this month, resource [2] is temporarily
            equivalent to resource [1], the fact that they have no overlapping membership
            despite their equivalence is the definition of disjoint sets. Next month, [2]
            should no longer be equivalent to [1].

            The only member representation of set [1] above is a 307 redirect pointer. To
            express permanent instead of temporary equivalency, the only member
            representation of set [1] below would be a 301 redirect instead of a 307:

            [1] http://example.com/2006-fruit-of-the-year
            [2] http://example.com/apples/

            Resource [1] may conceptually identify resource [2], but this does not make
            resource [2] or its members, members of set [1]. The Venn diagram for a
            disjoint set is a rectangle U containing two circles A and B which do not
            overlap, it is the only diagram required to express REST redirection.

            To sum up: content negotiation is the late binding to a requested resource of
            some member representation which is equivalent, defined as the Union of
            Complements of the resource set and its proper subsets. Redirection is the
            early binding to a request of some other resource which is equivalent,
            defined as a disjoint set. These relationships may be modeled using simple
            Venn diagrams as visual aids when conceptualizing a website or web service.
            These Venn diagrams can be used to derive the URI allocation scheme, and be
            referred to when designing the function of the various components.

            (My nutshell objection to the notion of a service document, is its Venn
            diagram consists of circles A and B on the outside of rectangle U, and I
            can't square that with REST.)

            -Eric

            >--
            >...jsled
            >http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
            >
          • Eric J. Bowman
            Modeling the orange apple case: [U] http://example.com/fruit/ [A] http://example.com/fruit/oranges/ [B] http://example.com/fruit/apples/ [A1]
            Message 5 of 20 , Aug 27, 2006
            • 0 Attachment
              Modeling the "orange apple" case:

              [U] http://example.com/fruit/
              [A] http://example.com/fruit/oranges/
              [B] http://example.com/fruit/apples/
              [A1] http://example.com/fruit/oranges/golden.apple
              [A2] http://example.com/fruit/apples/orange.apple
              [I] http://example.com/fruit/orange_apples/
              [I1] http://example.com/fruit/orange_apples/golden.apple
              [I2] http://example.com/fruit/orange_apples/orange.apple

              The equivalent members of set [I] are in the Intersection (the white-
              background region in the attached image), not the Union of Complements (the
              shaded-background region in venn.png). The URIs which identify [I]'s member
              resources should be (but are not required to be) [I1] and [I2]. When
              dereferenced, these resources identify their equivalent disjoint sets [A1]
              and [A2] with 303 redirects.

              The use case for [I1] and [I2] is only when [I] is required to return a
              directory listing when dereferenced. Otherwise, we can just use:

              [I] http://example.com/fruit/orange_apples

              When dereferenced, the response is an HTML representation of a page
              describing orange apples, with links to [A1] and [A2]. If, when [I1] and
              [I2] are dereferenced, the responses are representations of apples instead of
              representations indicating the equivalent disjoint sets [A1] and [A2], [I1]
              and [I2] would be "URI aliases".

              If the attached Venn diagram's background were entirely shaded, like it would
              be if we were referring to the set [U] instead of the set [I], its meaning
              would be the "Union of Subset and its Complement". When dereferenced [U]
              could, using content negotiation, legitimately return any member URI (not
              just members of A and B) because we have specifically defined the
              Intersection as a member of the Universal set, and because we haven't ruled
              out any fruits which aren't apples or oranges.

              [1] http://canuck.bisonsystesms.net/dev/rest/venn.png

              -Eric
            • Eric J. Bowman
              Crap. Sorry: [1] http://canuck.bisonsystems.net/dev/rest/venn.png -Eric
              Message 6 of 20 , Aug 27, 2006
              • 0 Attachment
              • Walden Mathews
                Eric, I think you are misinterpreting the significance of set theory, if there is any, to REST. It is not about resource containment; it s about
                Message 7 of 20 , Aug 27, 2006
                • 0 Attachment
                  Eric,

                  I think you are misinterpreting the significance of set theory, if there is
                  any, to REST. It is not about resource containment; it's about
                  representation.

                  Given some resource, there is a set of representations for it, and the
                  following are all true:

                  1. The set may be empty for all time

                  2. The set may be broken into not necessarily disjoint subsets, each
                  of which represents the resource at some distinct time.

                  3. Each of the subsets in 2 above may be empty or have any number
                  of members. The members are equivalent in that they all represent
                  the same resource at the same time.

                  Further, to your URI examples and content negotiation discussion,
                  there is no need to implicate more than one resource (and therefore one
                  URI) in modeling content negotiation. I think if you figure that out,
                  you'll be well on your way to some rest from this subject, no pun
                  intended.

                  Walden

                  ----- Original Message -----
                  From: "Eric J. Bowman" <eric@...>
                  To: "Josh Sled" <jsled@...>
                  Cc: <rest-discuss@yahoogroups.com>
                  Sent: Sunday, August 27, 2006 5:22 AM
                  Subject: Re: [rest-discuss] Representations (Was: Resources as Orange
                  Apples)


                  : >
                  : >Why so much of a focus on containers, sets and physical objects anyways?
                  : >There's very little -- on the HTTP web, anways -- that actually exploits
                  : >a "container" relationship; even Apache directory listings are done by
                  : >generating HTML, and simply following links. The browser doesn't know.
                  : >
                  :
                  : Because the definition of resource in REST is built on the notion of set
                  : theory. REST leaves "equivalent" undefined, which it can get away with by
                  : leaving the responsibility for understanding set theory squarely on the
                  : shoulders of the reader. I'm afraid this has led many to interpret
                  : "equivalent" to mean "anything I want it to mean". REST also defines
                  : concepts like content negotiation and redirection without elaborating on
                  : them, requiring the reader to first understand equivalence as defined by
                  set
                  : theory in order to properly implement a REST-based solution.
                  :
                  : To me, this suggests that the best way to understand or explain REST
                  concepts
                  : like content negotiation and redirection is to converse in terms of set
                  : theory, because understanding or explaining those concepts first requires
                  a
                  : clear understanding of the semantics of "equivalent". The problem is that
                  : "equivalent" may only be defined as it pertains to any given example,
                  which
                  : is why I think there needs to be some sort of base vocabulary using non-
                  : opaque URIs.
                  :
                  : Otherwise, parties must first agree on the semantics of the example URIs
                  : before proceeding to discuss the issue at hand, even if both are
                  well-versed
                  : in REST. It can take days for a group to even understand that their
                  : disagreement comes down to the semantics of a URI's mapping, not the
                  behavior
                  : of that URI when dereferenced, because one side thinks it's talking about
                  : apples and the other side thinks it's talking about oranges.
                  :
                  : The semantics of a mapping can be made more obvious by restricting
                  examples
                  : to sets whose membership and equivalency are inherent in their naming,
                  : regardless of URI allocation scheme, so I chose apples and oranges. It
                  : provides a common-ground example, wholly unrelated to any specific service
                  : (flight reservations, weather etc.), which carries over to a wide variety
                  of
                  : situations and possible URI allocation schemes.
                  :
                  : This may allow examples to be more easily understood without having to
                  first
                  : define the conceptual sets, and provide a means for parties who disagree
                  : about the semantics of a particular mapping to illustrate their positions.
                  If
                  : not, hopefully some people besides me will find it useful to explain or
                  : understand REST or at least those parts of it which are wholly reliant on
                  an
                  : understanding of set theory, like "resource".
                  :
                  : >
                  : >What about focusing on URI's identifiying application states, and using
                  : >hyperlinks (and forms) in the media to transition between them?
                  : >
                  :
                  : I wish you hadn't asked me that, since I had planned to spend my Saturday
                  : differently, but it was cold and rainy so I spent it adding URI-based
                  : examples to what I already had. ;-) But it just didn't work. Problem
                  is,
                  : whatever URI allocation scheme is chosen for an example comes across as
                  some
                  : sort of "preferred" method if it's an example of good practice, while
                  those
                  : used as examples of bad practice look as though it results from the URI
                  : scheme itself instead of flawed conceptualization.
                  :
                  : Some Venn diagrams in the narrative might prove useful, though.
                  :
                  : If I've established the analogy correctly, it may be used as an example-
                  : neutral "common notation" to illustrate the situational semantics of that
                  : pesky word "equivalent", and other REST concepts:
                  :
                  : [1] http://example.com/apple/
                  : [2] http://example.com/apple/red-delicious.apple
                  : [3] http://example.com/apple/golden-delicious.apple
                  :
                  : [1] http://example.com/apple
                  : [2] http://example.com/apple.red-delicious
                  : [3] http://example.com/apple.golden-delicious
                  :
                  : [1] http://example.com/apples
                  : [2] http://example.com/apples/red-delicious/apple.fruit
                  : [3] http://example.com/apples/golden-delicious/apple.fruit
                  :
                  : Considering any of the three URI allocation schemes above, resource [1]
                  : sometimes responds with a representation of resource [2] when
                  dereferenced,
                  : while at other times the response is a representation of resource [3],
                  : depending upon user preference. This is a perfectly acceptable use of REST
                  : content negotiation, provided that resources [2] and [3] are "proper
                  subsets"
                  : of set [1] (they must be both conceptual and hierarchical subsets), AND
                  : representations [1], [2] and [3] are all members of set [1]'s "Union of
                  : Complements".
                  :
                  : The inverse of the Union of Complements is the "Intersection". A basic
                  Venn
                  : diagram consists of two overlapping circles, A and B, inside a rectangle U
                  : (for Universal set). The area where the circles overlap is the
                  Intersection,
                  : everything else inside the rectangle is the Union of Complements. URIs
                  [1],
                  : [2] and [3] so far, have all been in the Union of Complements. If we
                  : conceptualize resource [1] as "fresh apples", this URI would be in the
                  : Intersection:
                  :
                  : [4] http://example.com/apples/red-delicious/rotten.apple.fruit
                  :
                  : The representation of a rotten apple is a member of the Red Delicious
                  : hierarchical subset, therefore it is a member of the Apples hierarchical
                  : subset. But, if we've decided that [4] will never be a response
                  : representation when resource [1] is dereferenced, we have excluded [4]
                  from
                  : membership in any conceptual subset of [1] without altering the URI
                  : allocation scheme. REST does not care how you go about defining the
                  : semantics of your mappings (configuring your server) so long as they're
                  : valid, and static.
                  :
                  : Resource [1]'s conceptual set is defined by its mapping, not by its
                  members,
                  : so it is up to the server manager to ensure that all members belong by
                  : properly constraining the responses returned when resource [1] is
                  : dereferenced. It is this constraint of the set which defines the resource
                  : concept in REST, not the semantics of its members, becasue the resource is
                  : the box -- not its contents at any given point in time.
                  :
                  : A Venn diagram which expresses a hierarchical subset is a rectangle U
                  : containing one circle B completely enclosed within another circle A. To
                  : express REST content negotiation for a given resource as a Venn diagram
                  : requires both the circle-in-a-circle diagram to constrain it to proper
                  : subsets, then the overlapping-circle diagram to constrain the resource set
                  to
                  : its conceptual Union of Complements.
                  :
                  : [1] http://example.com/fruit/
                  : [2] http://example.com/apples/
                  : [3] http://example.com/oranges/
                  :
                  : [1] http://example.com/fruit
                  : [2] http://example.com/apple
                  : [3] http://example.com/orange
                  :
                  : In either sequence above, if resource [1] sometimes responds with a
                  : representation of resource [2] when dereferenced and at other times, a
                  : representation of resource [3], it is a REST error (aka "URI collision")
                  even
                  : though conceptually, [2] and [3] are equivalent subsets of [1]. This is
                  : because "Each origin server provides... a resource hierarchy", which means
                  : that [1], [2] and [3] are "disjoint sets" by definition of URIs as
                  : hierarchical sets. URIs [2] and [3] cannot be seen as proper subsets of
                  [1]
                  : unless they are also hierarchical subsets of [1]:
                  :
                  : [1] http://example.com/fruit/
                  : [2] http://example.com/fruit/apples/
                  : [3] http://example.com/fruit/oranges/
                  :
                  : [1] http://example.com/fruit
                  : [2] http://example.com/fruit.apple
                  : [3] http://example.com/fruit.orange
                  :
                  : So far, the examples have assumed content-negotiation situations, where
                  the
                  : response representation when resource [1] is dereferenced may be any
                  : equivalent member representation contained the Union of Complements with a
                  : response code of 200 OK. These are examples of the "late binding of a
                  : representation to a resource". Sometimes, we want to include an equivalent
                  : set in our conceptual set, which is NOT in the same hierarchical set. In
                  such
                  : a case, the response when [1] is dereferenced is not a representation of
                  the
                  : resource it identifies, instead the response representation "indicates the
                  : value of some other resource" by redirection.
                  :
                  : This redirection serves the purpose of identifying a "disjoint set" as an
                  : equivalent resource, which could also be called the early binding of a
                  : resource to a request. This redirection must be the same for all users,
                  : regardless of the preference settings of their user-agents, in order for
                  the
                  : semantics of the resource mapping to remain static. The "late binding of a
                  : representation to a resource" may only occur at the target of the
                  : redirection, not the dynamically-redirecting resource itself, because that
                  : set's only member representation "indicates an equivalent disjoint set"
                  and
                  : nothing more.
                  :
                  : [1] http://example.com/fruit-of-the-month
                  : [2] http://example.com/apples/
                  : [3] http://example.com/apples/red-delicious.apple
                  : [4] http://example.com/oranges/
                  :
                  : URI [1] indicates some other resource as being a disjoint set of
                  temporarily-
                  : equivalent value by responding to requests with a 307 redirect. Let's
                  assume
                  : this month's fruit is "apples". For this month, resource [2] is
                  temporarily
                  : equivalent to resource [1], the fact that they have no overlapping
                  membership
                  : despite their equivalence is the definition of disjoint sets. Next month,
                  [2]
                  : should no longer be equivalent to [1].
                  :
                  : The only member representation of set [1] above is a 307 redirect pointer.
                  To
                  : express permanent instead of temporary equivalency, the only member
                  : representation of set [1] below would be a 301 redirect instead of a 307:
                  :
                  : [1] http://example.com/2006-fruit-of-the-year
                  : [2] http://example.com/apples/
                  :
                  : Resource [1] may conceptually identify resource [2], but this does not
                  make
                  : resource [2] or its members, members of set [1]. The Venn diagram for a
                  : disjoint set is a rectangle U containing two circles A and B which do not
                  : overlap, it is the only diagram required to express REST redirection.
                  :
                  : To sum up: content negotiation is the late binding to a requested resource
                  of
                  : some member representation which is equivalent, defined as the Union of
                  : Complements of the resource set and its proper subsets. Redirection is
                  the
                  : early binding to a request of some other resource which is equivalent,
                  : defined as a disjoint set. These relationships may be modeled using
                  simple
                  : Venn diagrams as visual aids when conceptualizing a website or web
                  service.
                  : These Venn diagrams can be used to derive the URI allocation scheme, and
                  be
                  : referred to when designing the function of the various components.
                  :
                  : (My nutshell objection to the notion of a service document, is its Venn
                  : diagram consists of circles A and B on the outside of rectangle U, and I
                  : can't square that with REST.)
                  :
                  : -Eric
                  :
                  : >--
                  : >...jsled
                  : >http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
                  : >
                  :
                  :
                  :
                  :
                  : __________ NOD32 1.1727 (20060826) Information __________
                  :
                  : This message was checked by NOD32 antivirus system.
                  : http://www.eset.com
                  :
                  :
                • Eric J. Bowman
                  ... When implementing content negotiation, each alternate representation is also its own resource with its own URI, this URI is returned in Content-Location. I
                  Message 8 of 20 , Aug 27, 2006
                  • 0 Attachment
                    >
                    >Further, to your URI examples and content negotiation discussion,
                    >there is no need to implicate more than one resource (and therefore one
                    >URI) in modeling content negotiation. I think if you figure that out,
                    >you'll be well on your way to some rest from this subject, no pun
                    >intended.
                    >

                    When implementing content negotiation, each alternate representation is also
                    its own resource with its own URI, this URI is returned in Content-Location.
                    I don't know how this is done without using multiple resources.

                    -Eric

                    >
                    >Walden
                    >
                  • Walden Mathews
                    Eric, That s the agent-driven form you are talking about, and not the only way to do it. I suggest that cases in which representations each have their own URI
                    Message 9 of 20 , Aug 27, 2006
                    • 0 Attachment
                      Eric,

                      That's the agent-driven form you are talking about, and not the only
                      way to do it.

                      I suggest that cases in which representations each have their own
                      URI are confusing when you are trying to understand the basic model
                      of the relationships among resources and representations. This could be
                      why you are going off on containers.

                      That's why I am recommending you examine a content negotiation
                      case that does not involve more than one URI. And see how you apply
                      set theory to that.

                      Try it.

                      Walden

                      ----- Original Message -----
                      From: "Eric J. Bowman" <eric@...>
                      To: "Walden Mathews" <waldenm@...>
                      Cc: <rest-discuss@yahoogroups.com>
                      Sent: Sunday, August 27, 2006 6:26 PM
                      Subject: Re: [rest-discuss] Representations (Was: Resources as Orange
                      Apples)


                      : >
                      : >Further, to your URI examples and content negotiation discussion,
                      : >there is no need to implicate more than one resource (and therefore one
                      : >URI) in modeling content negotiation. I think if you figure that out,
                      : >you'll be well on your way to some rest from this subject, no pun
                      : >intended.
                      : >
                      :
                      : When implementing content negotiation, each alternate representation is
                      also
                      : its own resource with its own URI, this URI is returned in
                      Content-Location.
                      : I don't know how this is done without using multiple resources.
                      :
                      : -Eric
                      :
                      : >
                      : >Walden
                      : >
                      :
                      :
                      :
                      : __________ NOD32 1.1727 (20060826) Information __________
                      :
                      : This message was checked by NOD32 antivirus system.
                      : http://www.eset.com
                      :
                      :
                    • Eric J. Bowman
                      ... Server-driven negotiation attempts to assess the preferences set in the user- agent and return the most appropriate representation. If the user-agent
                      Message 10 of 20 , Aug 27, 2006
                      • 0 Attachment
                        >
                        >Eric,
                        >
                        >That's the agent-driven form you are talking about, and not the only
                        >way to do it.
                        >

                        Server-driven negotiation attempts to assess the preferences set in the user-
                        agent and return the "most appropriate" representation. If the user-agent
                        prefers Red Delicious over Golden Delicious the server responds with Red
                        Delicious.

                        Agent-driven negotiation is when the server responds with a list of options,
                        or its best-guess representation plus a list of options. All my examples
                        assume a 200 OK response from the server, not 300 Options, I think that
                        indicates server-driven negotiation.

                        >
                        >I suggest that cases in which representations each have their own
                        >URI are confusing when you are trying to understand the basic model
                        >of the relationships among resources and representations. This could be
                        >why you are going off on containers.
                        >

                        I agree that it's confusing, which is why I use Venn diagrams when I'm
                        figuring out content-negotiation scenarios. All I can really say is it works
                        for me. Content negotiation introduces a certain ambiguity between resource
                        and representation (one resource returns representations of other resources),
                        diagrams help me keep my head above water.

                        >
                        >That's why I am recommending you examine a content negotiation
                        >case that does not involve more than one URI. And see how you apply
                        >set theory to that.
                        >
                        >Try it.
                        >

                        I'm all for constructive criticism here, I'm not trying to be stubborn, but I
                        can't think of such a case. The alternate representations can always be
                        assigned their own URIs, which I always return in Content-Location because
                        that URI is not the same as the one in the "location bar", i.e. the request
                        URI.

                        -Eric

                        >
                        >Walden
                        >
                        >----- Original Message -----
                        >From: "Eric J. Bowman" <eric@...>
                        >To: "Walden Mathews" <waldenm@...>
                        >Cc: <rest-discuss@yahoogroups.com>
                        >Sent: Sunday, August 27, 2006 6:26 PM
                        >Subject: Re: [rest-discuss] Representations (Was: Resources as Orange
                        >Apples)
                        >
                        >
                        >: >
                        >: >Further, to your URI examples and content negotiation discussion,
                        >: >there is no need to implicate more than one resource (and therefore one
                        >: >URI) in modeling content negotiation. I think if you figure that out,
                        >: >you'll be well on your way to some rest from this subject, no pun
                        >: >intended.
                        >: >
                        >:
                        >: When implementing content negotiation, each alternate representation is
                        >also
                        >: its own resource with its own URI, this URI is returned in
                        >Content-Location.
                        >: I don't know how this is done without using multiple resources.
                        >:
                        >: -Eric
                        >:
                        >: >
                        >: >Walden
                        >: >
                        >:
                        >:
                        >:
                        >: __________ NOD32 1.1727 (20060826) Information __________
                        >:
                        >: This message was checked by NOD32 antivirus system.
                        >: http://www.eset.com
                        >:
                        >:
                        >
                        >
                      • Julian Reschke
                        ... No, it doesn t need to. It just can be that way. ... It doesn t need to be done that way in the first place. Best regards, Julian
                        Message 11 of 20 , Aug 28, 2006
                        • 0 Attachment
                          Eric J. Bowman schrieb:
                          >
                          >
                          > >
                          > >Further, to your URI examples and content negotiation discussion,
                          > >there is no need to implicate more than one resource (and therefore one
                          > >URI) in modeling content negotiation. I think if you figure that out,
                          > >you'll be well on your way to some rest from this subject, no pun
                          > >intended.
                          > >
                          >
                          > When implementing content negotiation, each alternate representation is
                          > also
                          > its own resource with its own URI, this URI is returned in
                          > Content-Location.

                          No, it doesn't need to. It just can be that way.

                          > I don't know how this is done without using multiple resources.

                          It doesn't need to be done that way in the first place.

                          Best regards, Julian
                        • Eric J. Bowman
                          ... Yes, I understand that Content-Location is optional, in fact that is why there s a VARY header. Either way, multiple representations are associated with
                          Message 12 of 20 , Aug 28, 2006
                          • 0 Attachment
                            >-----Original Message-----
                            >From: Julian Reschke [mailto:julian.reschke@...]
                            >Sent: Monday, August 28, 2006 12:13 AM
                            >To: eric@...
                            >Cc: 'Walden Mathews', rest-discuss@yahoogroups.com
                            >Subject: Re: [rest-discuss] Representations (Was: Resources as Orange Apples)
                            >
                            >Eric J. Bowman schrieb:
                            >>
                            >>
                            >> >
                            >> >Further, to your URI examples and content negotiation discussion,
                            >> >there is no need to implicate more than one resource (and therefore one
                            >> >URI) in modeling content negotiation. I think if you figure that out,
                            >> >you'll be well on your way to some rest from this subject, no pun
                            >> >intended.
                            >> >
                            >>
                            >> When implementing content negotiation, each alternate representation is
                            >> also
                            >> its own resource with its own URI, this URI is returned in
                            >> Content-Location.
                            >
                            >No, it doesn't need to. It just can be that way.
                            >

                            Yes, I understand that Content-Location is optional, in fact that is why
                            there's a VARY header. Either way, multiple representations are associated
                            with one URI. It is my belief that in a REST system, these variants should
                            be individually addressable as resources in their own right. Even if those
                            URIs are not sent in Content-Location when a system is deployed, that should
                            certainly be a capability of any implementation.

                            >
                            >> I don't know how this is done without using multiple resources.
                            >
                            >It doesn't need to be done that way in the first place.
                            >

                            No, of course not, not according to RFC 3296 or RFC 2616 but we are talking
                            about REST which is a best-practices subset of what is possible, aren't we?
                            If you can't assign each of your variants a URI, how do you know your negotiated resource isn't an endpoint?

                            When I first designed my RMS I didn't provide for any means of overriding
                            content negotiation, and I wasn't even worried about what URIs to assign the
                            variants. The VARY header did its job. But since I often discuss Web
                            Development I decided that I wanted to be able to link to back-compat
                            HTML 4.01 variants so that even users whose browsers would normally negotiate
                            for XHTML 1.1 could view them, without resorting to 300 Options.

                            In other words, I learned from experience several reasons not to forego the
                            _ability_ to send Content-Location even in situations where I don't send that
                            header.

                            My solution was to parameterize the URLs instead of using file extensions, or
                            a variety of other options many of which are equally viable. Even if I chose
                            not to send Content-Location, or if I chose not to respond to the
                            parameterized URLs by sending 404 errors, internally my system is based on
                            the REST architectural style so it is critical that I be able to identify
                            each of my variants with its own URI, at least in order to model the system.

                            I offer this proof of my RMS, based on the notation and diagrams I've been
                            developing. It's WIP. Feel free to use the PNGs I made however you want:

                            [1] http://canuck.bisonsystems.net/dev/rest/

                            -Eric

                            >
                            >Best regards, Julian
                            >
                            >
                            >
                          • Julian Reschke
                            ... I do agree that it s good to have a separate URI when there s a chance that that representation is authorable, or that people may want to bookmark it. It s
                            Message 13 of 20 , Aug 28, 2006
                            • 0 Attachment
                              Eric J. Bowman schrieb:
                              > Yes, I understand that Content-Location is optional, in fact that is why
                              > there's a VARY header. Either way, multiple representations are associated
                              > with one URI. It is my belief that in a REST system, these variants should
                              > be individually addressable as resources in their own right. Even if those
                              > URIs are not sent in Content-Location when a system is deployed, that
                              > should
                              > certainly be a capability of any implementation.

                              I do agree that it's good to have a separate URI when there's a chance
                              that that representation is authorable, or that people may want to
                              bookmark it. It's not entirely clear to my why it's desirable in the
                              general case (why does it matter?).

                              > No, of course not, not according to RFC 3296 or RFC 2616 but we are talking
                              > about REST which is a best-practices subset of what is possible, aren't we?
                              > If you can't assign each of your variants a URI, how do you know your
                              > negotiated resource isn't an endpoint?

                              How is that relevant to the client? Also, what's the definition of an
                              "endpoint"?

                              > ...

                              Best regards, Julian
                            • Eric J. Bowman
                              ... It matters because there is another resource involved whether one acknowledges its presence by assigning it a URI, or not. It does not matter to a
                              Message 14 of 20 , Aug 28, 2006
                              • 0 Attachment
                                >
                                >I do agree that it's good to have a separate URI when there's a chance
                                >that that representation is authorable, or that people may want to
                                >bookmark it. It's not entirely clear to my why it's desirable in the
                                >general case (why does it matter?).
                                >

                                It matters because there is another resource involved whether one
                                acknowledges its presence by assigning it a URI, or not. It does not matter
                                to a user-agent, it matters to the definition of content negotiation. When
                                a resource is negotiated, it is not a box of apples containing a Red
                                Delicious apple and a Golden Delicious apple. It is a box of apples which
                                has been divided into one container (bin) for Red Delicious apples and
                                another container for Golden Delicious apples. To dereference an apple one
                                is reaching into a box of apples, yes, but one is reaching into one bin or
                                the other, and those bins (boxes) should be identified with URIs in a REST
                                system simply because they're resources.

                                >
                                >How is that relevant to the client? Also, what's the definition of an
                                >"endpoint"?
                                >

                                Not sure where I said any of this is relevant to the client? The semantics
                                of the mapping for a REST resource is static, as can be shown using basic set
                                theory and simple two-circle Venn diagrams. When the semantics of the mapping
                                for a resource can't be defined in such fashion, I say that makes it non-
                                static and hence, an endpoint.

                                -Eric

                                >
                                >Best regards, Julian
                                >
                              • Julian Reschke
                                ... Well, no. There doesn t need to be another resource at all. Just because the representation varies on request parameters doesn t mean at all that there
                                Message 15 of 20 , Aug 28, 2006
                                • 0 Attachment
                                  Eric J. Bowman schrieb:
                                  > >I do agree that it's good to have a separate URI when there's a chance
                                  > >that that representation is authorable, or that people may want to
                                  > >bookmark it. It's not entirely clear to my why it's desirable in the
                                  > >general case (why does it matter?).
                                  > >
                                  >
                                  > It matters because there is another resource involved whether one
                                  > acknowledges its presence by assigning it a URI, or not. It does not matter

                                  Well, no. There doesn't need to be "another" resource at all. Just
                                  because the representation varies on request parameters doesn't mean at
                                  all that there must be another resource involved. It could be that way,
                                  but it doesn't have to be that way.

                                  > to a user-agent, it matters to the definition of content negotiation. When
                                  > a resource is negotiated, it is not a box of apples containing a Red
                                  > Delicious apple and a Golden Delicious apple. It is a box of apples which
                                  > has been divided into one container (bin) for Red Delicious apples and
                                  > another container for Golden Delicious apples. To dereference an apple one
                                  > is reaching into a box of apples, yes, but one is reaching into one bin or
                                  > the other, and those bins (boxes) should be identified with URIs in a REST
                                  > system simply because they're resources.

                                  So who says that a server should assign a URI to a resource even though
                                  it doesn't plan to make it accessible under that URI?

                                  > >How is that relevant to the client? Also, what's the definition of an
                                  > >"endpoint"?
                                  > >
                                  >
                                  > Not sure where I said any of this is relevant to the client? The semantics

                                  You said:

                                  "If you can't assign each of your variants a URI, how do you know your
                                  negotiated resource isn't an endpoint?"

                                  That's up to the server to decide, right? I don't think it makes sense
                                  to force URI assignment if a resource won't be accessible under it
                                  (actually, I would think that's a bad idea).

                                  Of course that doesn't mean it's a good idea to expose as much of your
                                  system's internals as possible as separate resources. However, REST
                                  doesn't seem to require that (or if it does, please point me to the text
                                  section).

                                  > of the mapping for a REST resource is static, as can be shown using
                                  > basic set
                                  > theory and simple two-circle Venn diagrams. When the semantics of the
                                  > mapping
                                  > for a resource can't be defined in such fashion, I say that makes it non-
                                  > static and hence, an endpoint.

                                  As I don't know what is meant by "endpoint", it's hard to argue with.

                                  Roy says:

                                  "More precisely, a resource R is a temporally varying membership
                                  function MR(t), which for time t maps to a set of entities, or values,
                                  which are equivalent. The values in the set may be resource
                                  representations and/or resource identifiers. A resource can map to the
                                  empty set, which allows references to be made to a concept before any
                                  realization of that concept exists -- a notion that was foreign to most
                                  hypertext systems prior to the Web [61]. Some resources are static in
                                  the sense that, when examined at any time after their creation, they
                                  always correspond to the same value set. Others have a high degree of
                                  variance in their value over time. The only thing that is required to be
                                  static for a resource is the semantics of the mapping, since the
                                  semantics is what distinguishes one resource from another."

                                  (<http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1>)


                                  Could you clarify how this definition relates to your usage of the term
                                  "endpoint"?

                                  Best regards, Julian
                                • Eric J. Bowman
                                  ... I don t know, who? I certainly didn t say that. I said when designing a site the server manager should be able to define all resources with URIs even if
                                  Message 16 of 20 , Aug 28, 2006
                                  • 0 Attachment
                                    >
                                    >So who says that a server should assign a URI to a resource even though
                                    >it doesn't plan to make it accessible under that URI?
                                    >

                                    I don't know, who? I certainly didn't say that. I said when designing a
                                    site the server manager should be able to define all resources with URIs
                                    even if there is no plan to make those URIs accessible. How does one go
                                    about designing a REST application using "mystery resources" which have no
                                    URIs?

                                    >
                                    >"If you can't assign each of your variants a URI, how do you know your
                                    >negotiated resource isn't an endpoint?"
                                    >
                                    >That's up to the server to decide, right? I don't think it makes sense
                                    >to force URI assignment if a resource won't be accessible under it
                                    >(actually, I would think that's a bad idea).
                                    >

                                    I'm speaking of the conceptualization of a website, not the realization of a
                                    website. The server decides nothing, it only does what the server manager
                                    tells it to do, nobody is suggesting the "forcing of URI assignments". I have
                                    a variety of URIs which are not available to the public, however, they have
                                    URIs so my system can address those resources internally.

                                    >
                                    >Of course that doesn't mean it's a good idea to expose as much of your
                                    >system's internals as possible as separate resources. However, REST
                                    >doesn't seem to require that (or if it does, please point me to the text
                                    >section).
                                    >

                                    A resource is a set, "the values in a set may be resource representations or
                                    resource identifiers". How can you have a resource under this definition if
                                    you have no resource identifier? Is it possible to access, or even generate,
                                    a representation of some resource which has no identifier?

                                    >
                                    >As I don't know what is meant by "endpoint", it's hard to argue with.
                                    >
                                    >Roy says:
                                    >
                                    >The only thing that is required to be
                                    >static for a resource is the semantics of the mapping, since the
                                    >semantics is what distinguishes one resource from another."
                                    >

                                    You keep asking me this and I keep giving the same response. _I_ define an
                                    endpoint to be some resource whose mapping semantics are variable. Is this
                                    so wrong? Should I stop? Any suggestions of what else to call such a
                                    resource?

                                    -Eric

                                    >
                                    >Best regards, Julian
                                    >
                                  • Eric J. Bowman
                                    ... If by infinite recursion you re referring to Russell s Paradox, I don t see how it applies here, where we are debating whether a box with two apples is one
                                    Message 17 of 20 , Aug 28, 2006
                                    • 0 Attachment
                                      >
                                      >The reality check, Eric, is this: since everything you can conceptualize
                                      >about
                                      >your application is a resource by definition, and because that definition
                                      >allows
                                      >infinite recursion via resource-representation relation, it is obviously not
                                      >feasible
                                      >to stamp every possible resource with a URI. Ergo: we must be reading
                                      >the advice in the wrong context.
                                      >

                                      If by infinite recursion you're referring to Russell's Paradox, I don't see
                                      how it applies here, where we are debating whether a box with two apples is
                                      one box or a box divided in two sections -- not whether it's one box or
                                      an infinite number of boxes.

                                      From the user-agent perspective, one resource returns multiple
                                      representations, from the server perspective I see those variants as their
                                      own resources. So I think it's important to model a system as if those were
                                      unique resources, whether or not those identifiers are opaque to the client.

                                      -Eric

                                      >
                                      >Walden
                                      >
                                      >
                                    • Eric J. Bowman
                                      Is this what you guys have in mind? http://canuck.bisonsystems.net/dev/rest/one_uri.html -Eric
                                      Message 18 of 20 , Aug 28, 2006
                                      • 0 Attachment
                                        Is this what you guys have in mind?

                                        http://canuck.bisonsystems.net/dev/rest/one_uri.html

                                        -Eric

                                        >
                                        >That's why I am recommending you examine a content negotiation
                                        >case that does not involve more than one URI. And see how you apply
                                        >set theory to that.
                                        >
                                        >Try it.
                                        >
                                        >Walden
                                        >
                                      • Walden Mathews
                                        Speaking for myself, no. You are modeling resources as sets, and you seem overall to be losing the distinction between resources and representations, although
                                        Message 19 of 20 , Aug 28, 2006
                                        • 0 Attachment
                                          Speaking for myself, no. You are modeling resources as sets, and
                                          you seem overall to be losing the distinction between resources and
                                          representations, although in some places you have it correct.

                                          Also, you have this inconsistency where at one point you say
                                          representations will not be identified with URI, then you go back on
                                          that promise by referring to a representation as a URI (which would
                                          be wrong even if you referred to a resource as a URI).

                                          To me, your model sounds like this:

                                          1. When you query a resource (via its URI) you will be given one
                                          out of a set of representations. (good so far)

                                          2. It is convenient (why?) to conceptualize every representation, which
                                          causes me to view it as a resource in my model. (still true to REST,
                                          but beginning to lead you astray)

                                          3. Therefore, when you query a resource, I will give you a resource
                                          from some set. (technically true, but definitely obscuring the basic
                                          REST relation of resource to representation at this point)

                                          4. As you can see from above, resources are containers for other
                                          resources. Ask for the box and I will give you something from in the
                                          box, maybe what you wanted. (misrepresents REST)

                                          Is this helpful?

                                          Walden

                                          ----- Original Message -----
                                          From: "Eric J. Bowman" <eric@...>
                                          To: "Walden Mathews" <waldenm@...>
                                          Cc: "Julian Reschke" <julian.reschke@...>; <rest-discuss@yahoogroups.com>
                                          Sent: Monday, August 28, 2006 6:08 PM
                                          Subject: Re: [rest-discuss] Representations (Was: Resources as Orange
                                          Apples)


                                          : Is this what you guys have in mind?
                                          :
                                          : http://canuck.bisonsystems.net/dev/rest/one_uri.html
                                          :
                                          : -Eric
                                          :
                                          : >
                                          : >That's why I am recommending you examine a content negotiation
                                          : >case that does not involve more than one URI. And see how you apply
                                          : >set theory to that.
                                          : >
                                          : >Try it.
                                          : >
                                          : >Walden
                                          : >
                                          :
                                          :
                                          :
                                          : __________ NOD32 1.1729 (20060828) Information __________
                                          :
                                          : This message was checked by NOD32 antivirus system.
                                          : http://www.eset.com
                                          :
                                          :
                                        • Eric J. Bowman
                                          ... That was just an editing oversight, it s been fixed now. ... This is the part of REST which gives me fits, I ll admit. Sometimes, all I need is a
                                          Message 20 of 20 , Aug 29, 2006
                                          • 0 Attachment
                                            >
                                            >Also, you have this inconsistency where at one point you say
                                            >representations will not be identified with URI, then you go back on
                                            >that promise by referring to a representation as a URI (which would
                                            >be wrong even if you referred to a resource as a URI).
                                            >

                                            That was just an editing oversight, it's been fixed now.

                                            >
                                            >2. It is convenient (why?) to conceptualize every representation, which
                                            > causes me to view it as a resource in my model. (still true to REST,
                                            > but beginning to lead you astray)
                                            >

                                            This is the part of REST which gives me fits, I'll admit. Sometimes, all I
                                            need is a real-world example, and sometimes a blatant and obvious one is
                                            right there in front of me and I miss it. One resource with two
                                            representations which are not resources themselves, would be a case where an
                                            XHTML 1.0 page is served as "application/xhtml+xml" to some user-agents and
                                            "text/html" to others.

                                            On the server, though, I count four resources: One unzipped cached output
                                            stream and one zipped cached output stream in "application/xhtml+xml", one of
                                            each of those also for "text/html". To a client those are representations,
                                            sometimes it takes a bit of bludgeoning me about the head to get me to step
                                            back from my implementation and see these things (also speak of them) in more
                                            general terms.

                                            >
                                            >3. Therefore, when you query a resource, I will give you a resource
                                            > from some set. (technically true, but definitely obscuring the basic
                                            > REST relation of resource to representation at this point)
                                            >

                                            I've been trying to say that I will give you a representation of some
                                            resource in the set. Ultimately the user receives an apple in my example,
                                            though, and I have clearly called the apples themselves representations.

                                            >
                                            >Is this helpful?
                                            >

                                            Yes and no. Yes, it helps me to see where I'm a bit off in my understanding.
                                            No, it doesn't help me with the problem of coming up with a simplified
                                            explanation for any of this. :(

                                            -Eric

                                            >
                                            >Walden
                                            >
                                            >----- Original Message -----
                                            >From: "Eric J. Bowman" <eric@...>
                                            >To: "Walden Mathews" <waldenm@...>
                                            >Cc: "Julian Reschke" <julian.reschke@...>; <rest-discuss@yahoogroups.com>
                                            >Sent: Monday, August 28, 2006 6:08 PM
                                            >Subject: Re: [rest-discuss] Representations (Was: Resources as Orange
                                            >Apples)
                                            >
                                            >
                                            >: Is this what you guys have in mind?
                                            >:
                                            >: http://canuck.bisonsystems.net/dev/rest/one_uri.html
                                            >:
                                            >: -Eric
                                            >:
                                            >: >
                                            >: >That's why I am recommending you examine a content negotiation
                                            >: >case that does not involve more than one URI. And see how you apply
                                            >: >set theory to that.
                                            >: >
                                            >: >Try it.
                                            >: >
                                            >: >Walden
                                            >: >
                                            >:
                                            >:
                                            >:
                                            >: __________ NOD32 1.1729 (20060828) Information __________
                                            >:
                                            >: This message was checked by NOD32 antivirus system.
                                            >: http://www.eset.com
                                            >:
                                            >:
                                            >
                                            >
                                          Your message has been successfully submitted and would be delivered to recipients shortly.