Re: [Sword-TAP] content negotiating for package formats

2011-01-28 Thread Graham Klyne 
[Historical note]

FWIW, the original work on content negotiation was intended to work in both push
and pull environments.

Cf. http://tools.ietf.org/html/rfc2703

One of the things I was trying to avoid was the asymmetric stance w.r.t. sender
and receiver of HTTP TCN described in http://tools.ietf.org/html/rfc2295 (both
of whose authors were also involved to greater or lesser extent in the media
features work).

#g
--


Richard Jones wrote:
> 
> 
> 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 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.
>>> Bearing in mind that I have my tongue embedded firmly in my cheek 
>>> here...
>>
>> Oh good!
>>
>>> I have an excellent content package that will either work with binary 
>>> data directly included or passed-by-reference, and I am working on 
>>> Importers for DSpace&  EPrints as we speak... as outputs of the OA-RJ 
>>> Broker work.
>>
>> I suggest we standardise on a really crappy packaging format with 
>> almost zero features, combined with a totally inadequate metadata 
>> schema. At least that way it might actually work.*
>>
> 
> I think we're talking slightly cross-purposes here.  The problem with 
> the content negotiation is in when the client /retrieves/ its content 
> from the sword server, not when it deposits it.
> 
>  From a deposit point of view we have the acceptPackaging field in the 
> service document, which tells the client what formats the server will 
> support the deposit of, and there is the (X-)Packaging header which 
> tells the server what the client has given them.  The default 
> (standard?) format that we're recommending for SWORD is a plain old zip 
> file, optionally augmented with dc embedded in an atom entry sent along 
> with it, which is very much in-line with the AtomPub spec (and also fits 
> your criteria above :) )
> 
> The problem is when the client is trying to retrieve content from the 
> server, and wants to ask for it in a particular format via content 
> negotiation.  At the moment, there is no provision in HTTP Accept- 
> headers to ask the server for a METS package.
> 
> 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 it does need to provide the client 
> and server a mechanism to negotiate over what format they are 
> interchanging.  If we can achieve that, that will be relatively useful 
> in an interoperability setting, I think, particularly as many SWORD 
> servers (particularly repositories) are able to create dissemination 
> packages in a large number of formats (see EPrints export plugins for 
> example).
> 
> I don't want us to decide, therefore, on a package format, but on a 
> mechanism by which a client and server can get together and negotiate 
> one for themselves.
> 
> Cheers,
> 
> Richard
> 
>>> On a serious note: yes - the transport mechanism should be agnostic 
>>> to the content... unless one wants to define a content transfer 
>>> mechanism rather than a transport mechanism :)
>>>
>>> -- 
>>>
>>> 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.
>>>
>>
>>
>> * http://en.wikipedia.org/wiki/Worse_is_better
> 
> 









--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] content negotiating for package formats

2011-01-28 Thread Graham Klyne 
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

Re: [Sword-TAP] content negotiating for package formats

2011-01-28 Thread Graham Klyne 
Whether or not the selection is clearly defined by the specification, in
practice I think it will always be a case of "server decides".  I don't think
the equal q-values add any additional difficulty to that.

#g
--

Ian Stuart wrote:
> On 19/01/11 08:06, Richard Jones wrote:
>> 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?
> I agree its not a clear-cut case. however it also has to be said 
> that the content negotiation header isn't helping by declaring two 
> options to be of equal "value"
> 
> I would say:
> A+Z, then A+X, then B+Z, then B+X
> 
>  FIFO-style
> 
> (after all, if you have a preference for order, try:
> 
>   Accept-Packaging: X; q=1.0, Z; q=1.0
> 
> instead)
> 
> 
> Even under the concept of a combined Accept model, what do you do when 
> you receive
> 
>   Accept-Media-Feature: A(Z); q=1.0, A(X); q=1.0, B(Z); q=0.8, B(X); q=0.8
> 
> 









--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] content negotiating for package formats

2011-01-28 Thread Graham Klyne 
I think there may be an interaction between this discussion and current
discussion of Research Objects; cf.

   http://eprints.ecs.soton.ac.uk/21587/
   http://www.wf4ever-project.org/wiki/display/docs/Data+packages+in+ADMIRAL

Quite coincidentally, I'm also in current email discussion with Dave Crocker
(probably best known for RFC822) about an all-new UTF-8 clean message format for
email.

I'm not sure if any of this is relevant...

#g
--


Graham Triggs wrote:
> On 19 January 2011 09:49, 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.
> 
> 
> I want to agree on having a standard package, but there are issues with 
> saying that. The most obvious is how that sits with the current use of 
> SWORD.
> 
> But there is also the situation that repositories are used in different 
> ways, have different features (that reflect in their content) and 
> contain a wide range of different materials.
> 
> We could agree on and define a profile that works in the most general 
> way for a set of use cases / content types. But that would still leave 
> it up to us/others to define other profiles that would be used in those 
> other scenarios.
> 
> I don't think you can ever get away from a degree of content 
> negotiation, but it doesn't necessarily need to be as complex as the 
> scenarios outlined depending on what agreements you can have for common 
> formats in common cases.
> 
> G









--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel

Re: [Sword-TAP] content negotiating for package formats

2011-01-28 Thread Graham Klyne 
Richard Jones wrote:
> I've spent the last 3 or 4 days looking at the Media Feature stuff in 
> detail, and I have to confess it does feel like a sledgehammer to crack 
> a nut.  At the moment I'm playing with specifying restricted version of 
> it to see if we can get the effect that we want without the huge 
> overhead of a full implementation.

I'm inclined to agree about the sledge hammer and nut part.  This is why I
suggested limiting the media feature expression to a more restricted form that
is easier to process and match.

The advantage  of such an approach is that it can use existing specifications
rather than invent new ones.  Also, it exploits an existing IANA registry,
allowing an easier path for possible future enhancements rather than forcing
discussion back to square one.  I don't believe the additional parsing effort is
significant in the scheme of things - I think a regex could do it for a
restricted form.  It's the feature matching that has the potential to get
complicated.

My suggestion is that the benefits of using existing specs. (with restrictions)
can outweigh the near-term complexities of adopting a more general solution.
Given the relatively limited number of likely implementations for SWORD
(compared with more mainstream IETF standards), I think the effort of doing the
standardization work (in whatever forum) will dwarf the implementation effort.

#g
--










--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Sword-app-techadvisorypanel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel