Re: [Sword-TAP] My Thoughts

2011-03-22 Thread Tim Brody 
On Mon, 21 Mar 2011 21:17:32 -, Richard Jones  
 wrote:

> Hi Tim,
>
[snip]

>> I just echo what Dave Tarrant has said about talking in real-time with
>> this. I can see Richard has injected ideas from various sources into the
>> spec. but these ideas need to be thrashed out between multiple brains. I
>> was initially thinking we want to add behaviourial controls through  
>> headers
>> whereas I'm more convinced now that these should be IRI parameters,  
>> which
>> will make it more obvious that this IRI is going to behave differently  
>> to
>> the base IRI.
>
> Can you give us a few examples of what you imagined?

POST http://myrepo.org/app/workspace?suppress_metadata
Content-Type: application/msword
...

POST http://myrepo.org/app/workspace?suppress_metadata&unpack
Content-Type: application/zip
...

My rationale for this is two-fold:
1) The IRI (base+query) defines the behaviour and can be exposed using  
rel-links.
2) HTTP headers feel like they're the wrong level for controlling  
application behaviour.

It doesn't seem elegant to express an HTTP request where behaviour is  
controlled through both the METHOD+IRI and HTTP headers. Conceptually  
headers like Content-Type are describing the payload whereas  
Suppress-Metadata is explicitly telling the server to do something with  
the payload.

(NB I think we should be asserting extract-metadata instead of  
suppress-metadata. The default behaviour of extracting metadata may be  
more useful but it feels wrong to be asserting a negative - otherwise a  
client could end up having to suppress-printing, suppress-emailing,  
suppress-conversion-to-pdf etc. etc.!)


I strongly feel In-Progress should be an Atom category. Using a header,  
clients can't ascertain whether an item is "in-progress", which means  
clients can't be stateless and in addition have no mechanism to verify the  
server is treating the collection as "in-progress".

In-Progress as a header is also ambiguous in scope:
POST contents/ 
In-Progress: true
...
PUT em-uri/ 
...

Does that mean the  is no longer in-progress?

And last nail in the coffin ... how does a client make an entry no longer  
in-progress? Very weird semantic to perform a no-op edit (PUT) to change  
the state of an entry!

-- 
All the best,
Tim.

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-22 Thread Ian Stuart 
On 21/03/11 21:22, Richard Jones wrote:
> In my mind, we're not doing any package content editing, we're just
> either adding new/more packages to the server (possibly to the same
> container) or overwriting old ones, not giving the client a way to edit
> the contents of the packages.  The Statement, which might give this
> impression, is supposed to be informative rather than operational,
> except in cases where it is implemented as part of, say, GData.
>
> If some part of the profile is suggesting that packages can be edited by
> SWORD that should definitely be clarified.

I think the confusion arises because a client can say "Use Edit-IRI and 
make the title read 'English pronunciation'"

What we are (in reality) doing is Replacing, however we have tagged it 
as Editing - we can "Edit" any data element: add it, replace it, delete 
it we can even read it, munge it, and put it back.

Is that "Editing"?


-- 

Ian Stuart.
Developer: Open Access Repository Junction and OpenDepot.org
Bibliographics and Multimedia Service Delivery team,
EDINA,
The University of Edinburgh.

http://edina.ac.uk/

This email was sent via the University of Edinburgh.

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-21 Thread Richard Jones 
Hi Scott,

>> I think someone
>> earlier pointed out our methodology is RFC-orientated i.e. minimal,
>> well-defined and, where relevant, re-using existing Internet RFCs. CMIS, by
>> comparison, defines a full query language, ACLs, CMS-orientated APIs ...
>
> Exactly, which is why this  new "package content editing" aspect of the spec 
> concerns me.

Do you think you could expand on that a bit?

In my mind, we're not doing any package content editing, we're just 
either adding new/more packages to the server (possibly to the same 
container) or overwriting old ones, not giving the client a way to edit 
the contents of the packages.  The Statement, which might give this 
impression, is supposed to be informative rather than operational, 
except in cases where it is implemented as part of, say, GData.

If some part of the profile is suggesting that packages can be edited by 
SWORD that should definitely be clarified.

It certainly feels to me that the scope of SWORD is becoming clearer 
through this discussion - keep it up!

Cheers,

Richard


> I think to do this "right" you probably do need something like CMIS. I'm not 
> convinced its actually needed in SWORD at all, and goes against the 
> principles of simplicity that made it successful.
>
> Remember why we are even talking about packages - not because people want to 
> edit them, but because we have interop issues due to too many conflicting 
> sector-specific package+metadata content types.
>
>> What I've been pushing for with SWORD is:
>> 1) Re-use sensible paradigms from existing AtomPub profiles (CMIS/GData)
>> 2) Behave like an AtomPub implementation (i.e. don't MUST something that
>> isn't MUST in AtomPub)
>> 3) Modularise the spec. and features to enable flexibility
>
> +1
>
>>
>> I just echo what Dave Tarrant has said about talking in real-time with
>> this. I can see Richard has injected ideas from various sources into the
>> spec. but these ideas need to be thrashed out between multiple brains. I
>> was initially thinking we want to add behaviourial controls through headers
>> whereas I'm more convinced now that these should be IRI parameters, which
>> will make it more obvious that this IRI is going to behave differently to
>> the base IRI.
>>
>> --
>> All the best,
>> Tim.
>>
>> --
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
>
>
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
>



--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-21 Thread Richard Jones 
Hi Tim,

I believe that the SWORD spec already meets these requirements of yours:

> What I've been pushing for with SWORD is:
> 1) Re-use sensible paradigms from existing AtomPub profiles (CMIS/GData)

Well, it explicitly doesn't get in the way of you using them, I don't 
believe.  Although if you could verify that, that would be really 
helpful, as I'm not an expert on either CMIS or GData.

> 2) Behave like an AtomPub implementation (i.e. don't MUST something that
> isn't MUST in AtomPub)

This was an original aim of SWORD 2.0.  See, for example:

http://sword2depositlifecycle.jiscpress.org/identifiers/

I believe that the profile as published in first draft meets this 
requirement, but again it would be good to have that verified in case I 
missed anything.

> 3) Modularise the spec. and features to enable flexibility

Also an original aim of SWORD 2.0, which is what led us towards the 
structure presented on the website:

http://swordapp.org/sword-v2/sword-v2-specifications/

There are 4 Internet Draft style documents which break the various parts 
of sword out into re-usable specifications, and a profile which draws 
them together into SWORD 2.0.

Is this sufficiently modular, or did you have further modularisation in 
mind?  I was thinking about modularising the profile itself, but it 
seemed correct to keep the whole CRUD stuff together.  I imagined, for 
example, breaking authNZ out into a separate profile at some 
undetermined time in the future.

> I just echo what Dave Tarrant has said about talking in real-time with
> this. I can see Richard has injected ideas from various sources into the
> spec. but these ideas need to be thrashed out between multiple brains. I
> was initially thinking we want to add behaviourial controls through headers
> whereas I'm more convinced now that these should be IRI parameters, which
> will make it more obvious that this IRI is going to behave differently to
> the base IRI.

Can you give us a few examples of what you imagined?

Cheers,

Richard



--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-21 Thread Richard Jones 
Hi Dave,

>>> 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.

I see what you're saying.  It looks like this is also legitimate if a 
Content-Location header is provided, if I am interpreting the HTTP spec 
correctly (which is maybe not the case).

> So the response of the DELETE should always be relevant to the URI you have 
> just deleted.

So, I guess I'd want to clarify what "relevant" means here.  I can't 
find anything definitive in the HTTP spec which tells you how what you 
get back from the DELETE request should be related to the resource 
deleted.  Any references you have that I could look at?

> 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 :)

I agree that the In Progress header should only be supplied on the 
container.  In the next version of the profile I'll make that change.

In the mean time, though, once again: this exists as a header because 
when you are POSTing a ZIP file without an Atom Entry before it, there 
is no Atom Entry for a sword:inprogress element to be placed in.  Also, 
it's not the business of SWORD to be moving things through the workflow 
- that would be either a content management operation or some other 
class of administrative interface, which would be out of legitimate 
scope.  In Progress is intended purely to hint to the server that it 
might expect more content to be coming before the client considers the 
full deposit process finished.

