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:
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<mailto: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<mailto:kathi.fletc...@shuttleworthfoundation.org>
Alternate Email: kathi.fletc...@gmail.com<mailto:kathi.fletc...@gmail.com>
Twitter: kefletcher<http://www.twitter.com/kefletcher>
Skype: kef-sky
Blog: kefletcher.blogspot.com<http://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
