From: Heiko Theissen, SAP:
At the Grid-Interop 2011, we discussed the use of atom:link elements with rel="up" in the Green Button file format. These links are meant to point from an atom:entry (e.g., /UsagePoint/1/MeterReading/1) to its hierarchically superordinate atom:entry (e.g., /UsagePoint/1), and we came to the conclusion that they should use, e.g., href="/UsagePoint/1", whereas in the examples given in the NAESB draft they use href="/UsagePoint/1/MeterReading", i.e., they point to a collection, not to an entry.
On my flight home, I have thought about this question again, and I now consider our conclusion premature.
Although up-links that point to an entry make it easier to select the hierarchically superordinate atom:entry, they prevent the other direction, making it impossible to select the hierarchically subordinate entries. For example, an <atom:link rel="up" href="/UsagePoint/1"/> would not only be found in the atom:entries for the MeterReadings, but also in the atom:entries for the ElectricPowerUsageSummaries, and these two kinds of subordinate entries cannot be distinguished without decomposing the URLs in the hrefs, what we wanted to avoid in the first place.
On the other hand, up-links that point to collections make it possible to elegantly select (with the help of XPath expressions) both the superordinate and the subordinate elements. Given an atom:entry element, we can select
• the hierarchically superordinate element by putting the context on the given atom:entry's up-link and evaluating the XPath expression
../../atom:entry[atom:link[@rel="related"]/@href=current()/@href]
(we select the entry whose related-link points to the same collection as the current up-link)
• the hierarchically subordinate elements of a given type (e.g., the MeterReadings, but not the ElectricPowerUsageSummaries) by putting the context on the corresponding related-link and evaluating the XPath expression
../../atom:entry[atom:link[@rel="up"]/@href=current()/@href]
(we select the entries whose up-links point to the same collection as the current related-link).
These selections work for 1:n relationships between super- and subordinate elements, where both the related-link and the up-link have type="application/atom+xml;type=feed".
But there are also 1:1 relationships
• either hierarchically from a super- to a subordinate element (e.g., the ElectricPowerQualitySummary subordinate to a UsagePoint) where both links have type="application/atom+xml;type=entry"
• or associations independent of the hierarchy (e.g., the ReadingType related to a UsagePoint), here the related-link has type="application/atom+xml;type=entry" (but the up-link of the ReadingType points to the feed of ReadingTypes and has type="application/atom+xml;type=feed").
In the case of such 1:1 relationships, analogous XPath expressions to the ones shown above can be used, where [@rel="up"] is replaced by [@rel="self"] (and the parenthesised "we select" remarks should read "the same entry" instead of "the same collection").
To summarise: I now believe that the up-links given in the NAESB draft are perfectly valid.