>>> 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've been through the GDocs API, and believe that we've included enough 
in the SWORD spec to ensure that it's use is not prevented (to the point 
of being explicitly mentioned).  Also, I looked in the GData 3.0 spec 
for information on how to retrieve the feed of an object, rather than an 
entry, and it didn't say.  I presumed content negotiation (hence section 
6.8 of the sword profile), but perhaps you know where there's a formal 
definition of how this bit works - the GData documentation did seem a 
little bit all over the place?

I'll include some more details in the next version as to how to use 
SWORD extensions on any old URI, and that should hopefully be enough to 
combine it fully with GData.

See my other email about the scope of sword, and let me know what you think.

Cheers,

Richard



--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-21 Thread Richard Jones 
Hi Scott,

>> 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.
>>>
>>> This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job 
>>> as CMIS. Is there a good reason for creating a new spec here?
>>>
>>> If these kinds of operations (remotely manipulating the content of virtual 
>>> packages) are part of the core functions of SWORD, should it be a profile 
>>> of CMIS rather than AtomPub?
>>
>> I've tried /quite/ hard to get to grips with CMIS without a huge amount of 
>> success.  It seems extremely large and full of a lot of stuff which is way 
>> way way over the top for what SWORD is trying to achieve, as far as I can 
>> tell.
>
> It is indeed rather more complex than SWORD as it is handling content 
> management rather than just deposit -->
>
>>
>> Also, we tried in the business case/technical architecture document to 
>> position SWORD firmly in the "deposit" space rather than the "content 
>> management space" (which I may or may not have succeeded in doing). 
>> Certainly I can see the case that enabling CRUD means that you are doing 
>> some content management, so we're striving to keep the details of what we 
>> say based entirely on the aspects of transferring data point to point rather 
>> than mandating what happens to that data at either end (this is, for 
>> example, part of the reticence to formally incorporate GData).
>
>
> -->   and so we really have to make sure the scope is correct. It has veered 
> into CM with all these operations on the content of packages.

So, I think it's inevitable that there will be some operations which 
could be considered content management by the very nature of allowing 
CRUD.  But CMIS applies a domain model to the server end, which SWORD 
doesn't do - I think this is a key distinction.

I'd be interested in your comments on the other email that I sent just 
now about the scope of sword.

>> So, profiling CMIS seems like a massive undertaking and a large burden on 
>> the implementers just to make sense of what they would or wouldn't have to 
>> implement.  Could you comment on that, do you think?
>
> Actually I don't think profiling CMIS would be at all necessary. If SWORD is 
> about deposit, and CMIS is about CM, then implementers can choose the specs 
> they want to support based on the functionality they want to expose.
>
> So some implementations may just want to support deposit with some packaging 
> format hints, while others may want to look at implementing CMIS (e.g. using 
> CMIS libraries such as Apache Chemistry) - either instead of or as well as 
> SWORD.
>
> At the moment there seems to be an assumption that a solution halfway between 
> SWORD 1.x and CMIS is desirable.

I think that even half way to CMIS is a pretty long way  :)

>> What does seem possible is that we could adopt terms from the CMIS namespace 
>> to use in SWORD, rather than minting new terms.  I'm thinking, for example, 
>> of cmis:createdBy being used instead of sword:depositedBy, although there's 
>> some argument to be had over whether those two are really the same thing.  
>> Could you possibly suggest some similarities in terms in CMIS that might be 
>> appropriate for reuse in SWORD?
>
> See above ...
>
>>
>> Also, do you know of any good introductions to CMIS that are bit more 
>> penetrable than the specification that I could look at?
>
> Playing with the Apache Chemistry libs is probably more rewarding than 
> reading the spec as you can see what its doing.
>
> http://chemistry.apache.org/

Thanks, that sent me off on a pretty useful direction.  For anyone else 
interested in CMIS, I found this basic introduction pretty instructive:

http://www.oldschooltechie.com/blog/2009/11/23/introduction-cmis

Cheers,

Richard



