As usual you are way ahead of me :) Looking forward to hearing more. /dff
> -----Original Message----- > From: Stuart Lewis [mailto:s.le...@auckland.ac.nz] > Sent: 13 October 2011 09:43 > To: David FLANDERS > Cc: sword-app-tech@lists.sourceforge.net > Subject: Re: [sword-app-tech] FW: Use of In-Progress header and the SE- > IRI vs. the EM-IRI > > Hi David, > > Documenting the use cases for SWORD is a high priority for us - we > actually have a journal article currently in review that lists the > different uses that we know of, and for each we have a case study of > how SWORD is being used (or could be used) to facilitate this. > > We'll forward details once we know more. > > We're also now working on the same type of thing, but looking > specifically at data deposit use cases, with an analysis of how well > SWORD can meet these requirements. > > Cheers, > > > Stuart > > > On 13/10/2011, at 9:11 PM, David FLANDERS wrote: > > > Hi Kathi, For the sake why you "cannot edit a published item" in the > "connexions model" do you think you could provide the basic use cas? - > apologies if this is obvious for an OER side as most of the use cases > we have collected have been from a research PoV. > > > > @Richard, Stuart - the other interesting thing I'm finding here is > the evolution of SWORD from v1 where the blog entry was the basic use > case we spoke about when adopting ATOM pub versus the more elaborate > scholarly CRUD use case for SWORD v2. I think these basic use cases > are really important for dev coming upon SWORD for the first time so > that we have an explicit use case example for each of the SWORD > versions... I think the spec is so focused on looking profession as an > IETF that we need some low steps for humans by which people can > understand and think about this? I'm sure we have this inte blog or > somewhere, but perhaps putting it in the spec somewhere near the top so > it is not just all formal spec? /2p /dff > > > > > > From: Kathi Fletcher > [mailto:kathi.fletc...@shuttleworthfoundation.org] > > Sent: 12 October 2011 18:32 > > To: Richard Jones > > Cc: sword-app-tech@lists.sourceforge.net; Roché Compaan; Carl > Scheffler > > Subject: Re: [sword-app-tech] FW: Use of In-Progress header and the > SE-IRI vs. the EM-IRI > > > > Richard, thanks for the reply. I didn't immediately figure out how to > unify it with what Connexions is doing, but I think that I have finally > had an epiphany about SE-IRI, EM-IRI and In-Progress and why I was > having such a disconnect with "marking" an object as "In-Progress" so > that you would know its state for actions on the EM-IRI. > > > > Although AtomPUB is simpler than SWORD, it helped me to think of a > blog entry as a model. So I might create a blog entry, and either mark > it as "draft" (like In-Progress) or publish it straight away. And > whether or not it is a draft or published, I can send a new image using > the EM-IRI. This action should never effect whether the thing is draft > or published. I think this is essentially what you were explaining > below. > > > > In the Connexions model, because you CANNOT edit a published item, > but rather must create a new version and publish that, the scenario > above never happens. We are implementing SWORD through the editing > environment, which is all "draft". > > > > One of the following two scenarios occur: > > . You either create a new draft and publish it right away (In- > Progress=false). No more editing is possible after this action. You > never get an action on the EM-IRI in this case. > > . You create a new draft with In-Progress=true, do PUTs and POSTs > to modify and add stuff. And then you eventually publish. > > So I think that the Connexions implementation can be compliant AND > enjoy the following simplifications: > > . Actions on the EM-IRI always assume In-Progress=true. Thus, no > marking is necessary. > > . Publish never occurs due to actions on the EM-IRI. > > I think the second bullet is actually true for all implementations of > SWORD V2. If In-Progress is false and you get an action to the EM-IRI, > that won't ever cause publishing to occur. It either already has > occured, or it is in some workflow that is proceeding along > orthogonally to this latest edit. Perhaps this latest edit satisfies > some final requirement, but again, something already in motion is > evaluating that. > > > > Kathi > > > > On Tue, Oct 4, 2011 at 5:01 AM, Richard Jones > <rich...@cottagelabs.com> wrote: > > Hi Kathi, > > > > Sorry I didn't pick this up from the sword-app-tech list earlier. > > There are some responses/justifications inline. > > > > > In implementing SWORD-V2, having the In-Progress header for all > actions on > > > the SE-IRI, but not having it on actions on the EM-IRI, turns out > to add a > > > fair amount of complication. I am wondering if that complication is > actually > > > buying anyone anything useful. > > > > Its interesting that that's the case, as it is actually omitted (in > > part) to avoid complication ... > > > > > So on the SE-IRI, you just check the In-Progress header (or the > implied > > > default value of 'false' if the header is missing) in order to > determine > > > whether to publish the resource after the action is taken. > > > > > > > > > > > > But actions on the EM-IRI are supposed to respect the previous > > > In-Progess='true' header on some prior SE-IRI action. So that means > that we > > > need to decide what the default "prior" setting for In-Progress is > if the > > > action to EM-IRI is the first action. I assume that would be > 'false' for > > > consistency. And it also means that services have to figure out a > place to > > > save state somewhere to record that flag and make sure that it is > always > > > properly initialized and maintained. This is the only place that > additional > > > state has to be created. > > > > The key here is that you can /never/ take your first action on the > > EM-IRI, because this IRI doesn't exist until a container has been > > created. The important identifiers in the interactions are: > > > > Col-IRI - the Collection identifier, to which the first action must > > take place. This is a POST of either a binary object, an atom entry > > or a multipart object, and results in the creation of the container. > > During creation you would specify the In-Progress header to indicate > > that the created object is to be held back from the workflow > > > > Edit-IRI/SE-IRI - the container's identifier; this is the entry point > > to the object itself at the server end. All operations regarding the > > object's state must be directed to this IRI (or the SE-IRI, which is > > almost always going to be the same), and therefore In-Progress is > > allowed here. Retrieving the Edit-IRI will give you an atom entry > > document which will contain the EM-IRI. Therefore, you cannot have > > acquired an EM-IRI until you have already created an object. > > > > EM-IRI - The identifier of the media contained in the container. > > Since this is a media level identifier, it cannot be used to make > > decisions about the container itself, and this is why In-Progress is > > forbidden here. If you were to allow In-Progress to be sent to this > > identifier, the server would need to understand whether the new media > > files being deposited were "in progress" or whether the header > referrs > > to the container as a whole. This resolution of a complex state is > > likely to be different per implementation, and also makes the > > specification itself far more confusing than is viable (we did try > > doing this, btw), but also is inconsistent with the nature of REST. > > > > > I can't figure out why we don't just use the header in all cases? > What > > > benefit accrues from not using the header on actions on EM-IRI? > What is not > > > using it for actions on the EM-IRI saving? If we use the header in > all cases > > > then the publish logic is always the same and super simple: check > the header > > > or its implied default. > > > > > > > > > > > > Thoughts? > > > > Hopefully the above clarifies the decision process. The crux, > > ultimately, is that In-Progress on the EM-IRI would not be RESTful, > > and the consequences of violating this principle bring uncertainty in > > the implementation and complexity in the profile. > > > > Does that make sense? > > > > Cheers, > > > > Richard > > > > > > > > -- > > Kathi Fletcher > > Email: kathi.fletc...@shuttleworthfoundation.org > > Alternate Email: kathi.fletc...@gmail.com > > Twitter: kefletcher > > Skype: kef-sky > > Blog: kefletcher.blogspot.com > > Phone: US 862-345-6178 > > > > --------------------------------------------------------------------- > --------- > > All the data continuously generated in your IT infrastructure > contains a > > definitive record of customers, application performance, security > > threats, fraudulent activity and more. Splunk takes this data and > makes > > sense of it. Business sense. IT sense. Common sense. > > http://p.sf.net/sfu/splunk-d2d- > oct_______________________________________________ > > sword-app-tech mailing list > > sword-app-tech@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech
