Re: [Sword-TAP] content negotiating for package formats
This is a perfectly reasonable option, if it fulfills community requirements.
(I just want to on record with this, as I am also putting the case for use of
existing conneg facilities.)
But even if there's no negotiation, if there remains any choice of packaging
format to send then there should be a clear way to unambiguously communicate
what is used. Content-features might help here.
#g
--
Scott Wilson wrote:
I think its time to take a step backwards here.
The packaging problem identified by the SWORD project was not that SWORD or
AtomPub have a problem with POSTing packaged content formats.
The problem is that implementations of SWORD in the academic repositories
community use - needlessly, IMHO - diverse incompatible formats, especially
of metadata within a package.
I don't see that adding any number of HTTP headers is going to improve
interoperability while this remains the case. If nothing else, I would
expect implementations to largely ignore any such headers sent by the client
and look inside the package to try and figure out what it is and if it can
support it. The headers just provide more opportunities for client error.
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 and support a common core of packaging and metadata
formats so that there is practical on-the-ground interoperability with a
reliable default format for client implementations to support out-of-the-box.
S
On 19 Jan 2011, at 08:06, Richard Jones wrote:
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-Packaging
X-Accept-Packaging (which I just made up for the purposes of this
discussion)
Some comments on these:
Accept-Features
Having looked at the document [1] (thanks Graham (K)) it looks like it
would give us the leeway that we need to describe requirements while
ensuring that Graham (T)'s concerns (which I share) about matching up
package format requirements with mimetypes would be dealt with. On the
other hand, this document is 12/13 years old and the header has not made
it into the HTTP content negotiation documentation and is significantly
different in format to all the other Accept- headers. It could also be a
substantial effort for servers to implement the full requirements of
this header.
X-Packaging
I'm against using this in this way as it is already used to alert the
server during POST as to the package format that is being supplied. The
format of the header for content negotiation would have to be totally
different to this usage: a list of package formats and q values for
example, rather than a single definitive URI. I see scope for confusion.
X-Accept-Packaging
Given my concerns about X-Packaging and the comments above about
Accept-Feature, perhaps there is a middle ground that we can define
which does something more minimal with just mimetypes, package formats
and q values in a way similar to having a mimetype that has added
parameters.
For example:
Accept: application/zip; q=1.0, application/atom+xml;type=entry;q=0.8
X-Accept-Packaging: application/zip;{package=METSDSpaceSIP};q=1.0,
application/atom+xml;type=entry;{package=AtomSIP};q=0.8
Or some other suitably neat and unambiguous serialisation which is in
line with how the other Accept- headers work and also gives us the
information we want in a totally definitive mimetype-package format
way. This could be supplied alongside the usual Accept header so that
clients which can't generate the X-Accept-Packaging header can fall back
easily to the usual content negotiation route.
I'm still unclear why there is a need to combine the content type
(application/zip; q=1.0) with the data encoding (METSDSpaceSIP; q=1.0)
Can't you say (1) I only deal in .tgz content, and (2) you can package
whatevers within that content as 'Foo', 'Bar', or even
'Acme::WhiteSpaceEncoded'
I think that the problem is that you can't guarantee that the list of
content types and the list of packaging types are combinable in a meaningful
way; Graham T's email had an example.
So suppose a server can give you content type A with packaging formats X and
Y, or content type B with packaging format Z:
A + (X or Y)
B + Z
and your content negotiation header says:
Accept: A; q=1.0, B; q=0.8
Accept-Packaging: Z; q=1.0, X; q=1.0
Which combination do you return?
On the other hand, this is a general problem and even within the Media
Feature syntax that Graham K describes in his RFC acknowledges this
effectively limits the use of q values to top-level feature sets. So, you
would be limited to content negotiating for:
Accept-Media-Feature:
Re: [Sword-TAP] An example Implementation (VIDEO)
On 18/02/11 12:52, David Tarrant wrote: I think that, if you want to upload a package, don't expect to be able to edit parts of the package. I feel if you want to edit using packages, then you delete the previous version and upload a whole new package. Supporting more features than that is going to be very hard in the packaging scenario. I think I agree with much of this. My feeling is that using multiple transactions to assemble and/or edit a package can become very complex. While some systems may wish to offer such capabilities, I don't think they're a useful basis for an spec whose primary goal is interoperability. I think this is a different issue from that which Alistair Miles was raising, which was, as far as I could tell, about the use of different link-rel types for different functions rarher than overloading an existing one. In my experience, overloading can over-constrain design choices, and often lead to tears, and is probably best avoided. On the topic of packaging, I don't think this should be progressed in isolation. There's a community of interest in e-Research looking at Research Objects, which share many high-level requirements with packages for deposition - roughly, composite objects + metadata, in a simple, easy-to-construct, easy-to-deconstruct container. At this stage, I'd suggest that SWORD the spec should avoid specifying package formats, and that SWORD (the application) should keep its powder dry regarding specific packaging recommendations until some clearer community consensus emerges. (Some common themes I see in several places are: ZIP file container; ORE manifest; metadata in files within the container.) #g -- [1] Bechhofer, S., De Roure, D., Gamble, M., Goble, C. and Buchan, I. (2010) Research Objects: Towards Exchange and Reuse of Digital Knowledge. In: The Future of the Web for Collaborative Science (FWCS 2010), April 2010, Raleigh, NC, USA. [2] Bechhofer, S., Ainsworth, J., Bhagat, J., Buchan, I., Couch, P., Cruickshank, D., Delderfield, M., Dunlop, I., Gamble, M., Goble, C., Michaelides, D., Missier, P., Owen, S., Newman, D., De Roure, D. and Sufi, S. (2010) Why Linked Data is Not Enough for Scientists. In: Sixth IEEE e--Science conference (e-Science 2010), December 2010, Brisbane, Australia. Ian Stuart wrote: On 18/02/11 12:52, David Tarrant wrote: On 18 Feb 2011, at 12:49, Ian Stuart wrote: SWORD is a transport mechanism... we all understand that - but sword can either be a bling truck (http://farm1.static.flickr.com/120/307424194_ccb7df1246.jpg) or a container (http://www.shipping-container-modification.com/images/standard_large.jpg) and both are really expensive!!! The Shipping container is an un-patented design open access, if you like ;-) I think that, if you want to upload a package, don't expect to be able to edit parts of the package. I feel if you want to edit using packages, then you delete the previous version and upload a whole new package. Supporting more features than that is going to be very hard in the packaging scenario. The question still comes down to at some point, the client and the server need to exchange metadata and files - how is this negotiated and how is the data transferred? Even in your video, you are transferring a small set of metadata items from client to server. In your example, you control both ends of the link, so you know the fields to transfer. What happens when the objects get more complex, and you don't control both ends? Copying binary files is (relatively) easy copying sets of metadata from one system to another requires packaging Packaging is the area I'm interested in. -- Index, Search Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev ___ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
[Sword-TAP] Possible header for describing packaging selection
This comes from a completely different set of requorements, but there's a proposal for a Prefer: header that might be useful for indicating packaging preferences. Te Internet draft is timed out now, but I've pinged Marl Nottingham and he indicates the proposal is still alive (sort of). Sometimes these things sit around until someone has the energy to use them. If this were viewed as a useful option for SWORD, then we could put a little weight behind it to hopefully see it progressed as a standards track IETF proposal. This has the advantage of slipstreaming some existing effort rather than making all the running. #g -- Original Message Subject: Re: [hybi] Fwd: New Version Notification for draft-thomson-hybi-http-timeout-00 Date: Mon, 21 Mar 2011 13:21:24 +1100 From: Mark Nottingham m...@mnot.net This smells a little bit like the Prefer header: http://tools.ietf.org/html/draft-snell-http-prefer-02 Did you consider using something like that? E.g., Prefer: response-fast Where the parameters of 'response-fast' is specific to the resource. As you can probably guess, I'm suggesting this because I'm concerned that 95% of people who want to use something like Request-Timeout won't have such a subtle use case in mind. -- 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 Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