--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-18 Thread Alistair Miles 
On Fri, Mar 18, 2011 at 09:46:57AM +, Tim Brody wrote:
> What I've been pushing for with SWORD is:
> 1) Re-use sensible paradigms from existing AtomPub profiles (CMIS/GData)
> 2) Behave like an AtomPub implementation (i.e. don't MUST something that
> isn't MUST in AtomPub)
> 3) Modularise the spec. and features to enable flexibility

+1 - this is nicely put. Point (2) especially strikes a chord.

Cheers,

Alistair

--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health 
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: [email protected]
Tel: +44 (0)1865 287669

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-18 Thread Alistair Miles 
On Wed, Mar 16, 2011 at 10:52:27PM +, Richard Jones wrote:
> > 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.
> 
> Oh for god's sake Dave, grow up.  It did not get ignored because you and 
> I had a long discussion about it in person.  I argued that since all the 
> other operations can optionally supply a response to a DELETE request, 
> it was inconsistent to not be able to supply one in this one instance. 
> Additionally, the deposit receipt is strictly optional in ALL cases as 
> per the specification.  You argued that DELETE doesn't allow a response 
> (and should return 204), and this turned out to be untrue when I pointed 
> you to the HTTP spec.  I'd appreciate it if you'd actually remember the 
> discussions we've had about this before having a strop.

FWIW, in our data repository implementations, some collections use Atom
tombstones [1,2], and some don't. For collections that use tombstones, a DELETE
request will return a 200 with an at:deleted-entry as the response body. For
collections that do not use tombstones, a DELETE request will return 204.

So I believe it is reasonable to return some content in response to a DELETE
request. Whether you should or not will depend on what the client needs. I
remember seeing some ideas around clients being able to express a preference
for 204 or 200 in response to DELETE, but I don't know if that went anywhere.

Cheers,

Alistair

[1] http://tools.ietf.org/html/draft-snell-atompub-tombstones-12
[2] http://code.google.com/p/atombeat/wiki/TombstonesDesign - ignore the stuff 
about ghosts, that's probably going to change

> 
> > 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.
> 
> It's strictly optional as per the document.  If you don't want to return 
> a receipt in your implementation, then don't.
> 
> > 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.
> 
> I will add the requirements on the Content-Location header to the spec 
> if that's the appropriate thing to do.  I'm still a little unsure about 
> how Location and Content-Location should be used ... have to go do some 
> more reading of the HTTP spec.
> 
> > 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.
> 
> POST to the EM-URI implies something about the structure of the Media on 
> the server.  POST to the Edit-URI is the appropriate RESTful way to add 
> new content to a container.
> 
> There is no detail on what the server should do because SWORD is an 
> interface definition not a set of implementation decisions.  How the 
> server implements a POST of new content to the container is up to the 
> precise mechanisms of the application ...
> 
> > I really don't like this and think we should more closely consider GDocs 
> > API here for
> > how to handle containers and the limitations.
> 
> We have tried to ensure that the GData spec is not ruled out by SWORD, 
> but it brings with it its own set of idioms with regard to hierarchical 
> file systems which may be appropriate for EPrints, but is not 
> necessarily appropriate for all other scholarly information systems.  As 
> such, I'm reticent to propose it as /part/ of SWORD but I do want to 
> ensure that you can implement it /as well as/ SWORD.
> 
> I spent some time working through the GData 3.0 spec and was unable to 
> find any information about exactly how they think you should get hold of 
> the feed representation of an entry.  I have assumed content negotiation 
> on the Edit-URI (see Section 6.8), but if you could confirm for me how 
> Google recommend this is done that would be useful.
> 
> > This whole fudge it and see it not going to help in the future.
> 
> this doesn't appear to be a sentence.  can you reword/expand?
> 
> > Interestingly section 6.6.3 DOES use the EM-URI not the Edit-URI...? Any 
> > reason?
> 
> Typo, by the looks of it, I will fix that.
> 
> >

Re: [Sword-TAP] My Thoughts

2011-03-18 Thread Scott Wilson 

On 18 Mar 2011, at 09:46, Tim Brody wrote:

> On Thu, 17 Mar 2011 21:55:37 +, Scott Wilson
>  wrote:
>> On 17 Mar 2011, at 21:28, Richard Jones wrote:
>> 
>>> On 17/03/11 08:43, Scott Wilson wrote:
 
 On 17 Mar 2011, at 00:25, David Tarrant wrote:
