his may well define the way that I work
for the duration of the project.
Initially, I think we need to be clear about the requirements.
(BTW, if we get some implementation experience, I may attempt to
progress the specs to Draft Standard status.)
#g
--
Richard Jones wrote:
Hi Folks,
Thanks, this is r
Hi Ian,
On 18/01/11 12:11, Ian Stuart wrote:
On 10/01/11 18:49, Richard Jones wrote:
It's looking like a separate header is the way to do this, with the
following couple of options immediately standing out:
Accept-Features (or X-Accept-Features if it isn't sufficiently official)
X-P
Hi Ian,
- Simplification of acceptPackaging: surely the list of what's not
accepted is (in essence) infinite? The list of package types (even if
they are defined by some Internet Taskforce) will grow over time.
This NEEDS to be a "list of things I understand" - be they "I can give
you in one of
On 19/01/11 10:16, Scott Wilson wrote:
On 19 Jan 2011, at 10:05, Ian Stuart wrote:
On 19/01/11 09:49, Scott Wilson wrote:
I would suggest SWORD is completely agnostic on the subject of
packaged content formats, but that the SWORD implementation community
make a concerted effort to identify a
Hi Rob,
* URIs used in Statements.
Could you either unpack this section a little, or give an example? When
reading in conjunction with the previous document, it seems that you're
reusing identifiers incorrectly.
I'm happy that the Edit-URI (URI of Atom Entry) is the Resource Map URI.
This is
Hi Folks,
* Content Negotiating for Package Formats
RFC2533 seems massive overkill, and very different from HTTP content
negotiation.
Could you set out the requirements that cannot be fulfilled by accept
headers? My understanding is that the packaging format and the wrapped
media format shoul
Hi Ed,
On 19/01/11 13:27, Ed Summers wrote:
On Wed, Jan 19, 2011 at 6:28 AM, Richard Jones wrote:
We've had a few discussions in the past about "supporting" some formats, and
they always end up pretty divisive. So SWORD is aiming to be totally
agnostic on the point, but
d a new URI form for
Aggregations.
Cheers,
Richard
On 19/01/11 13:04, Richard Jones wrote:
Hi Rob,
* URIs used in Statements.
Could you either unpack this section a little, or give an example? When
reading in conjunction with the previous document, it seems that you're
reusing identifier
ons
(ATOM and ORE)
I don't think there was anything sudden about it - it's been in the
design proposal since the start.
Cheers,
Richard
Dave T
On 19 Jan 2011, at 18:57, Richard Jones wrote:
Hi Rob,
I've just mocked up another deposit receipt serialisation which I think
Hi Tim,
While this is all lovely...
Why is it that Google docs API and CMIS both use THE SAME solution to
returning an ATOM entry which has a link rel to a feed which outlined
the resources which are part of this object?
Wouldn't this require an extra URI?
In the original proposal we had a
Dear All,
Thanks for your extensive feedback on the various issues that we have
been discussing on this list, it has been really valuable for the
project team to get this input. We have, we think, identified 3
particular issues of contention:
1/ Whether the Statement should be embedded in the
Hi Alistair,
> I'm new to sword and this thread, so apologies if this has already been
> covered, but one thought...
>
> On Fri, Feb 04, 2011 at 08:54:49AM +0000, Richard Jones wrote:
>> Dear All,
>>
>> Thanks for your extensive feedback on the various issues
Hi Dave,
This looks interesting, definitely chat about it this week. In the mean
time, you could try pointing your client at the Simple SWORD Server:
https://sword-app.svn.sourceforge.net/svnroot/sword-app/sss/trunk/
I'm very close now to a draft of the spec to be implemented against. I
don'
Hi Folks,
We've now got for you a first draft of the SWORD 2.0 profile of AtomPub,
and you can find it here:
http://swordapp.org/sword-v2/sword-v2-specifications/
The main document here is the Profile, but beneath it I will be adding
the first drafts of the Internet Drafts associated with it o
Hi Folks,
In discussions about the SWORD 2.0 spec, a point has been raised
regarding whether using 202 (Accepted) is actually a valid thing to do.
Your thoughts on the following would be appreciated:
First, 202 (Accepted) is defined here:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htm
o important for us to communicate that we are not imposing
specific behaviours on a server with regard to how content is managed
(that's the domain of CMIS as far as I can tell), so if a server can't
manage to unpack a file and add the content and metadata in a way which
makes sense, th
Hi Tim,
>> If the server supported adding further media resource to the package, you
>> could advertise this by including an app:collection element within the feed
>> document, as per [2]. I.e., clients would do a POST to the package-contents
>> collection URI, as per standard Atom protocol for cr
Oh, one other thing...
I would like to ensure that everyone gets attribution (if they want it)
in the spec. Please could you mail me (on or off list) how you would
like to be attributed (name, job title, affiliation, etc), or if you
would like to NOT be attributed.
Cheers,
Richard
---
Hi Ian,
I think that a large part of what SWORD adds to AtomPub is how you talk
about packaging. We're definitely not going to go down the route of
specifying package formats or support levels outside of AtomPub's basic
definitions. What I'd be particularly interested to know is whether you
Hi Folks,
Please keep the packaging discussions on-list if you prefer, or you can
move the discussion to the main sword technical list where practitioners
might have some input for you.
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
SWORD has to support your packaging needs, so it
On 24/02/11 16:22, David Tarrant wrote:
>
> On 24 Feb 2011, at 15:39, Ian Stuart wrote:
>
>> On 23/02/11 11:37, David Tarrant wrote:
>>> In simple terms yes, however because both the repository and client
>>> can be in control of an object then it is actually a lot more
>>> complex!
>>>
>>> Plus
Hi Tim,
On 14/03/11 17:26, Tim Brody wrote:
> Hi All,
>
> I'm pondering whether on-behalf-of is necessary when we could be using
> OAuth (or similar approach)?
>
> e.g.
> OAuth authorize ("ON-BEHALF-OF")
> -> token
> SWORD: Authorization: OAuth {token}
>
> That means we can cut a chunk out of t
Yeah, that's probably something I need to do in the spec. Too used to
writing URI, need to get new habbits. Pretty sure AtomPub says IRI (off
the top of my head without looking), and the Abdera library that I'm
playing with explicitly deals with IRIs. Thanks for bringing that up.
Cheers,
Ri
Hi Glen,
> I've noticed a couple of things. I'm afraid I'm also new to the list so
> apologies if you've already discussed them.
>
> 3. Terminology
>
> EM-URI 'The Atom Edit Media URI'
> Edit-URI 'The Atom Media Edit URI'
>
> I'm afraid the first sentences for the two definitions got me confused
>
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
> mult
Hi Ian,
On 15/03/11 11:55, Ian Stuart wrote:
> On 14/03/11 21:21, Richard Jones wrote:
>> I think that a large part of what SWORD adds to AtomPub is how you talk
>> about packaging. We're definitely not going to go down the route of
>> specifying package formats or
to read in full soon. More
> inline...
>
> On Mon, Mar 14, 2011 at 06:08:56PM +, Richard Jones wrote:
>>> I notice in the current spec you overload the 'edit-media' relation to
>>> define new protocol behaviour when POSTing binary content to a deposit's
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 (s
Hi Folks,
There's been some great discussion on the list this past week or two,
and I thought it might be time for a summary of what looks to me to be a
key sticking point: the scope of sword.
There are two distinct sides to this argument as it's been articulated
on this list:
a) That we shou
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 reaso
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
Hi Ian,
On 18/03/11 09:11, Ian Stuart wrote:
> On 17/03/11 19:37, Richard Jones wrote:
>>> In this second, expanded, view there are three things one need to define
>>> within the discussion
>>>
>>> 1) What the singular Thing is: a (zip|xml|csv|xyz) file
>
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
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 "packag
Hi Folks,
Just a quick summary of changes to be made to the profile in the next
version. Did I miss anything?
1/ 6.6.2 and 6.6.3 are incorrect in their description of the usage of
POST on the URIs. This needs to be clarified.
2/ Add a section describing how to use SWORD headers/techniques on
Hi Folks,
I've put a new version of the spec up on the website based on the recent
feedback from the list:
http://swordapp.org/sword-v2/sword-v2-specifications/
The main changes that were made are as follows:
1/ Changed all relevant instances of URI to IRI. I think I got them
all, but if you
th the
> In-Progress header set to false (it may simply omit the header
> altogether too, as this is treated as In-Progress: false by the
> server)."
oops! well spotted.
Cheers,
Richard
>
> /Tim.
>
> On Wed, 2011-03-30 at 18:49 +0100, Richard Jones wrote:
>> H
Hi Folks,
Last week while Dave T was in town we met up and had a chat about a
particular limitation of SWORD (and Atom, as it happens) which means it
doesn't meet the DepositMO use case requirements.
The problem can be stated as follows:
Given that the atom:link@rel="edit-media" IRI in an atom
Hi Folks,
The reason for the traffic dying down on this list over the past month
or so is that we've been transitioning into the development phase of the
project. As such, we've held off making major changes and instead taken
note of discussions on the list for action later on when we have
fe
Hi Tim,
I've been using text/xml.
I'll update the spec to say text/xml or application/xml, how does that
sound?
Cheers,
Richard
On Fri, May 13, 2011 at 11:58 AM, Tim Brody wrote:
> 1. What is the content-type of SWORD error responses?
>
> /Tim
>
>
>
>
Hi Tim,
Dave and I went round on this a few times, too. AtomPub doesn't say
what should be returned, so we went for recommending a Deposit Receipt
(i.e. an atom:entry), but left the door open for alternative
implementations.
Cheers,
Richard
On 5/27/11, Tim Brody wrote:
> For consistency with
Hi Folks,
Just a quick note to say that today I added some new changes to the spec
to version control, covering feedback from the development process. The
latest version of the spec can be seen here:
http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/trunk/SWORDProfile.html?revision=HE
Hi Folks,
As the end of this round of the SWORD work draws to a close, we're
looking to cut a release of the profile as the official SWORD 2.0.
There have been very few changes to the document in the past couple of
months, so we are fairly confident in its stability. Some tidying
work is still re
Hi Folks,
The final version of the SWORD 2.0 profile and supporting specifications
has now been released:
http://swordapp.org/sword-v2/sword-v2-specifications/
There have been no significant changes to the specification for a couple of
months now, and we are happy that it is stable, and that the
44 matches
Mail list logo
