Re: [sword-app-tech] [sword] Fwd: SWORD 1.3

[Jim D. <jim...@po...>]

Hi all,

In this e-mail some open issues, and some reasoning where I've made changes
between 1.2 and 1.3.

Open issues

1/ sword:formatNamespace and X-Formatnamespace aren't particularly well
named; sword:acceptPackaging X-Packaging seem more appropriate. I erred on
the side of not changing things.

2/ It would be useful to have a user guide spelling out how to implement
"deferred" resource creation, i.e. where the server responds 202 to the
original POST.

3/ How does the server obtain the identity of the client to use in the
atom:generator element? There's no header for it.

4/ I'm ambivalent about whether the error-codes should be in headers or in a
document. If we want to enforce back-compatibility the headers will have to
be supported in either case.

5/ Adopting the multipart proposal would solve some issues (e.g. the
atom:generator issue above). It would mean a bit more complexity to the
authentication / mediation section. Also, it seems premature to base SWORD
on a draft RFC. Thoughts?

6/ Pablo at MS requested a "preferred format" feature in the collection
element of the service document, or alternatively a @preference attribute
containing an ordinal number. Would others find this useful?

Explanations

* The formatNamespace types will be in a separate document with its own
revisions.

* The need for co-ordination between the service document and the deposit
behaviour with the No-Op feature was potentially dangerous, so I've required
all servers to understand X-No-Op even if they don't support it.

* On reflection, the guidance on the Slug header wasn't prescriptive enough
to be useful, and encouraging use of the Slug as the atom:id was a bad idea.

* I streamlined the requirements for mediated deposit - it was impossible
for servers to differentiate between the cases listed in 1.2, so I've just
recommended a consistent approach that hopefully works for everybody.

Thoughts / discussion on any of this very welcome: please direct discussion
to the sword-app-tech list, since the ukoln list isn't open.

Best regards,
jim