>> 
>>> 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.
 
 This whole area of SWORD (secs 6.4-6.6) is effectively doing the same
 job as CMIS. Is there a good reason for creating a new spec here?
 
 If these kinds of operations (remotely manipulating the content of
 virtual packages) are part of the core functions of SWORD, should it be
 a profile of CMIS rather than AtomPub?
>>> 
>>> I've tried /quite/ hard to get to grips with CMIS without a huge amount
>>> of success.  It seems extremely large and full of a lot of stuff which
>>> is way way way over the top for what SWORD is trying to achieve, as far
>>> as I can tell.
>> 
>> It is indeed rather more complex than SWORD as it is handling content
>> management rather than just deposit -->
> 
> Hi,
> 
> My instinct is CMIS is only worth pursuing if you need to talk to an
> existing system talking CMIS (e.g. Microsoft Sharepoint).

Or indeed a system that incorporates CMS functionality such as a VLE. 

However my argument is: if it looks like CMIS-type functionality, leave it to 
CMIS and out of SWORD. Implementers that are interested in that level of 
interop can go implement CMIS if they think its worth it. 

i.e. don't try to make SWORD into "simple CMIS"

> I think someone
> earlier pointed out our methodology is RFC-orientated i.e. minimal,
> well-defined and, where relevant, re-using existing Internet RFCs. CMIS, by
> comparison, defines a full query language, ACLs, CMS-orientated APIs ...

Exactly, which is why this  new "package content editing" aspect of the spec 
concerns me.

I think to do this "right" you probably do need something like CMIS. I'm not 
convinced its actually needed in SWORD at all, and goes against the principles 
of simplicity that made it successful.

Remember why we are even talking about packages - not because people want to 
edit them, but because we have interop issues due to too many conflicting 
sector-specific package+metadata content types.

> What I've been pushing for with SWORD is:
> 1) Re-use sensible paradigms from existing AtomPub profiles (CMIS/GData)
> 2) Behave like an AtomPub implementation (i.e. don't MUST something that
> isn't MUST in AtomPub)
> 3) Modularise the spec. and features to enable flexibility

+1

> 
> I just echo what Dave Tarrant has said about talking in real-time with
> this. I can see Richard has injected ideas from various sources into the
> spec. but these ideas need to be thrashed out between multiple brains. I
> was initially thinking we want to add behaviourial controls through headers
> whereas I'm more convinced now that these should be IRI parameters, which
> will make it more obvious that this IRI is going to behave differently to
> the base IRI.
> 
> -- 
> All the best,
> Tim.
> 
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel


--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-18 Thread Tim Brody 
On Thu, 17 Mar 2011 21:55:37 +, Scott Wilson
 wrote:
> On 17 Mar 2011, at 21:28, Richard Jones wrote:
> 
>> On 17/03/11 08:43, Scott Wilson wrote:
>>> 
>>> On 17 Mar 2011, at 00:25, David Tarrant wrote:
> 
>> 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.
>>> 
>>> This whole area of SWORD (secs 6.4-6.6) is effectively doing the same
>>> job as CMIS. Is there a good reason for creating a new spec here?
>>> 
>>> If these kinds of operations (remotely manipulating the content of
>>> virtual packages) are part of the core functions of SWORD, should it be
>>> a profile of CMIS rather than AtomPub?
>> 
>> I've tried /quite/ hard to get to grips with CMIS without a huge amount
>> of success.  It seems extremely large and full of a lot of stuff which
>> is way way way over the top for what SWORD is trying to achieve, as far
>> as I can tell.
> 
> It is indeed rather more complex than SWORD as it is handling content
> management rather than just deposit -->

Hi,

My instinct is CMIS is only worth pursuing if you need to talk to an
existing system talking CMIS (e.g. Microsoft Sharepoint). I think someone
earlier pointed out our methodology is RFC-orientated i.e. minimal,
well-defined and, where relevant, re-using existing Internet RFCs. CMIS, by
comparison, defines a full query language, ACLs, CMS-orientated APIs ...

