LISTSERV 16.5 - CODE4LIB Archives

RFC and expectation violations make my brain hurt.

Overloading an operator that has a clearly defined role in HTTP URIs (https://tools.ietf.org/html/rfc7230#section-2.7.1) creates the potential for /so/ many unexpected interactions between browsers (https://code.google.com/p/chromium/issues/detail?id=108690), HTTP caches, URL rewriting servers, etc. that implementations, adopters, and users are going to be playing a long game of whack-a-mole working around them.

The proposal is already carving out a URI namespace in the form of “ark:”:

  http://ark.cdlib.org/ark:/13030/tf5p30086k?

So why not take advantage of the fact that any system processing the “ark:” namespace is already going to have to be a custom application and adopt a RESTful path to communicate the service requested instead?

  http://ark.cdlib.org/ark:metadata/13030/tf5p30086k
  http://ark.cdlib.org/ark:policy/13030/tf5p30086k

If a web services style implementation is undesired, what about creating another reserved character or overload a character that is already used in URIs but not part of the HTTP URI specification, “!"?

Or, if a standard approach for HTTP header implementation were proposed and adopted, it is not unreasonable to imagine that browsers might adopt methods that would allow the average user access to the inflections without jumping through hoops once adoption reaches critical mass.

There are many approaches and techniques that could be employed here that would not require overloading “?” in HTTP URIs that there really is no excuse for trying to do so.

-- 
Andrew Anderson, Director of Development, Library and Information Resources Network, Inc.
http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes

On Dec 9, 2014, at 9:25, Ethan Gruber <[log in to unmask]> wrote:

> I'm using a few applications in Tomcat, so inflections are much more
> difficult to implement than content negotiation. I can probably tweak the
> Apache settings to do a proxypass for inflections by modifying the examples
> above.
> 
> I agree with Conal, though. Inflections are puzzling at best and bad
> architecture at worst, and the sooner the community puts forward a more
> standard solution, the better.
> 
> On Mon, Dec 8, 2014 at 7:21 PM, John Kunze <[log in to unmask]> wrote:
> 
>> Just as a URL permits an ordinary user with a web browser to get to an
>> object, inflections permit an ordinary user to see metadata (without curl
>> or code).
>> 
>> There's nothing to prevent a server from supporting both the HTTP Accept
>> header (content negotiation) and inflections.  If you can do the one, the
>> other should be pretty easy.
>> 
>> On Mon, Dec 8, 2014 at 4:01 PM, Conal Tuohy <[log in to unmask]> wrote:
>> 
>>> I am really puzzled by the use of these non-standard "inflexions" as a
>>> means of qualifying an HTTP request. Why not use the HTTP Accept header,
>>> like everyone else?
>>> 
>>> 
>>> On 9 December 2014 at 07:59, John A. Kunze <[log in to unmask]> wrote:
>>> 
>>>> Any Apache server (not Tomcat) can handle the '?' and '??' cases with a
>>>> few rewrite rules to transform them into typical CGI-like query
>> strings.
>>>> 
>>>>  # Detect ? and ?? inflections and map to typical CGI-style
>> parameters.
>>>>  # One question mark case:  ?  -> ?show=brief&as=anvl/erc
>>>>  RewriteCond %{THE_REQUEST}  \?
>>>>  RewriteCond %{QUERY_STRING} ^$
>>>>  RewriteRule ^(.*)$ "$1?show=brief&as=anvl/erc"
>>>> 
>>>>  # Two question mark case:  ?? -> ?show=support&as=anvl/erc
>>>>  RewriteCond %{QUERY_STRING} ^\?$
>>>>  RewriteRule ^(.*)$ "$1?show=support&as=anvl/erc"
>>>> 
>>>> So if your architecture supports query strings of the form
>>>> 
>>>>  ?name1=value1&name2=value2&...
>>>> 
>>>> it can support ARK inflections.
>>>> 
>>>> I don't believe that the ARK spec and HTTP URIs are fully compatible
>>>>> ideas.
>>>>> 
>>>> 
>>>> True.  A '?' by itself has no meaning in the URI spec, which means it's
>>>> also an opportunity to do something intuitive and important with an
>>>> unused portion of the "instruction space" (of strings that start out
>>>> looking like URLs).  Any URLs (not just ARKs) could support this.
>>>> 
>>>> The THUMP spec (where inflections really live) will be modified to
>>>> require an extra HTTP response header to indicate that the server is
>>>> responding to an inflection and not to a standard URI query string.
>>>> This could help in the '??' case, which actually could be interpreted
>>>> as a valid URI query string.
>>>> 
>>>> -John
>>>> 
>>>> 
>>>> 
>>>> --- On Mon, 8 Dec 2014, Ethan Gruber wrote:
>>>> 
>>>>> Thanks for the info. I'm glad I'm not the only person struggling with
>>>>> this.
>>>>> I'm not entirely sure my architecture will allow me to append question
>>>>> marks in this way (two question marks is probably feasible, but it
>>> doesn't
>>>>> appear that one is). I don't believe that the ARK spec and HTTP URIs
>> are
>>>>> fully compatible ideas. Hopefully some clearer request parameter or
>>>>> content
>>>>> negotiation standards emerge.
>>>>> 
>>>>> Ethan
>>>>> 
>>>>> On Sat, Dec 6, 2014 at 10:23 AM, Phillips, Mark <
>> [log in to unmask]>
>>>>> wrote:
>>>>> 
>>>>> Ethan,
>>>>>> 
>>>>>> As Mark mentioned we have implemented the ARK inflections of ? and ??
>>>>>> with
>>>>>> our systems.
>>>>>> 
>>>>>> I remember the single ? being a bit of a problem to implement in our
>>>>>> system stack (Apache/mod_python/Django) and from what I can tell
>> isn't
>>>>>> possible with (Apache/mod_wsgi/Django) at all.
>>>>>> 
>>>>>> The ?? inflection wasn't really a problem for us on either of the
>>>>>> systems.
>>>>>> 
>>>>>> From conversations I've had with implementors of ARK,  the issues
>>> around
>>>>>> supporting the ? and ?? inflections don't seem to be related to the
>>>>>> frameworks issues as other issues like commitment to identifiers, the
>>>>>> fact
>>>>>> that ARKs are being used in a redirection based system like Handles,
>> or
>>>>>> the
>>>>>> challenges of accessing the item metadata for items elsewhere in
>> their
>>>>>> system.
>>>>>> 
>>>>>> I think having a standard set of request parameters or other url
>>>>>> conventions could be beneficial to the implementation of these
>> features
>>>>>> by
>>>>>> others.
>>>>>> 
>>>>>> Mark
>>>>>> ________________________________________
>>>>>> From: Code for Libraries <[log in to unmask]> on behalf of
>>>>>> [log in to unmask] <[log in to unmask]>
>>>>>> Sent: Saturday, December 6, 2014 8:23 AM
>>>>>> To: [log in to unmask]
>>>>>> Subject: Re: [CODE4LIB] Functional Archival Resource Keys
>>>>>> 
>>>>>> This brief exchange on Twitter seems relevant:
>>>>>> 
>>>>>> https://twitter.com/abrennr/status/296948733147508737
>>>>>> 
>>>>>> On Fri, Dec 5, 2014 at 12:50 PM, Mark A. Matienzo <
>>>>>> [log in to unmask]
>>>>>> 
>>>>>>> 
>>>>>>> wrote:
>>>>>> 
>>>>>> Hi Ethan,
>>>>>>> 
>>>>>>> I'm hoping Mark Phillips or one of his colleagues from UNT will
>>> respond,
>>>>>>> but they have implemented ARK inflections. For example, compare:
>>>>>>> 
>>>>>>> http://texashistory.unt.edu/ark:/67531/metapth5828/
>>>>>>> http://texashistory.unt.edu/ark:/67531/metapth5828/?
>>>>>>> http://texashistory.unt.edu/ark:/67531/metapth5828/??
>>>>>>> 
>>>>>>> In particular, the challenges posed by inflections are described in
>>> this
>>>>>>> DC2014 paper [0] by Sébastien Peyrard and Jean-Philippe Tramoni from
>>> the
>>>>>>> BNF and John A. Kunze from CDL.
>>>>>>> 
>>>>>>> [0] http://dcpapers.dublincore.org/pubs/article/view/3704/1927
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Mark
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Mark A. Matienzo <[log in to unmask]>
>>>>>>> Director of Technology, Digital Public Library of America
>>>>>>> 
>>>>>>> On Fri, Dec 5, 2014 at 2:36 PM, Ethan Gruber <[log in to unmask]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> I was recently reading the wikipedia article for Archival Resource
>>> Keys
>>>>>>>> (ARKs, http://en.wikipedia.org/wiki/Archival_Resource_Key), and
>>> there
>>>>>>>> 
>>>>>>> was
>>>>>>> 
>>>>>>>> a
>>>>>>>> bit of functionality that a resource is supposed to deliver that we
>>>>>>>> 
>>>>>>> don't
>>>>>> 
>>>>>>> in our system, nor do any other systems that I've seen that
>> implement
>>>>>>>> 
>>>>>>> ARK
>>>>>> 
>>>>>>> URIs.
>>>>>>>> 
>>>>>>>> From the article:
>>>>>>>> 
>>>>>>>> "An ARK contains the label *ark:* after the URL's hostname, which
>>> sets
>>>>>>>> 
>>>>>>> the
>>>>>>> 
>>>>>>>> expectation that, when submitted to a web browser, the URL
>> terminated
>>>>>>>> 
>>>>>>> by
>>>>>> 
>>>>>>> '?' returns a brief metadata record, and the URL terminated by '??'
>>>>>>>> 
>>>>>>> returns
>>>>>>> 
>>>>>>>> metadata that includes a commitment statement from the current
>>> service
>>>>>>>> provider."
>>>>>>>> 
>>>>>>>> Looking at the official documentation (
>>>>>>>> https://confluence.ucop.edu/display/Curation/ARK), they provided
>> an
>>>>>>>> example
>>>>>>>> of http://ark.cdlib.org/ark:/13030/tf5p30086k? which is supposed
>> to
>>>>>>>> 
>>>>>>> return
>>>>>>> 
>>>>>>>> something called an Electronic Resource Citation, but it doesn't
>>> work.
>>>>>>>> Probably because, and correct me if I'm wrong, using question marks
>>> in
>>>>>>>> 
>>>>>>> a
>>>>>> 
>>>>>>> URL in this way doesn't really work in HTTP.
>>>>>>>> 
>>>>>>>> So, has anyone successfully implemented this? Is it even worth it?
>>> I'm
>>>>>>>> 
>>>>>>> not
>>>>>>> 
>>>>>>>> sure I can even implement this in my own architecture.
>>>>>>>> 
>>>>>>>> Maybe it would be better to recommend a standard set of request
>>>>>>>> 
>>>>>>> parameters
>>>>>>> 
>>>>>>>> that actually work in REST?
>>>>>>>> 
>>>>>>>> Ethan
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Tod Robbins
>>>>>> Digital Asset Manager, MLIS
>>>>>> todrobbins.com | @todrobbins <http://www.twitter.com/#!/todrobbins>
>>>>>> 
>>>>>> 
>>> 
>>