I withdraw the proposal/plea for a simpler, less verbose mechanism for expressing a hierarchy in atom in a single document. Since the group finds value in a generic mechanism and would be useful as well for CMIS in non-hierarchy use cases, I doubt it makes sense to standardize two approaches for the same similar functionality.
If it is not a huge cost, I would prefer the generic inlining mechanism to be a separate I-D since it is only generically related to hierarchy. >RFC 4287 already defines a similar constraint for @rel="alternate". RFC 4287 provides two discriminators for link elements in addition to rel, and processors use >this to select one that is suitable for the purpose, and these are type and hreflang. Since down defines a formal relation between the referrer and the referee, it is >necessary to have a clear meaning for multiple occurrences of that relation. Therefore the text above. If you can propose an alternate resolution of the issue I >identified just now, I'll be interested in reviewing it. I don't actually see a need to resolve multiple occurrences of that relation. Multiple relations of 'up' are multiple parents - feeds or entries. Multiple relations of 'down' are multiple children. The client can chose to follow none, one or all of those links. In most scenarios, there will probably only be one up and one down link relation though. Changing MUST to SHOULD would be better, though omitting that statement entirely would be better. I see a problem with that restriction in RC4287 in exposing alternate renditions/transcodings of that resource specifically when the variance happens inside the media type and is not language-specific such as bit rate (low or high bandwidth video) or height and width (color vs b/w, small, medium or large). It is one of the reasons why I prefer not to state items in a specification unless there is clear reason to do so. This is actually a problem for CMIS in leveraging alternate link relation in exposing image representation of resources as there may be more than one thumbnail of different sizes. Another use case is different image representation of CAD drawings at different scale or orientation. -Al Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email [email protected] CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. From: "Nikunj R. Mehta" <[email protected]> To: Al Brown/Costa Mesa/i...@ibmus Cc: Atom-Syntax Syntax <[email protected]> Date: 06/08/2009 12:17 PM Subject: Re: New Version Notification for draft-divilly-atom-hierarchy-01 On Jun 5, 2009, at 2:06 PM, Al Brown wrote: The 01 draft is a much better. I am concerned the generic mechanism using inlining links is sub-optimal for displaying a hierarchy that this I-D helps navigate via the new link relations. I read "displaying" as conveying, since Atom format is all about a representation, and not a rendering. First example: there are two down relations: down and down-tree. It is important to have both of those link relations on the [standalone] atom entry that represents a folder so the client can chose a flat (feed) or tree (expanded feed) representation. With you so far. If the client chooses the tree representation, then on the atom feed returned the server will inline using the link relation down. down-tree is not expanded with content inline. E.g., When producing an entry representation, e.g., for a folder, the server may go one level deep by in-lining the "down" relation but not in-lining the entries in the already in-lined link. Or it can choose to arbitrarily in-line linked resources. The communication between the client and the server about what representation is desirable may either be out of band, or be a part of the request (either through query parameters or custom headers) <atom:entry> ... <!-- children level 1 --> <atom:link rel="down" type="application/atom+xml;type=feed" href="/finance/feeds/default/portfolios/1/positions"> <ae:inline> <atom:feed> <!-- /a --> <atom:entry> ... <!-- children level 2 for /a --> <atom:link rel="down" href="/finance/feeds/default/portfolios/1/positions"/> ... <ae:inline> <atom:feed> <!-- entry /a/1 --> <atom:entry> ... <atom:link rel="down" href="/finance/feeds/default/portfolios/1/positions/down"> <!-- repeats --> </atom:link> <atom:link rel="down-tree" href="/finance/feeds-tree/default/portfolios/1/positions/down" /> ... </atom:entry> </atom:feed> </ae:inline> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </atom:feed> </ae:inline> </atom:link> <atom:link rel="down-tree" type="application/atom+xml;type=feed" href="/finance/feeds-tree/default/portfolios/1/positions" /> ... </atom:entry> I can't make sense of this example since it appears to be not well-formed XML (omitting ellipsis). Can you, perhaps, retry with a well-formed example? Also, your concern is not clear (to me). The contents of the down link relation will be what should be included in the down-tree due to recursion through the atom entries. Having a separate extension element, side-steps this issue of expression. Is this related to your concerns about duplication [1]. If so, let me say that a server can choose to in-line where it finds the need to and not, where it doesn't. In fact, it may be possible to get rid of the down-tree relation, if the representation of "down" can be in-lined to a suitable depth. That may actually be preferable anyway. Second example: verbosity This proposal now has: <atom:entry> ... <atom:link rel="down" type="application/atom+xml;type=feed" href="/finance/feeds/default/portfolios/1/positions"> <ae:inline> <atom:feed> <atom:link rel="self" href="/finance/feeds/default/portfolios/1/positions"/> ... <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </atom:feed> </ae:inline> </atom:link> ... </atom:entry> instead of a simpler mechanism: <atom:entry> ... <ah:include rel="down"> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> <atom:entry>...</atom:entry> </ah:include> ... </atom:entry> The I-D introduces a concept of hierarchy through up/up-tree/down-tree/down relations yet a all-purpose mechanism for inclusion. Most (all?) of the information on the feed element is duplicated on the enclosing entry (id, uri, etc). If verbosity is a concern, then the fact that we repeat the text "atom:entry" about 8 times in the above example is a valid target. However, that is besides the point. Even if we were to take the "simpler mechanism", you would still have to put in id, title, updated, etc. because the definition of atom:entry requires those things. See Section 4.1.2 of RFC 4287. BTW, link is not one of the required elements in a valid entry, so you could skip it in either case. Can't we do better for this specific scenario the I-D is addressing? Yes, the server can avoid sending anything in the in-lined entry that is not required for being treated as valid Atom by RFC 4287. This is unrelated to the hierarchy I-D. Also, Are there reasons for the statements below? A resource may be involved in many different independent hierarchies - e.g., folder structure, file plan, etc. Most of which we probably cannot imagine right now, but may be used in a year or two. This also conflicts with the current 'up' relation which, as not stated otherwise, allows multiple 'up' link relations in a single entry or feed. Section 4.1:[1] >An entry MUST NOT contain more than one atom:link element with a rel attribute value of "down" that has the same combination of type and >hreflang attribute values. RFC 4287 already defines a similar constraint for @rel="alternate". RFC 4287 provides two discriminators for link elements in addition to rel, and processors use this to select one that is suitable for the purpose, and these are type and hreflang. Since down defines a formal relation between the referrer and the referee, it is necessary to have a clear meaning for multiple occurrences of that relation. Therefore the text above. If you can propose an alternate resolution of the issue I identified just now, I'll be interested in reviewing it. Section 4.2: >An entry MUST NOT contain more than one atom:link element with a rel attribute value of "down-tree" that has the same combination of type and >hreflang attribute values. Section 5.1: >A feed MUST NOT contain more than one atom:link element with a rel attribute value of "up" that has the same combination of type and hreflang >attribute values. Section 5.2: >An entry MUST NOT contain more than one atom:link element with a rel attribute value of "up-tree" that has the same combination of type and >hreflang attribute values. -Al [1] http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html Al Brown Emerging Standards and Industry Frameworks CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home Office 714 327 3453 Mobile 714 263 6441 Email [email protected] CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation. <graycol.gif>"Nikunj R. Mehta" ---06/05/2009 11:18:07 AM---All the feedback on this mailing list has been really useful. We have revised the I-D to reflect the thinking about in-lining i <ecblank.gif> <ecblank.gif> From: "Nikunj R. Mehta" <[email protected]> <ecblank.gif> <ecblank.gif> To: Atom-Syntax Syntax <[email protected]> <ecblank.gif> <ecblank.gif> Date: 06/05/2009 11:18 AM <ecblank.gif> <ecblank.gif> Subject: Fwd: New Version Notification for draft-divilly-atom-hierarchy-01 All the feedback on this mailing list has been really useful. We have revised the I-D to reflect the thinking about in-lining inside atom:link using foreign markup. We've also made the use of in-line representations independent of the the new link relations. Looking forward to comments and implementation experience. 01 - Changes include: In-line representations of linked resources are independent of hierarchy Removed Atom specific language in link relation definitions Made explicit that this specification re-uses existing 'up' link relation Changed namespace prefix from ah to ae Removed the ah:count attribute and added the ae:inline element Text: http://www.ietf.org/internet-drafts/draft-divilly-atom-hierarchy-01.txt HTML: http://www.oracle.com/technology/tech/feeds/spec/draft-divilly-atom-hierarchy.html Nikunj http://o-micron.blogspot.com Begin forwarded message: From: IETF I-D Submission Tool <[email protected]> Date: June 5, 2009 10:06:45 AM PDT To: [email protected] Cc: [email protected] Subject: New Version Notification for draft-divilly-atom-hierarchy-01 A new version of I-D, draft-divilly-atom-hierarchy-01.txt has been successfuly submitted by Nikunj Mehta and posted to the IETF repository. Filename: draft-divilly-atom-hierarchy Revision: 01 Title: Inlining and Hierarchy Extensions for Atom Creation_date: 2009-06-05 WG ID: Independent Submission Number_of_pages: 11 Abstract: This specification defines mechanisms for in-lining representations of linked resources and for hierarchical navigation among Atom feeds and entries.Editorial Note To provide feedback on this Internet-Draft, join the atom-syntax mailing list (http://www.imc.org/atom-syntax/) [1]. The IETF Secretariat.
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