What I've been pushing for with SWORD is:
1) Re-use sensible paradigms from existing AtomPub profiles (CMIS/GData)
2) Behave like an AtomPub implementation (i.e. don't MUST something that
isn't MUST in AtomPub)
3) Modularise the spec. and features to enable flexibility

I just echo what Dave Tarrant has said about talking in real-time with
this. I can see Richard has injected ideas from various sources into the
spec. but these ideas need to be thrashed out between multiple brains. I
was initially thinking we want to add behaviourial controls through headers
whereas I'm more convinced now that these should be IRI parameters, which
will make it more obvious that this IRI is going to behave differently to
the base IRI.

-- 
All the best,
Tim.

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-17 Thread Scott Wilson 
On 17 Mar 2011, at 21:28, Richard Jones wrote:

> Hi Scott,
> 
> On 17/03/11 08:43, Scott Wilson wrote:
>> 
>> On 17 Mar 2011, at 00:25, David Tarrant wrote:
 
> 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.
>> 
>> This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job as 
>> CMIS. Is there a good reason for creating a new spec here?
>> 
>> If these kinds of operations (remotely manipulating the content of virtual 
>> packages) are part of the core functions of SWORD, should it be a profile of 
>> CMIS rather than AtomPub?
> 
> I've tried /quite/ hard to get to grips with CMIS without a huge amount of 
> success.  It seems extremely large and full of a lot of stuff which is way 
> way way over the top for what SWORD is trying to achieve, as far as I can 
> tell.

It is indeed rather more complex than SWORD as it is handling content 
management rather than just deposit -->

> 
> Also, we tried in the business case/technical architecture document to 
> position SWORD firmly in the "deposit" space rather than the "content 
> management space" (which I may or may not have succeeded in doing). Certainly 
> I can see the case that enabling CRUD means that you are doing some content 
> management, so we're striving to keep the details of what we say based 
> entirely on the aspects of transferring data point to point rather than 
> mandating what happens to that data at either end (this is, for example, part 
> of the reticence to formally incorporate GData).


-->  and so we really have to make sure the scope is correct. It has veered 
into CM with all these operations on the content of packages.

> 
> So, profiling CMIS seems like a massive undertaking and a large burden on the 
> implementers just to make sense of what they would or wouldn't have to 
> implement.  Could you comment on that, do you think?

Actually I don't think profiling CMIS would be at all necessary. If SWORD is 
about deposit, and CMIS is about CM, then implementers can choose the specs 
they want to support based on the functionality they want to expose. 

So some implementations may just want to support deposit with some packaging 
format hints, while others may want to look at implementing CMIS (e.g. using 
CMIS libraries such as Apache Chemistry) - either instead of or as well as 
SWORD.

At the moment there seems to be an assumption that a solution halfway between 
SWORD 1.x and CMIS is desirable.

> 
> What does seem possible is that we could adopt terms from the CMIS namespace 
> to use in SWORD, rather than minting new terms.  I'm thinking, for example, 
> of cmis:createdBy being used instead of sword:depositedBy, although there's 
> some argument to be had over whether those two are really the same thing.  
> Could you possibly suggest some similarities in terms in CMIS that might be 
> appropriate for reuse in SWORD?

See above ... 

> 
> Also, do you know of any good introductions to CMIS that are bit more 
> penetrable than the specification that I could look at?

Playing with the Apache Chemistry libs is probably more rewarding than reading 
the spec as you can see what its doing.

http://chemistry.apache.org/

> 
> Cheers,
> 
> Richard
> 
> 
> 


--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-17 Thread Richard Jones 
Hi Scott,

On 17/03/11 08:43, Scott Wilson wrote:
>
> On 17 Mar 2011, at 00:25, David Tarrant wrote:
>>>
 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.
>
> This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job as 
> CMIS. Is there a good reason for creating a new spec here?
>
> If these kinds of operations (remotely manipulating the content of virtual 
> packages) are part of the core functions of SWORD, should it be a profile of 
> CMIS rather than AtomPub?

I've tried /quite/ hard to get to grips with CMIS without a huge amount 
of success.  It seems extremely large and full of a lot of stuff which 
is way way way over the top for what SWORD is trying to achieve, as far 
as I can tell.

