One document matched: draft-divilly-atom-hierarchy-02.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3986 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY rfc4287 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml'>
]>
<!--<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'/ ?>-->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc tocdepth="3" ?>
<rfc category="exp" ipr="trust200811" docName="draft-divilly-atom-hierarchy-02">
<front>
<title abbrev="Atom Hierarchy Relations">Hierarchy Relations for Atom</title>
<author initials="C." surname="Divilly" fullname="Colm Divilly">
<organization>Oracle Corp.</organization>
<address>
<email>colm.divilly@oracle.com</email>
<uri>http://cdivilly.wordpress.com</uri>
</address>
</author>
<author initials="N. R." surname="Mehta" fullname="Nikunj R. Mehta">
<organization>Oracle Corp.</organization>
<address>
<email>nikunj.mehta@oracle.com</email>
<uri>http://o-micron.blogspot.com/</uri>
</address>
</author>
<date day="9" month="June" year="2009"/>
<abstract>
<t>
This specification defines link relations for hierarchical navigation
among Atom feeds and entries.
</t>
</abstract>
<note title="Editorial Note">
<t>
To provide feedback on this Internet-Draft, join the
<eref target="http://www.imc.org/atom-syntax/">atom-syntax mailing
list (http://www.imc.org/atom-syntax/)</eref>.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Many applications, besides blogs, provide their data in the form of
syndicated Web feeds using formats such as Atom <xref target="RFC4287"/>.
Some such applications organize Atom Entries in a hierarchical fashion
similar to a file system.
</t>
<t>
This specification describes a means of communicating about Atom Entries
that are hierarchically related to each other since resource identifiers
are opaque to clients and cannot be directly manipulated for the purposes
of representation exchange, i.e., navigation.
</t>
<t>
This specification proposes new link relations for hierarchically
related Atom resources.
</t>
<section title="Notational Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
<section title="Terminology" anchor="terminology">
<t>
This specification uses Atom link relations to identify different
types of links; see the Atom specification <xref target="RFC4287"/> for
information about their syntax, and the IANA link relation registry
for more information about specific values.
</t>
</section>
</section>
<section title="Hierarchy link relations" anchor="hierarchy-relations">
<t>
A hierarchy exists when a resource indicates the likelihood of the
existence of a parent and/or a child resource. The terms parent and
child are indicative of the need for the former to exist before the
latter can be created.
</t>
<section title="Modeling Hierarchy In Atom" anchor="hierarchy-model">
<t>
The Atom Syndication Format <xref target="RFC4287"/> defines the Atom Entry construct.
The extensions in this specification define two specialized kinds of Entry construct --
parent Entry and child Entry.
</t>
<t>
A parent Entry is a container for child Entries. A parent Entry
could itself be a child of another parent Entry.
</t>
<t>Every Entry construct is represented as an Atom Entry Document <xref target="RFC4287"/>
referred to in this specification as an "entry" and its plural. A logical
Feed comprising entirely of child entries of a given Entry is called
its child feed and one comprising entirely of its parent entries is
called its parent feed. Both parent feed and child feed are seen from the
perspective of a given Entry resource. The entries in the parent feed and
child feed of an Entry SHOULD be disjoint, i.e., not share any entries.
</t>
<t>
Applications MAY allow more than one parent Entry to contain a given
child Entry. This is similar to hard links in filesystems. On the
other hand, certain applications allow only a single parent Entry.
</t>
<t>
A child Entry MAY use a logical Feed to represent multiple parent
Entries. Alternatively, a child Entry MAY use multiple "up" atom:link
elements, each to identify one of the parent Entries.
</t>
</section>
<section title="The "down" Link" anchor="down-link">
<t>
An Atom link element with a rel attribute value of "down" may be
used to reference a resource where child entries of an entry may
be found. If the attribute of the atom:link is omitted, its value
is assumed to be "application/atom+xml".
</t>
<figure>
<preamble>
For example,
</preamble>
<artwork name="down link" type="example"><![CDATA[
<entry xmlns="http://www.w3.org/2005/Atom">
<title type="text">Hanky Panky Portfolio</title>
<link rel="down" type="application/atom+xml;type=feed"
href="/portfolios/1/positions/"/>
<link rel="down" type="text/html"
href="/portfolios/1;listing"/>
...
</entry>
]]></artwork>
</figure>
<t>
Although Atom feed, entry, and source elements MAY each contain any
number of atom:link elements using the "down" link relation, this
specification assigns no significance to the presence or order of
such links. Multiple down links appearing within an atom:entry
may reference alternative representations of the same set of
children or may reference entirely distinct resources containing
distinct sets of children. Processors MUST NOT assume that multiple
down links are referencing different representations of the same
resource and MUST process each down link independently of any
others.
</t>
</section>
<section title="The "up" Link" anchor="up-link">
<t>
An Atom link element with a rel attribute value of "up" may be
used to reference a resource where parent entries of an entry or a
feed may be found. If the attribute of the atom:link is omitted,
its value is assumed to be "application/atom+xml".
</t>
<figure>
<preamble>
For example,
</preamble>
<artwork name="down link" type="example"><![CDATA[
<feed xmlns="http://www.w3.org/2005/Atom">
<title type="text">Positions in Hanky Panky</title>
<link rel="self"
href="/portfoloios/1/positions/"/>
<link rel="up"
href="/portfolios/1"/>
...
</feed>
]]></artwork>
</figure>
<t>
Although Atom feed, entry, and source elements MAY each contain any
number of atom:link elements using the "up" link relation, this
specification assigns no significance to the presence or order of
such links. Multiple up links appearing within an atom:entry
may reference alternative representations of the same set of
parents or may reference entirely distinct resources containing
distinct sets of parents. Processors MUST NOT assume that multiple
up links are referencing different representations of the same
resource and MUST process each up link independently of any
others.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
Hierarchy Extensions for Atom is subject to the
security considerations found in Section 8 of <xref target="RFC4287"/>.
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This specification uses the following relation that has been previously
registered in the Link Relations Registry
<list style="symbols">
<t>Attribute Value: up</t>
<t>Description: A URI that refers to one or more parent resources
in a hierarchy of resources.</t>
<t>Expected display characteristics: none</t>
<t>Security considerations: See this specification</t>
</list>
</t>
<t>
This specification defines the following new relations that have been
added to the Link Relations registry:
<list style="symbols">
<t>Attribute Value: down</t>
<t>Description: A URI that refers to one or more child resources in a hierarchy
of resources.</t>
<t>Expected display characteristics: none</t>
<t>Security considerations: See this specification</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3986;
&rfc4287;
</references>
<section title="Acknowledgements">
<t>
Bill de hÓra and Ashish Motivala reviewed early drafts of this I-D. On the atom-syntax
mailing list, Al Brown, Julian Reschke, Mark Nottingham, Pablo Castro, and Kyle Marvin
provided very valuable feedback to improve the subsequent public drafts.
</t>
</section>
<section title="Revision History">
<t>
00 - Initial Revision.
</t>
<t>
00 - Based on feedback from Peter Keane, Julian Reschke, and members of the CMIS TC made the following changes:
<list style="hanging">
<t>Renamed the link relation "detail" to "down" and "master" to "up"</t>
<t>Removed Section 3, 4, 6, and 7</t>
<t>Changed namespace prefix from h to ah</t>
<t>Added new link relations "up-tree" and "down-tree"</t>
</list>
</t>
<t>
01 - Changes include:
<list style="hanging">
<t>In-line representations of linked resources are independent of hierarchy</t>
<t>Removed Atom specific language in link relation definitions</t>
<t>Made explicit that this specification re-uses existing 'up' link relation</t>
<t>Changed namespace prefix from ah to ae</t>
<t>Removed the ah:count attribute and added the ae:inline element</t>
</list>
</t>
<t>
02 - Changes include:
<list style="hanging">
<t>In-line extensions moved to draft-mehta-atom-inline</t>
<t>Removed down-tree and up-tree relations</t>
<t>Removed cardinality restrictions on up and down links</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:52:00 |