In coming are a few of my thoughts on the specification as I read it:
app:accept vs sword:acceptPackaging
* The SWORD server MUST specify the app:accept element. If the Collection can
take any format content type, it should specify */* as its value [AtomPub]. It
MUST also specify an app:accept element with an alternate attribute set to
multipart-related as required by [AtomMultipart]
* The SWORD server MAY include zero or more sword:acceptPackaging elements
[SWORD002]. The value SHOULD be a URI for a known packaging format (where such
URIs exist)
So there is an implied behaviour here? The second statement says I can do
something with this package, where the first says I accept this mime-type. This
is highly confusing in my view and you should either stick to one or the other.
What if the server only accepts PDF but in the packaging says it accepts bagit?
Should it say in the accept that it accepts zip? What if the package and the
accept are the same thing, e.g. a docx (which is also a zip...?)
I can see people becoming very confused here!
If we need both then they either both need to be mime-types or both need to be
URIs, or accept both. I feel this is a bodged solution to (1) keep to atom pub,
(2) Extend mime-types to URIs. Maybe what we are actually after is the server
to accept */* then the client to use a dc:Conforms to somehow to inform the
server on the packaging they are sending (thus not having to mint another
header). In the deposit receipt the server could then inform the client on the
capabilities it has to do stuff with this format/package. This provides a much
greater level of flexibility moving forward, but are we ready to include this
yet.
To retrieve the content in the desired packaging format, the client makes an
HTTP GET request to the EM-URI and MAY supply an Accept-Packaging header
[SWORD001] with the URI from one of the sword:packaging elements.
Same here, this is disgusting when we have the HTTP accept header which should
be the priority. I can see the point in using the accept-packaging header in
order to get round the mime-types vs URIs issue, however it would be better if
the whole lot was done using mime-types!
6.4. Editing the Content of a Resource
The client MAY provide an In-Progress header with a value of true or false
[SWORD001]
Not regarding the content it shouldn't, surely the whole item (defined by the
edit-URI) is In-Progress or not, not the content. E.G. can my blog post (which
includes, titie, tags, body text etc) be complete but the content still in
progress. No in my view, and this would be a bitch for the server to implement!
In-Progress should only be used on the container (Edit) URI.
6.5. Deleting the Content of a Resource
Should return the 200 header representing what has happened.
I'm against the delete operation on the content URI returning the receipt of
the edit-URI. No one asked for this, the client asked for the thing to be
deleted, not a statement or receipt! I've made this point before... it got
ignored. The client knows the edit-URI as as you say in your video Richard, if
you do a get on the Edit-URI you can get the receipt again. This is too
overblown here.
1) Client asks to delete object at any URI
2) Server returns http error code
If the server chooses to return anything else then the Content-Location header
MUST be used to define what it is returning. This is because the client
SHOULDN'T be able to call the same delete operation to get the same content as
the object should 404 or 410 at that point.
6.6. Adding Content to a Resource
Yuck! This section needs completely re-writing and/or removing. There is no
detail here on what the server should do with the random content it is given
and where it should go. If it is posted to the Edit-URI, is the a new EM-URI,
replace everything at the EM-URI or what. I think if you want to add content
(Media) into the container then you post it to the Edit-Media URI.
I really don't like this and think we should more closely consider GDocs API
here for how to handle containers and the limitations.
This whole fudge it and see it not going to help in the future.
Interestingly section 6.6.3 DOES use the EM-URI not the Edit-URI...? Any reason?
Other than that, this looks pretty good. I still believe it can be made much
better through better alignment with the GDocs API, this will also make it
simpler for both the server and client while enabling more functionality. I am
going to change a version of this spec to reflect this and then people can see
the main differences and capabilities. This also may rid the need for the
statement URI and make it simpler again.
Dave T
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Sword-app-techadvisorypanel mailing list
Sword-app-techadvisorypanel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