Also, we tried in the business case/technical architecture document to 
position SWORD firmly in the "deposit" space rather than the "content 
management space" (which I may or may not have succeeded in doing). 
Certainly I can see the case that enabling CRUD means that you are doing 
some content management, so we're striving to keep the details of what 
we say based entirely on the aspects of transferring data point to point 
rather than mandating what happens to that data at either end (this is, 
for example, part of the reticence to formally incorporate GData).

So, profiling CMIS seems like a massive undertaking and a large burden 
on the implementers just to make sense of what they would or wouldn't 
have to implement.  Could you comment on that, do you think?

What does seem possible is that we could adopt terms from the CMIS 
namespace to use in SWORD, rather than minting new terms.  I'm thinking, 
for example, of cmis:createdBy being used instead of sword:depositedBy, 
although there's some argument to be had over whether those two are 
really the same thing.  Could you possibly suggest some similarities in 
terms in CMIS that might be appropriate for reuse in SWORD?

Also, do you know of any good introductions to CMIS that are bit more 
penetrable than the specification that I could look at?

Cheers,

Richard




--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-17 Thread Scott Wilson 

On 17 Mar 2011, at 00:25, David Tarrant wrote:
>> 
>>> 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. 

This whole area of SWORD (secs 6.4-6.6) is effectively doing the same job as 
CMIS. Is there a good reason for creating a new spec here? 

If these kinds of operations (remotely manipulating the content of virtual 
packages) are part of the core functions of SWORD, should it be a profile of 
CMIS rather than AtomPub? 
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-17 Thread Scott Wilson 
On 17 Mar 2011, at 00:25, David Tarrant wrote:

> 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.

Its highly useful! Not all SWORD services are going to care about packaging 
specs. So being able to say talk about Zip/Gzip/Tar archive MIME types is still 
useful.
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-16 Thread David Tarrant 
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-16 Thread Richard Jones 
Hi Dave,

> 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...?)

First of all, this is the behaviour from SWORD 1.3, and I'm not aware of 
any particular confusion regarding it.

Secondly, if a server can't announce consistent app:accept and 
sword:acceptPackaging elements, that's not really an issue with the 
profile but with the server implementation.  The same issues arise in 
content negotiation, as we have covered extensively on this list.

In the case of docx, since this has a mime-type, I don't see any problem 
with supplying this as an app:accept.  If you made up a URI for it you 
could put it in the sword:acceptPackaging element too.

> I can see people becoming very confused here!

And yet so far, since this has been in place since 2008, no such 
confusion has been indicated to me (perhaps I missed it?).

This is really no more confusing than the existing content negotiation 
headers in HTTP.  The answer - in the absence of a hard solution to that 
problem - is a bit of common sense on both sides.

> 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.

Unfortunately, we can't have mime-types for both, as there are simply 
not mime-types for the package formats (unless you happen to know of a 
mime-type which uniquely identifies a DSpace METS package?).  Meanwhile 
app:accept only takes mime-types, not URIs.

This is therefore a solution which a) avoids confusing pure AtomPub 
implementations and b) allows the server to accurately identify the 
packaging formats it supports.

The client cannot supply a dc:conforms to the server unless it also 
sends an Atom Entry with it, which is not a requirement, so that 
approach won't work.  This is the reason we have for pushing all of that 
information up into the HTTP headers.

The last part of your point above I can't make sense of.  In the deposit 
receipt (i.e. after deposit) the server tells the client what it can do 
with the package.  Doesn't that seem somewhat after-the-fact?

> 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!

Then in which case if you could supply us with the mime-types for every 
conceivable package format that would be great.

Otherwise you may try to see this as a pragmatic solution to an actual 
existing problem.  SWORD is, of course, open to alternatives which meet 
the requirements.

> 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.

I can see what you're saying, the spec is not sufficiently clear on this 
point.

The intention is that the In-Progress header refers to the container,

Re: [Sword-TAP] My Thoughts

2011-03-14 Thread David Tarrant 
OK, just realised that I wan't going to send the original email, I had another 
version which I then deleted. This was just me writing things as I was reading 
the spec, much of which I then thought about some more and realised there was a 
reason for some of it. 

Oops.

Oh well too late now. I'll try and re-phrase it tomorrow. 

A simple specification is really hard to write and I have much respect for 
Richard for even trying. 

My points below still stand.

Cheers

Dave T


On 14 Mar 2011, at 19:58, David Tarrant wrote:

> 
>> 
>> Thanks for the comments so far, they have been really useful.  Any more 
>> comments (either in agreement of the spec, or in disagreement with it) would 
>> be appreciated.  We hope to get the team of 7 project developers starting to 
>> implement this soon once the review has been finished.  The implementation 
>> experience will no doubt then highlight the need for some more changes.
> 
> Please bear in mind that I am one of those members and have been implementing 
> prototypes for some while. This has informed my comments greatly however the 
> current spec is highly confusing and a mash of many of the user requirements 
> which have been raised up to this point. 
> 
> I would therefore highly recommend that a community meeting between as many 
> available members is arranged to try and sort through the various use cases 
> and issues face to face before the spec becomes final. In it's current state 
> I can't see many clients, or servers being able to implement this within 
> their current limitations. 
> 
> There are many issues which I feel cannot be expressed fully and completely 
> in an email and what chances I have had to get together with Richard have 
> been fleeting and usually focussed on other issues. For this reason and many 
> others, my experiences have not been fed back properly. I hope that this can 
> be resolved in the near future as I feel this a hugely important step in 
> actually producing a usable and interoperable specification. 
> 
> I started revising the specification today to make it simpler and reflect my 
> own work. Perhaps this can be diff'd against the published specification and 
> discussed at such a meeting. 
> 
> I hope that time limitations are not forcing the project to complete quickly 
> at this point as this is a vital stage to try and get right. 
> 
> I am willing to travel somewhere soon if such a meeting can be arranged to 
> discuss this specification and work through the sticking points.
> 
> Cheers
> 
> Dave T
> 
> 
>> 
>> Thanks,
>> 
>> 
>> Stuart Lewis
>> 
>> SWORD Community Manager
>> 
>> 
>> --
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
> 
> 
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel


--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-14 Thread David Tarrant 

> 
> Thanks for the comments so far, they have been really useful.  Any more 
> comments (either in agreement of the spec, or in disagreement with it) would 
> be appreciated.  We hope to get the team of 7 project developers starting to 
> implement this soon once the review has been finished.  The implementation 
> experience will no doubt then highlight the need for some more changes.

Please bear in mind that I am one of those members and have been implementing 
prototypes for some while. This has informed my comments greatly however the 
current spec is highly confusing and a mash of many of the user requirements 
which have been raised up to this point. 

I would therefore highly recommend that a community meeting between as many 
available members is arranged to try and sort through the various use cases and 
issues face to face before the spec becomes final. In it's current state I 
can't see many clients, or servers being able to implement this within their 
current limitations. 

There are many issues which I feel cannot be expressed fully and completely in 
an email and what chances I have had to get together with Richard have been 
fleeting and usually focussed on other issues. For this reason and many others, 
my experiences have not been fed back properly. I hope that this can be 
resolved in the near future as I feel this a hugely important step in actually 
producing a usable and interoperable specification. 

I started revising the specification today to make it simpler and reflect my 
own work. Perhaps this can be diff'd against the published specification and 
discussed at such a meeting. 

I hope that time limitations are not forcing the project to complete quickly at 
this point as this is a vital stage to try and get right. 

I am willing to travel somewhere soon if such a meeting can be arranged to 
discuss this specification and work through the sticking points.

Cheers

Dave T


> 
> Thanks,
> 
> 
> Stuart Lewis
> 
> SWORD Community Manager
> 
> 
> --
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel


--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] My Thoughts

2011-03-14 Thread Stuart Lewis 
Helpful language:
-
This is highly confusing / I can see the point, however / What if...

Unhelpful language:
---
This is disgusting / this would be a bitch / Yuck

If we could bear that in mind when reviewing the spec, that would be 
appreciated.

Thanks for the comments so far, they have been really useful.  Any more 
comments (either in agreement of the spec, or in disagreement with it) would be 
appreciated.  We hope to get the team of 7 project developers starting to 
implement this soon once the review has been finished.  The implementation 
experience will no doubt then highlight the need for some more changes.

Thanks,


Stuart Lewis

SWORD Community Manager


--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel