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:
1. 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.
2. 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 <http://www.twitter.com/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
