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

Re: [rest-discuss] Re: Deigning representations of collections and references

Expand Messages
  • Eric J. Bowman
    Have you looked at the threading extensions for Atom? http://www.ietf.org/rfc/rfc4685.txt I m not a big fan of the service document. As far as generic clients
    Message 1 of 15 , Feb 2, 2010
    • 0 Attachment
      Have you looked at the threading extensions for Atom?

      http://www.ietf.org/rfc/rfc4685.txt

      I'm not a big fan of the service document. As far as generic clients
      go, I think they can infer the editability of a resource by the
      presence of a link rel='edit' without needing to consult a service
      document. The response to a PUT request is what's authoritative, not
      any sort of service document. Allow headers work just as well to
      provide a hint as to acceptable methods.

      Where I do use a "service document" in an otherwise-Atom Protocol
      system, I repurpose Google's XML sitemaps so I have a hierarchical
      format, instead of using a root-level flat-file document to define a
      hierarchy.

      You can also have feeds of feeds in Atom, so I don't really understand
      the disadvantage you're seeing. I didn't propose Atom as the magical
      solution to your problem, merely as a way forward. Once you've
      identified its actual shortcomings, you're free to abandon it, but it
      will give you an awful lot of ideas on how to use link relations
      properly. See it through, though, since it provides a useful guideline
      on how to arrange and link collections.

      You can use standard link relations, even if you use your own
      vocabulary as a resource model. Better to use standard media types,
      though.

      -Eric

      "piers_lawson" wrote:
      >
      > Mike, thank you for pointing out the draft inlining spec... it was
      > interesting.
      >
      > Jan, I started off the thread suggesting a format similar to the one
      > that you put forward as one of my alternatives. I have been convinced
      > by the idea that really the collection should not contain Account
      > elements but some sort of link. The inlining idea is good in that it
      > formalises combining a link with some data from the target
      > resource.... at least it would be if the spec had moved forward from
      > being a draft ;-)
      >
      > However, what I'm really pushing for is an example of publishing a
      > feed (or even feeds) within other content, for example within the
      > seller element from my last post. If I end up with something similar
      > to my last post (i.e. a seller element that contains a feed element)
      > I'm back to a custom vocabulary... at which point I can't see the
      > advantage of using Atom feeds... a generic client would never find
      > the feeds in the first place (because my seller element doesn't look
      > anything like a Service document)... Any thoughts?
      >
    • piers_lawson
      Thanks for the quick response Eric. I m certainly not dismissing Atom yet and I hope I m learning a lot from it and this discussion. You mention a feed of feed
      Message 2 of 15 , Feb 2, 2010
      • 0 Attachment
        Thanks for the quick response Eric. I'm certainly not dismissing Atom yet and I hope I'm learning a lot from it and this discussion.

        You mention a feed of feed approach... would that be a <feed> element that represents the parent resource, which then contained an <entry> for each "collection"? With the <entry> containing a link to the feed for that child collection (and possibly also containing an <inline> to provide a high level view of the child feed's content)?

        I think what I'm missing is some good examples of using Atom outside of the basic scenario. So given a resource that has properties of its own, and perhaps is linked to at least one possibly two collections of other resources... how would you represent it? What XML would you envisage being returned when the parent is requested?

        Thanks everyone for your time!
      • Eric J. Bowman
        ... Yes. If the client wants to access a feed within a feed, it can follow the link rel= related instead of the link rel= self of an entry in the original
        Message 3 of 15 , Feb 2, 2010
        • 0 Attachment
          "piers_lawson" wrote:
          >
          > You mention a feed of feed approach... would that be a <feed> element
          > that represents the parent resource, which then contained an <entry>
          > for each "collection"? With the <entry> containing a link to the feed
          > for that child collection (and possibly also containing an <inline>
          > to provide a high level view of the child feed's content)?
          >

          Yes. If the client wants to access a feed within a feed, it can follow
          the link rel='related' instead of the link rel='self' of an entry in
          the original feed. The link rel='self' just points to the first entry
          in the sub-collection.

          This is the first I've heard of <inline>, so I can't answer as to that.

          -Eric
        • piers_lawson
          Thanks Eric, Could you post a small sample showing what you mean exactly. So a feed that contains one (or even better two feeds)... and for the parent feed and
          Message 4 of 15 , Feb 4, 2010
          • 0 Attachment
            Thanks Eric,

            Could you post a small sample showing what you mean exactly. So a feed that contains one (or even better two feeds)... and for the parent feed and the child feeds they contain some additional data beyond the standard fields supportted by Atom. I think an example would really solidify it in my mind.

            Thank you for your input so far!
          • Eric J. Bowman
            ... I m working on your example. The demo I posted shows what I m talking about, but I haven t worked the rest of my solution into the demo yet. When I have,
            Message 5 of 15 , Feb 8, 2010
            • 0 Attachment
              "piers_lawson" wrote:
              >
              > Could you post a small sample showing what you mean exactly. So a
              > feed that contains one (or even better two feeds)... and for the
              > parent feed and the child feeds they contain some additional data
              > beyond the standard fields supportted by Atom. I think an example
              > would really solidify it in my mind.
              >

              I'm working on your example. The demo I posted shows what I'm talking
              about, but I haven't worked the rest of my solution into the demo yet.
              When I have, I'll bump here. I'm almost finished (I think) making the
              XSLT also function in Opera (using a holistic approach to the cross-
              browser XSLT problem, rather than using @mode and an engine test, i.e.
              making some code specific to Mozilla's Transformiix processor or Opera's
              libxslt).

              After I've made the XSLT work with WebKit, I'll work those other tricks
              up my sleeve for dealing with collections into the demo. Then I'll make
              the XSLT work with IE, so I can get back to my original problem, which
              is dealing with Xforms. IE has a couple of nice Xforms extensions
              available.

              The result of this work, for me, will be a development style based on
              the union of subsets of XSLT 1.0, EXSLT and Xforms that works on the
              Web. And, a coding style (which can be validated using RELAX NG +
              Schematron) for hitting that cross-browser sweet spot, which results in
              code that also works for server-side transformation (if nothing else
              works, libxslt can be used on the server).

              Anyway, I ought to be able to provide an interesting collection example
              for you later this week.

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