Subject: How to represent hierarchical entries (Was: Atom Best Practice for directory file listing?)

From: Farrukh Najmi <[email-masked]>
Date: Thu, 04 Oct 2007 08:28:03 -0400

No one has responded to my question below in many days so I will repeat 
it in simpler terms in the hope that someone will take the time to respond.

Does ATOM support hierarchical entries in a feed where an entry has 
another entry nested inside it?
If not, what is the suggested way to handle that use case? The classic 
example is an atom feed for a directory tree where each entry is a node 
in the tree. How would one go about representing that in ATOM?

Farrukh Najmi wrote:
>
> Hello,
>
> I am new to ATOM and have a followup question to the archived message 
> below.
>
> Since a folder can contain other folders thus defining a item 
> hierarchy how is this hierarchical content best represented in an ATOM 
> feed? A modified example based on original from archived message below 
> would be terrific. Thanks.
>
> <archived message>
>
> One important thing to keep in mind is that the author element is only
> required in an entry if it does not exist at the feed level, so you
> really do not need to worry about entry level authors.
>
> This is just off the top of my head, so this might not entirely work,
> but if I were building an Atom feed from a directory listing, I'd likely
> do something like the following:
>
> <feed xmlns="...">
>  <id>file:/path/to/the/folder</id> <!-- or whatever else works -->
>  <title>folder name</title>
>  <updated>{folder last modified timestamp}</updated>
>  <link rel="self" href="..." />
>  <link rel="alternate" href="..." />
>  <author><name /></author> <!-- the name can be empty-->
>
>  <entry>
>    <id>file:/path/to/the/file</id>
>    <title>filename</title>
>    <updated>{file last modified timestamp}</updated>
>    <link rel="alternate" type="..." href="file:/path/to/the/file" />
>    <summary>filename, type, last modified, size, etc. Info that would
>      typically appear in a directory listing</summary>
>  </entry>
>
> </feed>
>
> It really shouldn't need to get anymore complicated than that.
>
> - James
>
> </archived message>
>

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com

---

From: Eric Scheid <[email-masked]>
Date: Thu, 04 Oct 2007 23:41:01 +1000

> another entry nested inside it?

no

> in the tree. How would one go about representing that in ATOM?

atom:link

e.

---

From: James M Snell <[email-masked]>
Date: Thu, 04 Oct 2007 07:59:17 -0700

> another entry nested inside it?

Not directly.  One way of accomplishing this would be to nest the entry
within the atom:content element, e.g.

<entry xmlns="http://www.w3.org/2005/Atom">
  ...
  <content type="application/atom+xml;type=entry">
    <entry>
      ...
      <content type="application/atom+xml;type="entry">
        <entry>
          ...
        </entry>
      </content>
    </entry>
  </content>
</entry>

That, however, can become quite unwieldly in practice.  Another approach
would be to have each entry as a separate file and use the src attribute.

<!-- entryA.atom -->
<entry xmlns="http://www.w3.org/2005/Atom">
  ...
  <content type="application/atom+xml;type=entry"
           src="entryB.atom" />
</entry>

<!-- entryB.atom -->
<entry xmlns="http://www.w3.org/2005/Atom">
  ...
  <content type="application/atom+xml;type=entry"
           src="entryC.atom" />
</entry>

<!-- entryC.atom -->
<entry xmlns="http://www.w3.org/2005/Atom">
  ...
</entry>

This has the upside of being easier to handle but requires additional
roundtrips.

- James

---

From: "Patrick Logan" <[email-masked]>
Date: Thu, 4 Oct 2007 11:23:31 -0700

Yeah, what they said.

I'm pretty stupid when it comes to atom, but we're looking at how to
apply it in some enterprisey situations with some fairly simple
information (e.g. "business partner"), and with some fairly complex
hierarchical information (e.g. "insurance policy and all risks it
covers").

So far it looks like the deeply hierarchical stuff would be linked and
entries describing the various parts will exist on their own to
represent manipulations at the level of the part.

The parts in and of themselves are not "entries" though. So you might
get a feed of entries at the policy level. The policy content would
link directly to a risk, or a party playing a role in the policy,
or... i.e. the policy would not be linked to an entry for the risk,
party, ...

But say a change of address occurs for some party. Then an entry for
that party would show up in a feed. The party content would also link
back one way or another to the associated policies. But again it would
not link back to an entry for that policy.

Not sure if I answered anyone's questions, but if that triggers any emotions...

-Patrick

---

From: Bill de hOra <[email-masked]>
Date: Thu, 04 Oct 2007 20:25:19 +0100

http://www.citizensinformation.ie/categories/social-welfare/irish-social-welfare-system/atom.zip

cheers
Bill