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 ------------------------------------------------------------------------------ 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-d2dcopy1 _______________________________________________ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech
