Need to explain flat and nested feeds in completion in the Rest binding

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major
    • None
    • Affects Version/s: None
    • Component/s: REST/AtomPub Binding
    • None
    • Hide

      Clarify - nested feed + its semantics in the spec
      repeated if repeated in the tree
      same level of infomation
      clarify returnToRoot - it is nested not flat in a feed + order object -> root

      Show
      Clarify - nested feed + its semantics in the spec repeated if repeated in the tree same level of infomation clarify returnToRoot - it is nested not flat in a feed + order object -> root

      The whole thing about flat and nested feeds in the AtomPub binding needs an entire chapter to describe it. It is not good enough to just say "flat" or "nested" in a couple of places and not be more specific everywhere a feed is specified. If there are two "flavors" of feeds, then it needs to be clear which flavor is expected, and do this everywhere that a feed is called out.

      It is our preference to avoid nested feeds, but if they're necessary the TC should propose some description an usage examples. Specifically, we need to know:
      o in every case where there is a feed, it needs to be specified if it's flat or nested (or just specify the ones that are actually nested).
      o what happens when documents are multi-filed? do their properties, etc. get repeated each and every time they occur in a nested feed? in a flat feed, they would only be found once.
      o are nested entries any different than top-level? i.e. includeAllowableActions, filter, summary, etc?
      o in the case of the folderParent/returnToRoot, in what order is the nesting? Part I says the folder immediate parent is to be returned first, and the root folder last. Also, the resource requested is the immediate parent. These two things thus imply that the parent folder should be the outer entry, and the root folder is the deepest nested? This is upside-down to what logic would dictate.

            Assignee:
            Al Brown (Inactive)
            Reporter:
            Ryan McVeigh (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: