[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CMIS-329) Representation ofchildren in hierarchical representations
[ http://tools.oasis-open.org/issues/browse/CMIS-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018#action_17018 ]
Al Brown commented on CMIS-329:
-------------------------------
JIRA Cleanup
> Representation of children in hierarchical representations
> ----------------------------------------------------------
>
> Key: CMIS-329
> URL: http://tools.oasis-open.org/issues/browse/CMIS-329
> Project: OASIS Content Management Interoperability Services (CMIS) TC
> Issue Type: Bug
> Components: REST/AtomPub Binding
> Reporter: Cornelia Davis
> Assignee: Al Brown
> Fix For: Draft 0.62
>
>
> As has been previously posted (http://lists.oasis-open.org/archives/cmis/200906/msg00347.html, http://lists.oasis-open.org/archives/cmis/200906/msg00371.html), we are really down to two options on the format for representing hierarchy in CMIS.
> What we refer to as option 3 is one where a folder entry has a cmis:children element that contains multiple atom:entry elements. In outline form it looks like:
> <atom:entry>
> <atom:title>Folder A</atom:title>
> ...
> <cmis:children>
> <atom:entry>
> <atom:title>Folder B</atom:title>
> ...
> </atom:entry>
> ... more atom entries ...
> </cmis:children>
> </atom:entry>
> What we refer to as option 4 is one where a folder entry has a cmis:children element that wraps an atom:feed element that then contains multiple atom:entry elements.
> <atom:entry>
> <atom:title>Folder A</atom:title>
> ...
> <cmis:children>
> <atom:feed>
> ... a bunch of feed stuff ...
> <atom:entry>
> <atom:title>Folder B</atom:title>
> ...
> </atom:entry>
> ... more atom entries ...
> <atom:feed>
> </cmis:children>
> </atom:entry>
> Option 3 has at least two advantages over option 4:
> • Option 3 will have a smaller representation because it does not include the feed and the elements that are required of a feed (i.e. the "bunch of feed stuff" shown in option 4 above)
> • Option 3 results in a simpler server side implementation (see Al's previous post on the subject)
> In spite of these advantages I believe that option 3 has one significant disadvantage over option 4, and that is that we fundamentally have two different representations for the same resource requiring that client developers must have two implementations of a function depending on how the resource representation was retrieved. Let me explain with an example.
> Suppose a client developer has written some code to display certain things about a children collection - they want to display the name of the collection, the last updated value, a list of the children and they want to have a button that allows the user to select this location as a target of a new item creation. This code executes against a feed retrieved via the URL to that child collection (URL could have been bookmarked for example). The pseudocode for this is something like:
> void processCollectionResource(feed childrenResource) {
> String title = childrenResource.getTitle();
> Date lastModified = childrenResource.getUpdated();
> // get the URL of the link relation with rel="self"
> URL postURL = childrenResource.getLinkURL("self");
> Iterate childrenResource.getEntries() {
> // so something with each child
> // (this will be the same in both cases)
> }
> // do something with all of this - render, etc.
> }
> Now the client realizes they want to do the same thing but against a set of children that are embedded within a hierarchical representation. Let's first look at the pseudocode for option 4.
> There is code that has to parse the child collection out - it is something along the lines of:
> feed childrenResource = folderResource.getChildren().getFeed();
> processCollectionResource(childrenResource);
> And the processCollectionResource method can be used as is.
> For option 3, I need to pass in the folder resource and start parsing from there, because some of the information I need is at the folder and some of it is in the cmis:children element. So I'd make a call something like:
> processCollectionResourceEmbedded(folderResource);
> And the new code to process this slightly different representation is:
> void processCollectionResourceEmbedded(entry folderResource) {
> String title = folderResource.getTitle();
> Date lastModified = folderResource.getUpdated();
> // get the URL of the link relation with rel="down"
> // NOTE!!!! that the code is less self contained here - self
> // is more direct than down
> URL postURL = folderResource.getLinkURL("down");
> Iterate folderResource.getChildren().getEntries() {
> // so something with each child
> // (this will be the same in both cases)
> }
> // do something with all of this - render, etc.
> }
> Of course, the developer COULD have written the original method to take in a folder resource but then that says that the client shouldn't write anything that goes against collection resource, instead they should write everything to go against the entry resource. I think that is a bad constraint and one, that quite frankly, won't be understood by a great many people.
> Some might say that writing the second instantiation of this code is no big deal and sure, it's not that hard. But consider that I might have several such processor methods and now I have 2x bodies of code to test, maintain, etc. and we are required to do this because CMIS defines a proprietary container element instead of using the standardized container element of atom:feed.
> Sure, embedding a feed duplicates some of the values from the folder entry to the feed, but I think that is a reasonable trade for the simplicity and elegance that it offers the client.
> I strongly suspect that it is exactly this analysis that drive gData to embed an atom:feed inside of their children element.
> So my closing arguments are these. Let's not define a proprietary container element - let's use feeds to represent sets of entries. Let's not trade sever implementation ease for client burden. And let's pay the penalty of some duplication of feed properties for the benefits we get in return.
> Thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]