- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 16 Mar 2016 12:54:53 +0000
- To: Robert Stuart <robert.j.stuart@ugov.gov>
- Cc: "David I. Lehn" <dil@lehn.org>, Pemanent Identifier CG <public-perma-id@w3.org>
Ah, I had failed to think about PURL doing case insensitivity.. that would affect its transition - which would also affect top-level entries (e.g. http://purl.org/PAV should work ) On 15 March 2016 at 13:41, Robert Stuart <robert.j.stuart@ugov.gov> wrote: > I can understand if this is out of scope. It feels like it should be a > choice for domains or subdomains instead of a always true or false. > > This was/is the behavior of purl.org so that is one of the main things that > set expectations of my community for the last ~6 years. I don't know if PURL > was apache based in the back end or not I don't think it was. So the method > of case insensitive is different from the desire to support it. > > I agree that misspellings like l for I are an issue that we have ignored but > since it's not a change from PURL we don't get flack for it. > > > On Tue, Mar 15, 2016 at 9:23 AM, Stian Soiland-Reyes > <soiland-reyes@cs.manchester.ac.uk> wrote: >> >> I'm not so sure about this..beyond binding us even closer to Apache (while >> we are discussing a more flexible CSV approach) >> >> w3id is about permanent identifiers, not a "nicer URL" service. Most URLs >> today are lowercase, so why not just assume that? You would also have the >> potential problem of lc vs Ic which is not covered by your rule >> >> On 15 Mar 2016 01:13, "Robert Stuart" <robert.j.stuart@ugov.gov> wrote: >>> >>> To better help understand the need my use cases are around giving URLs to >>> people in briefing decks and verbally. Much less for client systems to be >>> coded and much more for humans who are bad at remembering case to use. >>> >>> I too am not an apache expert. My limited testing locally seemed to say >>> that the .htaccess file was not hit if there was a valid path that it could >>> traverse instead. That does mean it would be hit for all "bad" w3id.org/xxx >>> URLs where xxx does not exist in that exact case. >>> >>> For humans messing up case it would be an extra .htaccess to process but >>> I would hope that is a trivial load. >>> >>> Thanks for your consideration and for standing up this service. >>> >>> >>> On Mon, Mar 14, 2016 at 8:22 PM, David I. Lehn <dil@lehn.org> wrote: >>>> >>>> On Tue, Mar 8, 2016 at 4:50 PM, Robert Stuart <robert.j.stuart@ugov.gov> >>>> wrote: >>>> > I would like w3id.org/ic to match case insensitive. I think it could >>>> > be done >>>> > with a top level .htaccess file that looked like: >>>> > >>>> > ########################## >>>> > ... >>>> > RewriteRule ^IC/?(.*)$ ic/$1 [NC] >>>> > ########################## >>>> > ... >>>> > rewrite any case of IC Ic iC to ic >>>> > not fire on any of the existing directories nor would it fire on ic >>>> > ... >>>> > would not fire on a future directory like ice >>>> > would only fire when there was no directory that matched exactly >>>> > existing. >>>> > ... >>>> >>>> I'm not sure I understand the reasoning for handling case differences. >>>> If just one case is used won't clients just fail and get fixed if they >>>> use the wrong thing? I would guess that's how most of the semantic >>>> web identifier use cases work. >>>> >>>> I suppose no one knows what to do here. I don't know what the limits >>>> are of what this project should support right now. I'm sure this >>>> simple rule won't be a problem today, but it just adds something that >>>> would need to be handled if the server changes technology. Apache was >>>> just the quickest means to an end when we started. Who knows what it >>>> might evolve into as the service grows. These issues can be handled >>>> but it may add complexity if we implement some new non-Apache system. >>>> Maybe the entire system should just be case insensitive by default? >>>> Do all the redirects and let the target handle what they want. >>>> >>>> I don't know the internals of Apache, but I'm guessing any top level >>>> rules still have to be checked for every path. Maybe it's smart >>>> enough to mostly avoid that. Not really an issue at the current low >>>> load but if everyone wants NC rules maybe it matters. >>>> >>>> Thoughts anyone? >>>> >>>> -dave >>> >>> >>> >>> >>> -- >>> Bob Stuart >>> SETA Support for ODNI/CIO/IA Division >>> Specifications Team Co-Lead >>> Cell: 703-304-5864 >>> AIM: bobStuart >>> Skype: cmsi-bobstuart >>> TextPage: 7033045864@txt.att.net >>> Robert.J.Stuart@ugov.gov > > > > > -- > Bob Stuart > SETA Support for ODNI/CIO/IA Division > Specifications Team Co-Lead > Cell: 703-304-5864 > AIM: bobStuart > Skype: cmsi-bobstuart > TextPage: 7033045864@txt.att.net > Robert.J.Stuart@ugov.gov -- Stian Soiland-Reyes, eScience Lab School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
Received on Wednesday, 16 March 2016 12:55:43 UTC