I'll try and break this email down, and only include the stuff from the email I
was meant to send. I'm humiliated that I sent this email. I was generally
having a bad day and did the worst thing possible by letting this get sent.
Still there are a few points I want to now raise.
>
>> app:accept vs sword:acceptPackaging
Firstly ignore the whole first one cos it's in the Atom-Pub spec, so that's
fine, not necessarily correct, but there.
>
>> 6.4. Editing the Content of a Resource
>>
>> The client MAY provide an In-Progress header with a value of true or false
>> [SWORD001]
>
>> 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.
Both of these are in fact about which URI you are interacting with not what is
returned. If you are CRUD'ing to one URI the server should never return data
which is not related to that URI without some sort of 300 redirect.
So the response of the DELETE should always be relevant to the URI you have
just deleted.
The In-Progress header should refer only to the URI which it is related to,
since In-Progress (or status) is in fact a piece of metadata i'd recommend
moving it to the atom metadata and turning it into a category. Thus you move
the item through a workflow by changing the metadata.
Neither of these are EPrints specific, just general good practise of a web
server :)
>
>> 6.6. Adding Content to a Resource
I'll get onto this and point, just as a pointer however look at the 'Creating a
folder' section in the GDocs API.
>
> I strongly feel that you are too focussed on the EPrints implementation
> decisions where the GData API may be appropriate. We have try, with SWORD,
> to avoid getting bogged down in the details of the structure of information
> at either end of the protocol. We are purely concerned with deposit, not
> with content management, as we discussed early on.
>
I feel that you are too focussed on your use cases, and i'm too focussed on
mine which is why I have tried... several times... to get a time when we chat
and see if we can work some of the issues through and make them work for all
repositories. I would appreciate it if this time could be made at some point in
the future.
I cannot apologise enough for the previous email and any offence it caused. I
think I cracked badly on Monday, everyone can have one day right?
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
