Identifiers 2.0 Public RFC results

[Theresa Dower]

Markus,

Thanks for the clarification. Of course, as folks may or may not know the ST registry has quite incorrectly all along been handing IVOIDS as case-insensitive since our back-end database (and therefore clever keyword searching) behave that way by default, and we've never had operational issues with it that I'm aware of. But rules are rules, particularly long-standing ones with many registries' worth of content behind them, and I can accept it's probably best to leave the case-sensitivitiy for IVOIDs alone.

Forwarded back to the list in case this overview was of any use to anyone else.

--Theresa

-----Original Message-----
From: Markus Demleitner [mailto:msdemlei at ari.uni-heidelberg.de] 
Sent: Friday, September 25, 2015 3:43 AM
To: Theresa Dower
Subject: Re: Identifiers 2.0 Public RFC results

Hi Theresa,

On Thu, Sep 24, 2015 at 08:30:25PM +0000, Theresa Dower wrote:
> One question:
> 
> "When comparing full IVOIDs, the local part must be split off and 
> compared preserving case, while the registry part must be compared 
> case-insensitively."
> 
> This really makes me sad. I'm sure there's a good reason for it.
> Can you give me a refresher on why it's necessary?

Yeah, it's a huge pain.  The problem was that the original spec said IVOIDs were case-sensitive, and we can't really go back behind that, at least not for the ones that they talked about, i.e. Registry references in the new terminology.

On the other hand, changing the case of fragment identifiers certainly wreaks havoc, as no XML library (say) is prepared to do case normalisation on getElementById (or similar).  On the query part, I expect these will mostly encode file paths (they do on my box), and if you allow people to muck with case there, on most systems you'll make implementation *a lot* harder.

Bottom line: I guess we're hosed on this.  Case-insensitivity is a bane.

Should this go on-list?

Cheers,

        Markus